html widget - meaningful sequence

Following is a copy of an item from the webaim mailing list regarding a
fairly common html widget for moving entries back and forth between two
lists. I would appreciate any input from you guys as to whether we are in
violation of WCAG on any criterion. In regard to Sailesh's comment, there
are descriptive headers at the top of each list. Still, I am worried he made
a valid point on 2.4.3.

Thanks in advance.

adam solomon to WebAIM
show details Jan 27 (3 days ago)

An example:
Html consists of two lists of names with corresponding checkboxes - the
first list consists of potential people who can be added to the second list.
The second list are the people who have already been added. The two lists
come one after another in the DOM, yet they are visually presented
side-by-side by css float. In between the two lists, both in the DOM and
visually are two buttons - one button adds an entry from the first list to
the second list, while the other button causes an entry already added to the
second list to be removed from it and placed back in the first list. I was
concerned about the fact that the remove button, which would need to be
clicked after choosing from the second list, comes before that list in the
DOM. In order to clarify things, we added a short explanation of how the
whole thing works. Technically, the DOM sequence matches the visual
sequence, yet visually it is easier to pick up on the fact that the buttons
"drag" names from one list to the other. The client is unwilling to change
the position of the buttons. Are we in violation of WCAG here, specifically
1.3.2<http://www.w3.org/TR/2010/NOTE-UNDERSTANDING-WCAG20-20101014/content-structure-separation-sequence.html>,
or any other criterion? More importantly, does a screen reader user stand a
reasonable chance to understand how to operate the lists?

Thanks in advance for any feedback.

-- 
adam solomon

On Thu, Jan 27, 2011 at 7:26 PM, Steve Green <steve.green@labscape.co.uk>wrote:

> I am sure we tested exactly this construction with a screen reader user
> some
> years ago, and that they coped ok. The WCAG say that the content has to be
> understandable, not that it has to be understandable the first time it is
> read in a linearised manner. I'm not sure there is a better way to
> construct
> this type of content than what you already have.
>
> Your website is very similar to an FTP client insofar as they also have two
> lists of items and two buttons to move them from one side to the other.
> Plenty of screen reader users manage to use this functionality with no
> difficulty.
>
> Steve Green
> Director
> Test Partners Ltd
>
>
>  adam solomon to WebAIM
> show details Jan 27 (3 days ago)
>
>  I agree. I do think that it is not the best way to do it but I think we
> have to let it pass as is. Thanks for the response.
> - Show quoted text -
>
> |
Sailesh Panchang to WebAIM
show details Jan 28 (2 days ago)

Certainly adding a brief explanation to aid non-visual users is one
way to help this group.
But is there some heading text before each list that suggests what the
list contains? Something to say that the first is a list of pending /
pottential items or members that can be added and the next one is a
list of items currently added or a list of current membership .
But the buttons should certainly be in the correct logical sequence if
one is tabbing through the content. Else it could trigger   SC 2.4.3.
And the purpose of the buttons too should be clearer.  Add (or Remove)
to/from what? In the context of this content it could trigger SC
2.4.6.  For e.g. "Add to selection"  or "Add a member" could be the
first button, followed by heading for the next list, then list #2 and
then button#2 that says "Remove from selection" or "Delete Member".
Aesthetically it may make sense to place the buttons between the
lists, but even visually or logically, is it consistent?The first
button is after the first list but the second one is before the second
list?
Thanks,
Sailesh Panchang
www.deque.com
- Show quoted text -