W3C home > Mailing lists > Public > w3c-wai-gl@w3.org > April to June 2011

RE: SC to cover changing widget

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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 24 June 2011 11:41:34 GMT