Note: I highly recommend reading the comments on this post. Jared Smith from WebAIM (Web Accessibility in Mind) makes some very valuable comments on these issues which I’ve responded to.
In a word, options. Building an accessible website doesn’t mean building a visual experience which will work perfectly for all audience. It doesn’t mean writing content that everybody will be able to read equally. What it means is creating an experience where users can alter their experience as they choose so they can best experience the site. Everything from font size, to color contrast, to color choice, to accesskey assignments, to the content itself can be configurable.
Naturally, this is a best case scenario. There are problems inherent in making every aspect of a site configurable, as well. When the options themselves become overwhelming, you’re once again erecting a barrier to accessibility.
So you need to strike a balance. Studying your website’s user base is a good place to start — although you can’t entirely eliminate any specific audience by market research, you can make a healthy start at prioritizing. The first place which will usually be compromised is in writing content. This is the most specific targeting element: the only one which you can honestly be certain of. If you’re publishing an informational site about the engineering of widgets, you can be reasonably confident that your audience are reasonably knowledgeable about engineering and about widgets. You can write your content to the level required for widget engineers, although you may well want to include a glossary and some basic tutorials for the curious but less knowledgeable.
You can’t, however, have any idea whether your audience includes the dyslexic, the color blind, the mobility impaired, or the elderly. So compromising on issues other than content is a very poor decision.
Even if you’ve conscientiously prepared your site to be a solid middle ground for accessibility you can’t be at all confident that you’ve provided for every audience. Making alternate options available remains a high priority.
Providing more options for this site is something I’m working on: right now the site has a pretty high contrast. The bright white background can certainly be rather glaring. I also haven’t provided any means to choose access keys: a very worthwhile access aid when they aren’t set in advance. My style switcher is very limited: the low contrast version of the site is only usable within the non-blog portions of the site. (WordPress isn’t picking up the cookie…anybody know how to do that?).
Good accessibility is more than just a design issue or conformance to standards: it’s a matter of user choices. Building an accessible design needs to mean creating more than just one design: you need to build the default site design, which is all most users will ever see, but you should also consider alternate contrast versions, different font sizes, and alternate access methods.
Just some food for thought.
Relevant links:
- PHP (Hypertext PreProcessing) Style Sheet Switcher – 456 Berea Street
- Dynamic Style Sheet Switcher – Juicy Studio
Note Gez Lemon’s concerns about providing alternate style options. They are worth noticing.
- PHP Style Switcher – Mike Cherim
This style switcher makes a point to check whether cookies are being accepted before offering the functionality, preventing fruitless dysfunctionality, and also takes steps to prevent cross-site scripting.
- User defined Accesskeys (ASP) – Thierry Koblentz
- User defined Accesskeys (PHP) – Juicy Studio
Hip Hop Klamotten
I once responded to someone on the WSG list who wanted to know if they had done well with their site in regards to accessibility. They hadn’t in my opinion so I told them as much. They provided all sorts of available user options was their argument. The trouble is that the default state was pretty unfriendly, and all the provided options where hard to get to (links at the end of the page).
In this case the text was tiny and the contrast extremely low. A person with a vision handicap would have had a heck of a time even finding the optional styles. I’d venture to guess they wouldn’t have even hunted for them and would have just left the site.
No name provided.
This article is what I was looking for…thanks!
Comment edited to replace name keywords.
Joe Dolson
Saw your post, in fact, Tom…already commented on it! 🙂 Thanks!
Tom
Hi Joe,
great post. This is a bit of a manual trackback, possibly a trekback since the computer didn’t do it automagically for me 🙂
After reading I wrote a post this exploring this a bit further on my blog.
Cheers,
Tom
Joe Dolson
Thanks for pointing that out, Jared – it’s a slightly different perspective. If you try and expand the options set to provide whatever the visitor might want, you’re definitely going to far for effective accessibility. Providing options should be limited to what a visitor might need if you choose to provide them.
Jared Smith
Here’s another blog entry that adds a bit of insight into providing choices to users.
Joe Dolson
Exactly what Jared and I were discussing in the first comments: the critical necessity of providing a default state which is maximally accessible. After all, all the settings changes in the world are irrelevant if the site isn’t accessible enough for those settings to be used!
Thanks, Mike!
Mike Cherim
Allowing browser customizations by not fixing and overriding too much is a requirement, providing extra customizations is a plus, but the default state should be of reasonable accessibility. I once responded to someone on the WSG list who wanted to know if they had done well with their site in regards to accessibility. They hadn’t in my opinion so I told them as much. They provided all sorts of available user options was their argument. The trouble is that the default state was pretty unfriendly, and all the provided options where hard to get to (links at the end of the page). In this case the text was tiny and the contrast extremely low. A person with a vision handicap would have had a heck of a time even finding the optional styles. I’d venture to guess they wouldn’t have even hunted for them and would have just left the site.
By the way, Joe. Much better comments textarea. Me likey!
Joe Dolson
That is an impressive example of a preferences page: unfortunate that it doesn’t allow control of accesskeys, but otherwise: wow!
Check it out: Swedish Government: Customize your Preferences
Some of the advantages to it that I noticed immediately was the natural language mode and the instant preview: the interface makes it very easy to see a) your current settings, b) the result of your changes, c) how to replace the default settings. It’s not invasive, since the options are exactly what they should be: optional.
And they don’t prevent you in any way from using your user agent to alter your view.
Thanks for that example, Jack. I’ve meant to look at it for a while, just hadn’t gotten around to it…
JackP
Get that “customise your preferences” from the English language version of the Swedish Government offices in here. That’s one of the best customisation examples I’ve seen as an exemplar of how to offer choice to your users. If you can’t find it, drop me a line and I’ll send you the URL (Uniform Resource Locator).
Joe Dolson
Isn’t it great how we all love each other? 😀
But seriously, you’re right: in my original post, I emphasized the value of options without spending sufficient time mentioning the fact that they are in NO way a substitute for a well designed website, or in discussing the flaws inherent in using external solutions to solve problems which are solvable in other ways.
Your comments for this post are incredibly valuable: and I’ve added a comment in the original text strongly recommending that visitors read the comments, since they add such a significant value to the post.
Thanks,
Joe
Jared Smith
Thanks! And I agree with you. So we’re all in agreement then. :=) I think we’re saying the same thing in different ways. Yes, options can be useful. Your suggestion of making them very unobtrusive and perhaps on an “accessibility settings” page is an excellent one. With the explosion of user interface and accessibility widgets that are showing up lately (the three A’s for font sizing is the most notable – and perhaps the most confusing), I fear that developer’s are providing them only because they can without understanding the implications. I mostly want to avoid the notion that I’m seeing lately of, “I’ll use tiny fonts and terrible contrast, but it’s not an issue because I provide options for the user to fix these things.”
If the site is well designed and accessible to begin with, the additional options will probably be unnecessary for those that require accessibility customizations because they’ll have those customizations through their user agent already (assuming you haven’t broken this functionality somehow). Still, they may also benefit some users, especially those that may not be aware of the customization options their browsers or assistive technologies provide. So as you say, striking a balance really is key.
Joe Dolson
Hi, Jared – I’m glad to hear from you. I really admire the work that WebAIM does and am thrilled that you’ve stopped by to make your comments. In answer to your points, to a degree, I agree with you. However, the one core difference is that I don’t believe it’s possible to build a website which provides ideal accessibility for all parties: I will never require that options be set in order to make a site accessible. A site should be as accessible as possible in its default state, but provide additional options to refine the options for those who need them.
You’re absolutely right that teaching users how to best make use of the tools they already have (browser features, screen magnifiers, etc.) is an ideal approach. However, I don’t perceive offering additional settings to be a huge barrier for a developer. They shouldn’t be necessary: but they’re still useful.
You use the example of overly high contrast: however, low contrast can also be a problem for some users. I sincerely believe that I’ve found a decent middle ground: but I can’t know this without extensive user testing (and I don’t have the resources for that.) There are no empirical studies on color contrast which convey the kind of detail I’d need to justify a specific contrast level.
I may well be crossing the line towards bowing to user “preferences”, rather than user “needs” – but I’m not unwilling to make that extra effort, at least to some degree.
Is that true? If no options are required to be set in order to have a highly accessible, usable website, is there any real barrier? These controls don’t need to be on every page; they can be fairly unobtrusive. If somebody really needs them, they’ll look for them (and, if placed on a page such as “user settings” or roughly equivalent, they should find them). If they don’t need them, they won’t look: and it won’t be a problem.
I think that having up-front options such as text resizing widgets, font selectors, color choices, etc., can be overwhelming and unnecessary. But providing a page where users can choose their options if desired is not a bad thing. As I said above, striking a balance is challenging: many of the site options widgets you’ve mentioned are serious problems. Forcing users to jump hoops to access a site, implying that they “need” to change settings to use the site, employing scripting methods which may break the widget itself – these are all major mistakes.
Thanks for your input – I’m really glad to have this dialogue.
Jared Smith
While I think that some options are sometimes good, I am of the opinion that solving accessibility issues by providing accessibility options is a poor choice. In nearly all of the testing that we have done on accessibility widgets and options, the resounding response has been that people with disabilities don’t like or even use them. I tend to prescribe to the “User preferences are for sissies” camp. If the accessibility of your site does not stand up in its default state, then you’ve probably done something wrong.
Providing interface options almost always involves a great amount of overhead for ALL users, when those options MAY only benefit one small group of users. You use the example that your site may have too high of contrast. So fix it! Providing a user option to fix your design problem doesn’t really solve the problem – it introduces new ones. In this case, it is only of use to visual users that may be impacted by contrast issues, it introduces additional navigation and overhead for keyboard and screen reader users, it’s a pain in the rear to program, it may require scripting (thus won’t work on many devices), etc. Not to mention the cognitive overhead issues of all of these display widgets. In most cases, one can make the argument that providing an accessibility option might help 1 user, but will in turn disadvantage 100.
If a user absolutely requires a certain color scheme or contrast or font size or keyboard navigation or whatever, then that user will come to the table with technology that will provide these options anyways.
If your text size is too small for many users, increase the size. If I, as a user, need large text, your font resizing widget will be useless to me because I’ll already have the font size bumped up in my user agent preferences. See where I’m going with this?
The burden should not be on developers to provide all of these options. The developer’s burden should be, however, that your site does not prohibit or exclude users that require this customization (something that your site does very well as is).