E-mail List Archives
Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
From: Andrew Kirkpatrick
Date: Nov 21, 2014 8:25PM
- Next message: L Snider: "Re: Video Transcript Question (Bump)"
- Previous message: Judith.A.Blankman@wellsfargo.com: "aria-expanded state for show-hide interaction?"
- Next message in Thread: jason@accessibleculture.org: "Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]"
- Previous message in Thread: Olaf Drümmer: "Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]"
- View all messages in this Thread
Jason,
My answer below:
<quote>
Agreed, but given that all screen readers (at least as far as I'm
aware) enable quick access to a link's preceding heading (albeit simultaneously moving focus to that heading), wouldn't we consider the relationship between the link and that heading both programmatically determinable AND effectively fully accessibility supported by screen readers?
</quote>
The original logic was that while it is easy and convenient for a sighted user to glance at the heading and click the link, it is not so easy for a screen reader user. The advantage of the JAWS shortcut (JAWS + T) is that you can be informed about the most local heading prior to the link, but if the user uses the heading shortcut they move their focus (as you indicate) so the user then needs to navigate back to the link that was focused and that they were considering activating. That link might be the next item in the DOM after the heading, or it could be that the user needs to navigate through many links that stand between the heading and the original link. This doesn't amount to a good user experience, and yes, it is absolutely due to what the screen reader is conveniently or (in this case) not conveniently providing, and as a result the group hear from users and as a result felt that what is currently available isn't quite good enough.
What the WCAG group says in this regard isn't normative, only the standard is. If you feel that you're meeting the success criteria with any technique you need to be prepared to defend your methods. It is convenient to be able to say "the WCAG group thinks it is ok" (just as a person complaining might find it convenient to say if the WCAG group publishes a failure for a technique you use) but if you can show that what you are doing works and meets the SC then you'll have a good response to a complaint. If you can't, well, then you probably aren't.
AWK
>
> What the techniques do for authors is provide a set of ways that they can meet the success criteria. There are many techniques that the group hasn't published, so the techniques don't describe the only way to meet the success criteria, but what they do provide is a way to meet a given SC in a way that allows the author to say "the WCAG group indicates that in their opinion this works". If an author wants to do something that the group hasn't published as a technique, or that the group feels is less than ideal, he still can but will need to provide more of the information that provides backing to the idea that the technique used meets the success criteria.
>
> Does this help?
> AWK
>
>
- Next message: L Snider: "Re: Video Transcript Question (Bump)"
- Previous message: Judith.A.Blankman@wellsfargo.com: "aria-expanded state for show-hide interaction?"
- Next message in Thread: jason@accessibleculture.org: "Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]"
- Previous message in Thread: Olaf Drümmer: "Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]"
- View all messages in this Thread