RE: SC to cover changing widget

Well I also make the same suggestions as Adam notes below in these circumstances.
But I do not think additional SCs are needed in these situations. Often more than one SC may be violated and one has to implement a solution that will address the requirements of multiple SCs that are triggered   .
If the linked text does not clearly say what will happen when the link is activated thenit fails SC 2.4.4. Besides advisory text  via title attribute that is available on mouseover, one may include off-screen text. Visible text notification placed before the link is another solution. An aria-tooltip that is available visually and to AT when link gets focus is another method.  
If it is a form label, SC 3.3.2 will apply and maybe SC 2.4.6. 
In some of these cases the UI element may also cause change of context and trigger SC 3.2.2. 
What about tabs? Links are often styled to appear and function like tabs. In this case merely indicating the role (tab) and its state (whether it is active / selected) will convey to the user that the content in the associated tab-container relates to the selected tab and changes with tab selection. SC 4.1.2 applies here.  Maybe an appropriate section header placed at the start of the container should be marked up as a heading h<n> tag (SC 1.3.1).
  A single SC will not address all accessibility challenges of a situation. So it is imperative that all applicable ones are identified during accessibility evaluation. And that is challenging. 
Sailesh Panchang
www.deque.com
 

--- On Fri, 6/24/11, Adam Solomon <adam.solomon2@gmail.com> wrote:


From: Adam Solomon <adam.solomon2@gmail.com>
Subject: RE: SC to cover changing widget
To: "'David MacDonald'" <david100@sympatico.ca>, "'WCAG'" <w3c-wai-gl@w3.org>, jason@jasonjgw.net
Date: Friday, June 24, 2011, 7:40 AM








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....