WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]

for

From: Lucy Greco
Date: Nov 24, 2014 12:59PM

one correction here the jaws + t only reads the page title it never reads a
proceeding heading the only way to get the hedding is by moving to it with
the h key



--
Lucia Greco
Web Accessibility Evangelist
IST - Architecture, Platforms, and Integration
University of California, Berkeley
(510) 289-6008 skype: lucia1-greco
http://webaccess.berkeley.edu
Follow me on twitter @accessaces


On Sun, Nov 23, 2014 at 1:15 PM, <EMAIL REMOVED> <
<EMAIL REMOVED> > wrote:

> Thanks, Cliff and Andrew. Much appreciated.
>
> Jason Kiss
>
>
>
>
>
> > On 22/11/2014, at 4:25 pm, Andrew Kirkpatrick < <EMAIL REMOVED> >
> wrote:
> >
> > 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
> >>
> >>