RE: SC to cover changing widget - expanding

Hello,
I agree with: Some said “as long as the extra content appears after the control that generated it, it’s ok.” with a rider:
The page does not refresh / reload causing loss of focus or the focus is re-positioned to where it should be. Usually if appearance of new form controls is dependent on choice from  checkbox / radio/ SELECT and the tab flow is managed logically, it poses no problem.
Another scenario is a set of links like a tree menu and when one is expanded a set of child links is presented below it. Here 4.1.2 will also apply: one needs to know it is a menu-link and whether it is expanded /collapsed. Also oned needs to be able to identify the child links as a group... their start and finish.
Yet in other cases, it is necessary to notify the user of the behavior. Usually if content (like chart or a data table or other stuff that does not get focus is present below the UI element and this content changes based on the choice made via the UI element, the user should be notified about the behavior. For instance, if data displayed relates to a province or state selected from a drop down and there is no Go button after the drop down. This may be done with page refresh or without.
Sailesh Panchang

--- On Fri, 7/29/11, David MacDonald <david100@sympatico.ca> wrote:

From: David MacDonald <david100@sympatico.ca>
Subject: RE: SC to cover changing widget - expanding
To: "'WCAG'" <w3c-wai-gl@w3.org>, jason@jasonjgw.net, adam.solomon2@gmail.com
Cc: "'adam solomon'" <adam.solomon2@gmail.com>
Date: Friday, July 29, 2011, 9:45 AM

I’m running across a lot of expanding pages during evaluations these days. The user checks a box (or a selection on a drop down). Suddenly the page expands with a bunch of extra content. We spoke briefly about it on the call yesterday and I didn’t feel there was much consensus on whether this is a failure or not.  Some said “as long as the extra content appears after the control that generated it, it’s ok.”Others said “as long as there is a notification on the control about the behaviour”Others said “we do not have a clear definition of what a ‘change of context is’”  When I brought up the question about a month ago, Jason said “these both seem to be cases in which 4.1.2 is not met. Certainly, it is exactly this kind of problem that 4.1.2 was intended to address, as I recall.”4.1.2 Name, Role, Value: ...and notification of changes to these items is available to user agents, including assistive technologies. (Level A)   I
 think “notification of changes to these items is available to user agents” covers it... but if the new values are available to the DOM, is there any requirement to “notify” the user, or warn them? So what do we think is necessary (sufficient) for these expanding widgets:  1) add title=”checking this will add content below”2) Or put aria-live on the new content.(Or both)3) Or is even a failure... if the focus does not change and the new content is below the control?  Let’s come to a consensus, because these types of controls are all over the place, and we have no clear direction currently.  David MacDonaldwww.eramp.com       From: w3c-wai-gl-request@w3.org [mailto:w3c-wai-gl-request@w3.org] On Behalf Of Sailesh Panchang
Sent: June-24-11 10:46 AM
To: 'David MacDonald'; 'WCAG'; jason@jasonjgw.net; adam.solomon2@gmail.com
Subject: 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 Panchangwww.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 AMWe 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 tree2) 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 checked3.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, 29 July 2011 17:17:33 UTC