[thelist] Accessibility, Screen Readers and Progressive Enhancement.

Benjamin Hawkes-Lewis bhawkeslewis at googlemail.com
Mon Sep 29 14:45:08 CDT 2008


Bill Moseley wrote:
> I have a form with a country drop down list.  The vast majority of our
> users are in the United States.  If the user selects United States
> from the drop down we collect additional fields than with other
> countries.
> 
> We use Javascript to display or hide fields based on the selected
> country.
> 
> Without javascript we show all fields -- that is, on page load we hide
> the fields and then once the country has been selected we show the
> fields we need.  So, although there will be extra fields displayed,
> the form still works without javascript.

Have you considered beginning with a simple country select and submit in 
the JS-less state? When the user selects a country and submits the form, 
the form is returned with the relevant fields added, if USA was 
selected. This could be progressively enhanced to add the US-specific 
fields dynamically. That way, while the JS-enhanced experience remains 
the same, nobody gets troubled by irrelevant fields.

 > One minor annoyance with javascript enabled is that when the page
 > first renders we see all the fields for a short amount of time.  We
 > use YUI and its onDOMReady() method to hide the fields.

 > Is there a
 > better (faster) way to use javascript to set the elements to
 > display:none before rendering?

Well, you can take the risky strategy and try to detect all the 
functionality your JS will need in a SCRIPT block shortly after the BODY 
element. If everything your JS will need is present, then you can add a 
class of 'js' to the BODY element. Then in your CSS you can write:

.js WHATEVER {
    display: none;
}

That way, the style will be applied as soon as WHATEVER is parsed into 
the DOM, without any additional JS being executed.

The danger of evading flash of unstyled content in this way is that your 
JS might fail, and users might be left unable to guess what's wrong.

In general, consider other performance enhancements before compromising 
on robustness:

http://developer.yahoo.com/performance/

 > Second, how will screen readers behave with this kind of setup?  Will
 > they not read the display:none fields?

Typical browser/screen-reader combinations will not read content styled 
"display: none;" although there are certain exceptions. JAWS will now 
read a span with display: none; inside a link, for example.

However, if you're concerned about accessibility, I'd be very wary of 
"display: none;". In addition to its unpredictability with regards to 
totally blind users, "display: none;" will fail to hide content if 
publisher CSS is not applied or overridden (e.g. by a low-vision user 
who needs their own custom styles).

HTML5 proposes an element for storing unused clumps of DOM (currently 
called "irrelevant"). I don't think display: none; is a good substitute 
for such a feature.

I follow a simple rule of thumb: if content should be presented to a 
user in any output media, it should be in the HTML DOM. If something 
should not be presented to the user, it should be outside the HTML DOM. 
So I would remove and readd the elements in question from the DOM, not 
merely flip their styles.

You could, I suppose, combine the two for maximum speed (hide it, then 
remove it; show it, then add it).

With regards to the particular question of whether a screen reader would 
pick up a change in a CSS display value, that's hard to answer without 
testing the case in question. Browser/screen-reader setups are often 
presenting users with some type of virtual buffer - a sort of cached 
"mental image" - of the page. Not all changes trigger updates to such 
buffers. Such a setup might still read content that was styled to 
display but had been changed to "display: none;" if nothing triggered a 
virtual buffer update. Worse still, such a setup might not read content 
that was styled "display: none;" but was changed to be displayed.

It's also important to note that just because a buffer is updated 
doesn't mean that the user is notified that there has been a change. One 
of the major innovations of the emerging WAI-ARIA drafts and 
experimental implementations is the concept of "live region" 
notifications, which can alert users to changes that have happened on 
the page. There's an introduction to this stuff at:

http://dev.opera.com/articles/view/introduction-to-wai-aria/

The problem of updates and notifications is, I admit, also a problem 
with removing and re-adding elements to the DOM.

There's some discussion of these issues at:

http://juicystudio.com/article/making-ajax-work-with-screen-readers.php

http://juicystudio.com/article/improving-ajax-applications-for-jaws-users.php

http://www.gwmicro.com/blog/index.php/all/2008/01/21/regarding_web_based_dynamic_content

http://www.paciellogroup.com/blog/?p=65

http://www.marcozehe.de/2008/04/29/are-ajax-and-accessibility-mutually-exclusive/

Nobody, as far as I know, has created a comprehensive set of test cases 
for what does and does not trigger mental image updates with various 
browser/AT combinations. (It's been somewhere on my Todo List of 
Infinite Length for yonks now, but there we go.)

My _guess_ (and it is only that) is that screen reader users would be in 
some sort of forms mode (or the equivalent) when interacting with your 
form and the buffer would be updated in time for them to tab to the next 
field. But if you're unsure whether the virtual buffer gets updated in 
your case, I recommend creating a test case and pasting it to a 
discussion group where real users can give you feedback on whether your 
form works for them. I listed a selection of relevant mailing lists and 
forums where you can find real users at:

http://dev.opera.com/articles/view/26-accessibility-testing/#recruitingtesters

It's a thorny area; hope that helps a bit.

--
Benjamin Hawkes-Lewis



More information about the thelist mailing list