RE: SC to cover changing widget - expanding

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 <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#ensure-compat-rsv>  Name, Role, Value: ...and notification of changes to these items is available to  <http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#useragentdef> user agents, including  <http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#atdef> 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 MacDonald

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