RE: Remote Scripting -- Compliant with 508 and WCAG?

RRust said:
>In my mind, there is no way to identify the new information with
>functional text.
>
>This may not hold true in all instances, but in our case, most of the
>things we would be doing is populating drop-down lists, based on a
>user-selected parameter or redisplaying data in a table. In some cases,
>we have had clients request that checking a checkbox or radio button
>automatically commit data, rather than clicking a button and submitting
>data.

The new data displayed in the table ** is**  "functional text" - because
the assistive technology, such as a screen reader, can read the new text /
content in the table just like it could read the old text / content.  This
can also be true with the drop-down lists, whether it is a client side
change of the <select menu> options or a similar list of links that now
appear when an accessible event occurs.

Things to remember is
1. That the user of the AT and/or browser needs to be able to trigger the
event, e.g. onFocus is keyboard accessible.
2. That the AT and/or browser "gets" the change. e.g., the browser+AT gets
notified that the DOM changed.
3. and that the changed DOM/content (including html, text, objects, etc.)
is "functional" in the sense that it is "available to" or "renderable by"
the AT+browser. For example, a screen reader speaks the functional text of
a web page, if you're sighted you can see the new text - its functional
because it can be spoken, seen, rendered.

One of the complexities I have seen is where the content (aka functional
text) in visually next to something that makes sense, but happens to be so
far down in the code (DOM) that the screen reader doesn't present it to the
user until found at the bottom of the content.  When there is a visual
connection, but no connection semantically or in the order in the DOM, then
it could be considered nonfunctional. For example, the new list of links
are there at the bottom of the page, the screen reader reads them, but as a
screen reader user I have no idea why they are now there.  If they are now
there because I had keyboard focus on a link at the beginning of the page,
the author needs to explain that to me somewhere, maybe in the help.

When it is a real select menu that changes by now having new or additional
options, you need some helpful way of telling the user where and why that
occurred.  For example, explain in the help section that by pressing a
radio button for a location, only those options applicable to that location
will now be available to select in the menu.  This is handled by the
AT+browser if it's all client side.  If the data has to be gathered from a
server, which causes a doc.write, then the AT + browser thinks the whole
new page has been written and starts at the top, not realizing (unless
you're sighted) that nothing has changed except the options in the select
menu.  This is not a problem for small or short pages, but may require more
explanation and some more skip links to be able to get the user back to
where they were before the doc.write made them start back at the top.

These are similar principles to making any GUI application (Web based,
Windows based, Gnome based, etc.) accessible and usable by an AT user.

Regards,
Phill Jenkins

Received on Friday, 5 December 2003 13:51:32 UTC