- From: Adam Solomon <adam.solomon2@gmail.com>
- Date: Fri, 24 Jun 2011 14:40:56 +0300
- To: "'David MacDonald'" <david100@sympatico.ca>, "'WCAG'" <w3c-wai-gl@w3.org>, <jason@jasonjgw.net>
- Message-ID: <4e0477cf.9c47df0a.6abd.ffff9134@mx.google.com>
We have grappled with similar issues. Just the other day a developer asked me about just such a problem. He had the text of the checkbox as a link and the onclick of the link opened up the text (which was placed immediately after the link). The link text did not indicate that the click opened up new text. It was just a checkbox label. Aside from adding a title attribute to the link (which is only advisory as I recall) I thought of two solutions - one was to have a sentence at the beginning of the form indicating that clicking the links opened up new text. The other was to have the text open up on link focus - that way as soon as the user got to the link text he would see the opened text without even having to know that something was opened. Another example (though not exactly the same as above) is an alert or validation div which opens up on the client (not the browser alert. Today people want custom designed divs instead). Most pages don't send focus to the new popup - but it certainly is required. How to do this in a supported fashion is far from trivial. I have been planning for a while to suggest that we write up techniques for these kinds of situations. Most pages don't get this stuff right and don't even know that there is a problem. 4.1.2, as Jason pointed out, indeed sounds like the most appropriate candidate. I think we also need techniques for widgets, such as autocomplete and multiselect, which are rampant on the web and about as orderly as the wild west. Steps wizard and collapsible panel are other common widgets which should be documented. From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of David MacDonald Sent: Friday, June 24, 2011 2:00 PM To: 'WCAG' Subject: SC to cover changing widget How have others on the group been mapping widgets that update and don't notify the AT of their updates...There are two scenarios I run into often. 1) there is a checkbox that when checked opens up a box below it full of information... like an expandable tree 2) there is a notification about something, and it is inserted via JavaScript into the page without notifying the user WAI ARIA addresses these issues, but I'm wondering which SC violations others have been using to require these fixes. 1.3.1 (info & relationships) is sort of a mapping... because the information is in appropriately related to its heading (but it's kind of a stretch) 2.1.1 (keyboard) is sort of a mapping because the information is not available to the user on page load (but it is available after the change) 1.3.2 (meaningful sequence) is sort of a mapping because the sequence of the code is different from the page on page load, as in the case of #1 where the CSS is hidden until the checkbox is checked 3.3.1 (error identification) could apply if it's an error message I kind of will we had a SC that said something like. SC XXXX: User is notified of changes or updates to sections of the page and is able to focus on controls in the changed region within 3 keystrokes Or something like that. Hey wcag 3....??? Can someone give me a good mapping in WCAG 2....
Received on Friday, 24 June 2011 11:41:33 UTC