Accessibility statements and site viewing options

In Glaucoma and photography, Richard Rutter notes that the Glaucoma Research Foundation has a really well-written accessibility statement. Reading it reminds me that I really need to revisit the accessibility statements I write. I say reminds me because in December Gez Lemon posted a guide to Writing a Good Accessibility Statement, and after reading that article I realised I had a bit of work to do.

One more thing that strikes me about Glaucoma.org is the way it presents various options for text size, contrast and layout. I’m not normally a fan of site viewing widgets like the tiny graphical buttons you can use to change text size that many public sector websites use. They are almost always nothing but cosmetic patches to sites that are in desperate need of major surgery. Not to mention the fact that they are in most cases just replicating functionality that is best left to the browser, as mentioned by Patrick H. Lauke in Big Button Report misses the point?.

But the way they are implemented on the Glaucoma.org site I find myself actually using them. Worth noting is that there is an option to switch between multi-column and single-column layouts. You don’t find that very often.

I’m not sure what it is that makes these widgets seem so much more usable than the awkward ones that are so common. Maybe it’s that the designers had the courage to put them in a bar across the top of the site instead of trying to hide them.

What is everyone’s thoughts on widgets of this kind?

Posted on May 10, 2006 in Accessibility, Quicklinks

Comments

  1. These examples are just what I need, I’ve got to write one this week! Thanks.

  2. Ah yes, thanks for the reminder about glaucoma.org I failed to add it to del.icio.us at the time of Gez’s article. Stylesheet widgets, right up there with fixed v fluid layouts for interesting debate factor :)

    I have a local government project coming up soon that will utilise stylesheet alternatives for layout (multi or single column), contrast and text size - all separate options. My sole reason for going to this effort (the multiple choices, not the multiple files) is purely because whereas disabled users will more than likely have their own computers correctly configured to support their disability, that is not necessarily the case when they use a publicly-available computer in a library for example. When library staff don’t have admin rights or the knowledge to configure a computer on a per-person basis it is much easier to provide the control from the website itself via CSS.

    Obviously, public access to government is very important so it’s an extra half-mile that I feel we have to travel, along with support for IE5 on Mac OS 8/9 [grin]. This “argument” or justification could be added to any website requirements specification but with everything it needs to be properly considered - how many disabled users will really access your site from someone else’s computer? With commitment to public access to government services on the up I think the justification is appropriate in my case.

  3. On the other hand, too many choices is not that good. I think they could keep only two buttons for text size “larger/smaller” and combine contrast and layout options into one, swtiching between two columns normal and single column high contrast version (“Zoom the web” ;)

  4. For some reason they don’t show up at all in Opera, and they don’t actually work in Firefox. Maybe it’s just me??? Of course, Opera has an accessibility layout built in :)

  5. May 10, 2006 by St├ęphane Chausson

    @Megan: the bar is pure javascript. I first had the same problem as it didn’t show up then I allowed javascript for the site and saw the bar.

  6. I kind of went overboard and added a ‘CSS Panel’ to my blog (linked to from my name) which I originally called an ‘access panel.’ Most of those things a browser can already do. It was just an experiment, maybe I’ll modify it as I get more ideas.

  7. @Rimantas: what I like about separating the single column from the high contrast style is that I can use that layout for mobile browsing and still maintain default contrast (i.e. use the style sheet twice). With some forethought though it is possible to provide the combinations via a “linking” style sheet containing @import calls. I never implemented it, but in one experiment I put the body font-size selector into a “linking” style sheet and called the text CSS and layout CSS via @import references. In this way, I could define my own combos. Why I was doing this is lost in the mists of time now though… I was either bored or dehydrated ;)

  8. I agree that most of these functions are better left to the browser. But most browser users don’t know how to change their settings. And some browsers don’t make it easy to change anything beyond font size.

    For example, I still haven’t figured out how to select an alternate style sheet using Safari. I’m pretty sure IE doesn’t offer that functionality at all (but I may be wrong).

    Most browsers do support custom style sheets. But does your average web user know enough CSS to create one? Do they even know it’s possible to do?

    Having widgets on the page gives users that flexibility in a space they’re familiar with. In sum: Widgets = Good.

  9. Plenty of good design/accessibility food for thought there. Nice to know there are well put together Glaucoma resources out there too - it runs in my family and I may need them one day.

    That sobering thought notwithstanding, I’ll always associate Glaucoma websites with this amazing site, complete with its sub-Monty Python animation and specially commissioned “Glaucoma Hymn”: the Association of International Glaucoma Societies . All together now, ” Glaucoma, Glaucoma, Glaucoma…”

  10. Curse you Chris for propogating THAT glaucoma site!

    I tend prescribe to the user preferences are for sissies camp. This site certainly has implemented these widgets in the most usable way I’ve seen, but if it’s accessibility we’re interested in, you have to ask the question of who benefits from such options and who is hindered by them. When you consider the sheer population of those with cognitive disabilities compared to those who might need such options, I think that usually these types of contraptions should be left off. And screen reader users certainly shouldn’t be subjected to visual preference options.

    And I’ll always argue that those that MUST have large font or contrast will already have it. If your site requires anybody else to need to increase the contrast or font size or change column width, then you’ve broken something to begin with - giving the user the option to fix your mistake is not a very good solution (IMHO).

  11. I have to agree with Jared. The widgets are a cool diversion, but that’s just what they are - a diversion.

    When I visit a site, I’d prefer to get straight to business and not worry about “what does this little button do?”

    Besides, if a person is truly having difficulty viewing web pages, then they will have taken the time already to adjust their browser settings. The reason that most people don’t know about these settings is simply because they’ve never needed them.

  12. Whether it’s right to use widgets or not, I think the reason that these seem so usable is that they are clearly labeled and have tool tips for each button. It’s pretty evident what each does.

  13. May 10, 2006 by Zephyr

    It’s a big assumption that users know how to set their preferences in their browser and will have done so already.

  14. Accessibility statements are fine as long as they don’t act as substitute for built-in accessibility. The site we focus on here - Glaucoma.org - seems to have been well built and can carry its statement.

    Alternative style widgets as additions are fine with me. However, I think the most needed alterations exist as browser-options, and see less and less need for duplicating the basic browser-functionality in web pages/sites.

    Whether or not users know how to use their browsers and set their own preferences, is not all that relevant. The fact that most browsers have the most needed options, is what matters, and user-ignorance is best counteracted by providing information to those who want it - maybe as part of an accessibility statement. Those who don’t want to know are creating their own, very personal, accessibility-barriers, which can’t be solved by widgets or statements.

  15. I find such widgets pointless on most sites, since they are indeed functions provided by the browser. However, I must say that the design of these particular widgets is very good.

    On some sites, I’ve seen microscopic buttons designed for the purpose of increasing text size. It’s hilarious that some people don’t think that if a user needs a larger font size, they’re not going to easily see or read a microscopic button.

    However, they are useless for font size because browsers do provide their own built in abilities for that.

    For layout switching, some browsers do provide built in stylesheet switching, but such things should be handled automatcially. There are scripts available to automatically select the best layout based on the available viewport size and when more browsers support media queies (which Opera already has partial support for) such scripts wouldn’t even be required.

    For switching contrast, again some browsers provide stylesheet switching, but it’s not as discoverable as it could be. I suspect many users wouldn’t even be aware when they visit a site that provides an alternate stylesheet, but this is something I feel the browser vendors need to work on.

  16. May 11, 2006 by Tommy Olsson

    I find widgets replicating browser functions pointless. Why reinvent the wheel?

    Yes, many users don’t know about these functions. But instead of doing a lot of work that relies on client-side scripting being enabled, why not educate your users instead?

    The accessibility statement could contain hints or instructions on how to perform common tasks like changing the text size or printing the page. Just be careful, or you’ll end up sounding patronising.

    Alternate style sheets may be useful. If you add a JavaScript style switcher, make sure to add the link with JavaScript, too. That way users without JavaScript won’t have to see a non-working link.

  17. It’s too bad that the site controls aren’t unobtrusive, rather, they include a UA check to exclude IE Mac and Opera. A zooming stylesheet would have been a better choice, since they could use a stylesheet switcher while keeping all options.

  18. May 11, 2006 by Robert Wellock

    It’s probably one of the more better methods of doing them. However, I find them too distracting and it would probably burdened some of those people with cognitive issues.

  19. May 11, 2006 by Zephyr

    Georg wrote (and several others agreed): “The fact that most browsers have the most needed options, is what matters, and user-ignorance is best counteracted by providing information to those who want it - maybe as part of an accessibility statement.”

    Like any design aimed to be usable, for whatever target group, you do what’s necessary to make the interaction flow through usable design. Although I agree that user education can be a good thing, it hasn’t proven itself to be very effective. Designers have tried in many areas to ‘educate’ users by providing instructions, when a more transparent / intuitive interaction may have been more effective. Education is best suited for environments where you can teach people face to face. On websites, they generally come to do something else than to be educated.

  20. Perhaps I was a little unclear in my previous comment when I said, “if a person is truly having difficulty viewing web pages, then they will have taken the time already to adjust their browser settings.”

    What I meant was that people who regularly make use of the Internet and have a disability will have found a method of viewing the most common websites (which, sadly, do not take accessbility to heart). That’s why the average, non-impaired web user does not know about these settings — they’ve never needed them!

    Added accessibility widgets to a website is like replacing the steps to a building with a ramp when there’s already a ramp just down the sidewalk. Just because most non-disabled people have never noticed the ramp doesn’t mean that handicapped visitors (that use the building regularly) don’t know about it.

  21. Zephyr wrote:

    Education is best suited for environments where you can teach people face to face. On websites, they generally come to do something else than to be educated.

    I agree - when it comes to education about how their own browsers are working. The good thing though is that most people only have to learn that once, whereafter they can go on to learn something from whatever site they choose to visit.

    When it comes to those widgets with ‘in-page duplications of browsers basic functionality’, it is often a bit more complicated. Those widgets don’t look the same, they don’t always work the same way, and they don’t always deliver the same - from site to site. So now even slightly more educated users may become a bit confused and loose focus on the ‘something else’ they came for, as they surf from site to site.

    As I wrote in my earlier comment:

    Alternative style widgets as additions are fine with me.

    I see no need for most of them, but if the designer wants them…

    It is when those ‘additions’ are used as substitutes for the browsers own options, and web developers don’t test that the methods they use work well for users who are educated enough to have set their own preferences, that the whole “widgetry” may become a usability-barrier - and that’s not fine with me.

    Example: how many web developers use ‘font-size: 62.5%’ on body because it is a practical value to size up from, without realizing that a browser-option like ‘minimum font size = 16px’ will blow up that font-size in Firefox and Opera, and the resulting value is inherited? How large is ‘font-size: 1.6em’ with ‘font-size: 16px’ on body? How many web developers have tested what font-sizes their pages are rendered at with such an option in those browsers? (Safari does it differently, so no need/use to test in that one.)

    The example above doesn’t hurt readability as long as the page-layout can handle the “pretty large” text-size, but that’s not always the case since too many web developers rely on their own widgets as the only option.

    So, web developers may add as many widgets as they like if they think it’s “necessary” - even if I disagree. However, they should make sure everything works just as well with regular browser-options so they don’t hurt the ‘educated user’ and all the users who want to become ‘educated’. The ‘education-process’ may take a lot longer if browser-options are counteracted by web developers.

  22. With regard to educating users, the BBC’s My Web My Way site explains the many ways users can change their browser, computer, keyboard and mouse settings to make the web more accessible.

    As for Glaucoma.org’s accessibility statement, I find it a bit waffley and “philosophical”. It rather runs counter to Gez Lemon’s suggestions of setting aside all the technical/standards stuff, and concentrating on the accessibility features available on the site.

  23. May 12, 2006 by Zephyr

    Georg, well put.

    Respecting browser settings is crucial to allow the ‘educated’ to be able to benefit from their personal settings. It’s also needed to allow the ‘others’ to become educated and actual users of these features, and that only happens if it’s dependable; does it work on every site? But given the problem of educating people on these browser features, alternatives, such as widgets within the website, might be necessary.

    This made me think: The widgets used on websites for increasing text size look a lot like toolbar buttons. They make ‘increase text size’ options more visible, yet my browser (Firefox) doesn’t come with these toolbar buttons, nor can I set them to appear. It shouldn’t be too difficult to create understandable icons for this. Instead I have to go into settings, a cascading menu or use some arcane key combination. Odd.

  24. September 29, 2006 by NeoGeo

    I agree that site-based widgets are not as good as the user knowing how to configure their browsing setup. But I’m not sure educating them by telling them to go edit a css style sheet is that useful either. Linking to a site that has some pre-configured css style sheets would be excellent. A contrast specific css sheet, a size specific sheet and specific background/text combinations would make a nice link.

    Now an web-app that could generate the CSS file based upon a host of on page widgets would make a really cool accesibility tool, rather than getting every site to provide it’s own mix of tools. The user could configure a design page with the onscreen widgets, then the app would generate the custom style sheet so the user can download it and reset their browser.

  25. September 29, 2006 by NeoGeo

    Does anybody know of a site that has some pre-defined accessibility specific downloadable css style sheets for browsers? I could not find any.

Comments are disabled for this post (read why), but if you have spotted an error or have additional info that you think should be in this post, feel free to contact me.