[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