Web Accessibility

A huge problem with almost every CMS in existence is the extremely poor quality of the code produced by their WYSIWYG editors.

Since visual gadgetry like WYSIWYG editors sells, every CMS has to have one.

That, in turn, makes it necessary for Web professionals who want to reduce the risk of clients unknowingly ruining the website’s semantics and accessibility to disable features and implement more or less advanced code cleaning procedures. It is a mess.

New Dutch accessibility law.

A few highlights of what is required: separate structure from presentation do not use deprecated markup when creating a new website, use a Strict doctype use progressive enhancement create semantic class and id values use the W3C DOM when scripting script-only links must be generated by JavaScript do not use the alt attribute to create tooltips

Well, it turns out you can do that. From The LABEL element in the HTML 4.01 specification: The LABEL element may be used to attach information to controls. Each LABEL element is associated with exactly one form control. The for attribute associates a label with another control explicitly: the value of the for attribute must be the same as the value of the id attribute of the associated control element. More than one LABEL may be associated with the same control by creating multiple references via the for attribute. Sounds great, doesn’t it? A quick check in graphical web browsers shows that they associate multiple labels with the input field (as evidenced by the input field gaining focus when either label is clicked). But what about screen readers? It would be so useful if this would work… Unfortunately, and perhaps unsurprisingly, it looks like it doesn’t quite work as well as you’d hope. I mentioned this briefly in Use the label element to make your HTML forms accessible, but I think it’s worth bringing up again since full support for multiple labels would help us make forms more accessible to screen reader users while keeping visual designers happy. I am far from an expert user when it comes to screen readers, but I’ve done some limited testing with mostly disappointing results. Apple VoiceOver does not recognise more than one label element associated with a form control and reads only the label that comes first in the document’s source order. JAWS and Window-Eyes both do the opposite and read only the last label when an input field gains focus. The only screen reader of those that I tested that does handle multiple labels is Fire Vox. The exact results may obviously depend on user configuration and reading modes, and there may be other screen readers that get it right, but these results indicate that screen reader behaviour is too inconsistent for multiple labels to be a reliable technique.

Some tips from the article include:Fieldset and Legend tags must be used together, never independently of each other.Keep the content of the Legend tag brief (the Legend may be read when each of the controls contained in a Fieldset receive focus.)In Windows Eyes, the option to read the Legend tag is off by default.Fieldsets may be nested.

A screen reader simply enables a blind person to use the applications and operating system on a computer without sight by converting on-screen text into a Braille or spoken format. Intelligent screen readers like Window-Eyes deliver information in a linear format, interpret the active window, read complex web pages and perform many other advanced functions.

Although scripting is, by far, the number one enhancement found in this latest Window-Eyes release, other new features are noteworthy in their own right. Geoffray tells us that Window-Eyes is now 100 percent Unicode compliant. This enables access to foreign language text, certain PDF documents not previously readable, Microsoft Word’s smart quoting feature and any other situation where use of special symbols is required. Intelligent place markers may now be defined on dynamic web pages delivering quick access to a specific area of the page based not only on its virtual line number, but also on the text at the cursor. A new Eloquence speech synthesizer, access to the Firefox 3.0 web browser, support for the public beta version of Internet Explorer 8.0

And that leads me to three great videos posted on the Yahoo! User Interface Blog: In Introduction to Screen Readers, Yahoo! engineer Victor Tsaran talks about who will be likely to use a screen reader, how screen readers work, and how they can be used to interact with the computer desktop and to browse web sites. In Introduction to Screen Magnifiers, Karo Caran shows how the screen magnifier ZoomText is used to make the computer desktop and web sites readable to people with reduced vision. And finally, in From the Mouth of a Screenreader, Doug Geoffray from GW Micro (Window-Eyes vendor) talks about the history of screen reading software and how they analyse what is displayed on the screen in order to speak it to the user.

Any web developer who has created a reasonably complex form is probably aware of the concept of multiple select elements that are connected – choosing something from one select box either makes a new select box appear or changes the options of one that is already visible. There are usually two problems with this approach. One is that most implementations are completely dependent on JavaScript being available. Often there either is no submit button at all, or there is a submit button but without JavaScript there is no way to access the options that appear only as a result of changing the first select box. The other problem is that in some browsers, using the cursor keys to change the selected option triggers the onchange event immediately, so you can never get past the first option unless you know how to use your keyboard to display all options. I normally work around these problems by requiring users to submit the form to get the next set of options from the server. Obviously that isn’t an ideal solution either. So what other options do we have? One option that looks promising is described by Christian Heilmann in Unobtrusive connected select boxes - yet another solution approach. It involves using optgroup elements to create a two-level select box, which is then split into two separate select boxes if JavaScript is available. Neat. The solution Chris describes solves (or at least mitigates) the keyboard access problem since it doesn’t reload the page when the onchange event is triggered. And if JavaScript is unavailable, there is a single select box with option groups. The catch is that nested optgroup elements are not allowed in current versions of HTML, so this will not work when more than two connected select boxes are needed. Nested optgroup elements are allowed in the current Web Forms 2.0 Working Draft, so I guess there is a reasonable chance of that change making it into HTML 5.

For anyone who hasn’t heard of Fire Vox, it is a free, open source screen reader extension for Firefox that works on Windows, Mac OS X, and Linux. Among other things it has support for WAI-ARIA and the CSS3 Speech Module, and is a good alternative to VoiceOver if you’re on a Mac and need a screen reader for web browsing (or testing).

For developers Fire Vox makes it easy to check how their sites work in a screen reader. Sure, it’s just one of several available screen readers, but this one is free and cross-platform. In other words there is no reason for you not to have it installed, so grab a copy right now.

United Nations Global Audit of Web Accessibility, conducted by accessibility agency Nomensa on behalf of the United Nations, shows that 97 percent of websites fail to meet the most basic accessibility requirements.

A story on the BBC News website, ‘Most websites’ failing disabled, notes that 93 percent did not provide alternative text for all images, 73 percent relied on JavaScript for important functionality, and 98 percent of the sites did not use valid markup.