E-mail List Archives
Thread: 1.3.2 meaningful sequence
Number of posts in this thread: 4 (In chronological order)
From: adam solomon
Date: Thu, Jan 27 2011 8:09AM
Subject: 1.3.2 meaningful sequence
No previous message | Next message →
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
linkedin <http://il.linkedin.com/pub/adam-solomon/24/449/a4>
blogix <http://adam.blogix.co.il/>
From: Steve Green
Date: Thu, Jan 27 2011 10:27AM
Subject: Re: 1.3.2 meaningful sequence
← Previous message | Next message →
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
From: adam solomon
Date: Thu, Jan 27 2011 10:51AM
Subject: Re: 1.3.2 meaningful sequence
← Previous message | Next message →
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.
On Thu, Jan 27, 2011 at 7:26 PM, Steve Green < = EMAIL ADDRESS REMOVED = >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
>
>
>
From: Sailesh Panchang
Date: Thu, Jan 27 2011 7:54PM
Subject: Re: 1.3.2 meaningful sequence
← Previous message | No next message
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
On 1/27/11, Steve Green < = EMAIL ADDRESS REMOVED = > 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
>
>
>