On Sun, Mar 30, 2008 at 6:42 AM, :murb: [maarten brouwers] <[EMAIL PROTECTED]> wrote: > > Accessibility can be measured in multiple ways. You can look at > font-sizes, colours etc. and say, well this and this text can't be read, > this can't be read, this is well readable... etc. On the other hand there > is another aspect that is a bit harder to quantify with contrast > differences etc., but is imho as important, if not more important: the > interface should be helpful in giving users the right pointers. As a team > we made the decision to deliberately focus on the action statements (and > content), and they are thought of as giving the right pointers to ~90% of > our the website users.
<snip> > Additionally we can make an alternative stylesheet (Ivan, that's the > solution W3C has developed, and is at least supported by Firefox/Opera for > these types of situations, not relying on background images being turned > on/off ;) ) with increased contrast (maybe even stored in a cookie), but > if search is at a certain stage really important... the page maintainer > should consider placing search in the content field, not relying on users > to search for the top right corner searchfield. > Hello, In following the discussions about the issue of the new site for visual impaired members/visitors on this list and the users mailing list this use of alternative CSS has been on my mind also. At one point someone on the users mailing even suggested to one user to just disable the use of style sheets to achieve more contrast. A rather caleous response I thought, unfortunately I could not reach through the monitor and retrieve the email after hitting the send button. ( I'll make my apology directly to that person ) One browser, Konqueror, supplies a client side CSS file designed specifically for visually impaired users. It seemed worthwhile to take a look at how the site would perform using this. Specifically I used Konqueror / KDE 4, a screen resolution of 1280 x 1024 and text size set to 120%, 150%, and 200% of normal. For the most part the OOo main site functions quite well - with a few notable exceptions: ( What follows is for text size settings of 120% and 150% ) Icons on the main page action statements disappear. The upper right hand corner 'widget' is a problem. Specifically the input boxes lose borders completely when the mouse over effects are fired. They are displayed quite clearly when the mouse is not over top. This is true for not only the search box but the user name and password boxs also. The main login page has no problems. The documentation projects main page with all the search functionality found there also displays without a problem. 'Advanced Search' page has no problems. The main Why page is a real problem. The front page breaks and becomes nearly unusable. Sub pages however, display without a problem. The issue tracking pages work without a problem. As for coverage - all pages linked off the main menu where traveled. Most of the project pages and a few of the NL pages. Moving from the main website to the auxillary sites: Extensions - some odd quirks in the header. Content is displayed well. Wiki - the logo is lost completely. Otherwise there doesn't seem to be a problem. I put an emphasis on covering the User Guides and FAQ pages - these appear to display well. Community Forum - All 'status' icons supplied in base package disappear. Those graphics added during site setup still display. Otherwise no noticeble issues. ( 200% of normal text size - exceptions ) Main site: The right corner 'widget' now covers the navigation tabs making those to the right of 'Download' inaccessible. Wiki - non-visible logo now covers part of the navigation items at the top of the page, when logged in. Extensions - The header becomes a real problem (distraction) now, particularly if logged in. ( Note: I also run a Drupal based site and ran this setup against it, the header problems don't manifest there. That site is not heavily customized, as the extensions site is, rather uses a standard drupal theme, so the problems probably come from that customization and not the base package ) --------------- OK - what does this all mean? I think it means we could all do a little better job on this. At the same time however the problems do not seem particularly egregious to me - with the exception of the Why page. ( Also, this was very specific test run - using the Konqueror style sheet - and given that I used KDE4 could include some bugs on that side ) For my part I need now to understand and fix the issue on the community forum. I know that we have a number of visually impaired users there and am wondering if they just don't even know that they are not seeing certain content. Going forward however, it may be appropriate to address the use of secondary style sheets to help with accessibility issues for all the sites that make up the OpenOffice.org community. It may also be appropriate to make the use of these secondary style sheets selectable from the the actual pages - not relying purely on the browsers options. ( As an example we have done this already on the Community forum where two secondary style sheets, changing text scaling factor, can be selected from the main index page. ) If I can help with some of this work I'd be willing to do what I can. Drew --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
