- From: Phill Jenkins <pjenkins@us.ibm.com>
- Date: Fri, 5 Dec 2003 12:51:26 -0600
- To: w3c-wai-ig@w3.org
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