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: Andrew Kirkpatrick
Date: Nov 24, 2014 1:06PM

Lucy,
I just tried this with JAWS on FF and it reads the heading.

For example, on w3.org I navigated to the link "By date" and hit capslock+t and at the end of a long string of voiced text JAWS announces "heading is technical reports".

AWK

-----Original Message-----
From: <EMAIL REMOVED> [mailto: <EMAIL REMOVED> ] On Behalf Of Lucy Greco
Sent: Monday, November 24, 2014 2:59 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] Preceding headings and link context [was Re: WCAG 2.0: multiple buttons with the same name accessible]

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
> >>
> >> -----Original Message-----
> >> From: <EMAIL REMOVED>
> >> [mailto: <EMAIL REMOVED> ] On Behalf Of Jason
> >> Kiss
> >> Sent: Thursday, November 20, 2014 3:24 PM
> >> To: WebAIM Discussion List
> >> Subject: [WebAIM] Preceding headings and link context [was Re: WCAG
> >> 2.0: multiple buttons with the same name accessible]
> >>
> >> I don't mean to come across as a troll, since this issue was
> >> addressed
> by the WAI more than a year ago, as is noted in the history of the
> change regarding H80 that Andrew provided last August [1].
> >>
> >> Still, I'd like to ask how that decision or the surrounding
> >> guidance
> provided in the non-normative Understanding WCAG and Techniques for
> WCAG documents disallow using the preceding heading for programmatic
> link context in order to satisfy Success Criterion 2.4.4?
> >>
> >> A little disclaimer: I openly admit to an intermittent frustration,
> >> if
> not simple confusion, with a certain ambiguity I find in not only some
> of the language used in the Sufficient Techniques and the
> Understanding documents, but also how they are sometimes referred to,
> intentionally or not, as if they established normative requirements as
> opposed to just providing, albeit very useful, informative guidance.
> >> Anyway, that's just my bugbear, but perhaps you can disabuse me. I
> wouldn't mind <grin>.
> >>
> >> Now the question: I might be misunderstanding the WCAG spec and its
> definitions. Do Success Criterion 2.4.4 and the normative definitions
> of programmatically determined (programmatically determinable) [2] and
> programmatically determined link context [3] require that a link's
> context be programmatically determinable without the user having to
> move focus from the link, as is informatively suggested in
> Understanding SC 2.4.4 [4]? Or do the Success Criterion and those
> definitions only require that the link's context be available by
> virtue of a programmatically determinable relationship, something that
> a link's immediately preceding heading surely provides (even though it
> may require that a user move focus away from the link to determine that context)?
> >>
> >> I'm not suggesting that relying on preceding headings to provide
> >> link
> context delivers the most usable experience for screen reader users. I
> know that it doesn't, given current levels of accessibility support
> among those user agents. But, from the perspective of having to assess
> a pass/fail against a specific normative requirement, doesn't a
> preceding heading provide a programmatically determinable context for a link?
> >>
> >> Perhaps I am misunderstanding Success Criterion 2.4.4 on the whole?
> >>
> >> By the way, I'm not suggesting that technique H80 be moved back to
> Sufficient from Advisory. I'm comfortable that it remain Advisory.
> >>
> >> Thanks for any help,
> >>
> >> Jason
> >>
> >>
> >> [1]
> >> http://lists.w3.org/Archives/Public/w3c-wai-gl/2014JulSep/0122.html
> >> [2] http://www.w3.org/TR/WCAG20/#programmaticallydetermineddef
> >> [3] http://www.w3.org/TR/WCAG20/#pdlinkcontextdef
> >> [4]
> >> http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-ref
> >> s.h
> >> tml
> >>
> >>
> >>
> >>
> >>
> >> On Thu, Nov 20, 2014 at 6:45 AM, Jonathan Avila <
> <EMAIL REMOVED> > wrote:
> >>>> Isn't preceding heading no longer allowed for link purpose
> determination? Link purpose, button purpose same thing right?
> >>>
> >>> Yes, that is my understanding but it was also my understanding
> >>> that SC
> 2.4.4 did not apply to buttons.
> >>>
> >>> Jonathan
> >>>
> >>> -----Original Message-----
> >>> From: <EMAIL REMOVED>
> >>> [mailto: <EMAIL REMOVED> ] On Behalf Of Paul
> >>> Adam
> >>> Sent: Wednesday, November 19, 2014 12:41 PM
> >>> To: <EMAIL REMOVED> ; WebAIM Discussion List
> >>> Subject: Re: [WebAIM] WCAG 2.0: multiple buttons with the same
> >>> name accessible
> >>>
> >>> Isn't preceding heading no longer allowed for link purpose
> determination? Link purpose, button purpose same thing right?
> >>>
> >>> Sent from my iPhone
> >>>
> >>>> On Nov 19, 2014, at 10:40 AM, Bim Egan < <EMAIL REMOVED> > wrote:
> >>>>
> >>>> Hi Rob,
> >>>>
> >>>> In my view the situation you've described would mean that the
> >>>> buttons
> were
> >>>> accessible under WCAG2. This is because there's a heading structure
> that
> >>>> gives context for each of the same-name buttons. The purpose of the
> >>>> button is programmatically determinable. Unfortunately, in some
> >>>> screen readers this might mean that audible output includes the
> >>>> page title as well as the preceding heading, but the context is
> >>>> there, so
> you've done your job.
> >>>>
> >>>>
> >>>> HTH,
> >>>>
> >>>> Bim
> >>>>
> >>>>
> >>>>
> >>>>
> >>>> -----Original Message-----
> >>>> From: <EMAIL REMOVED>
> >>>> [mailto: <EMAIL REMOVED> ] On Behalf Of Wloch,
> >>>> Rob
> >>>> Sent: 19 November 2014 16:05
> >>>> To: ' <EMAIL REMOVED> '
> >>>> Subject: [WebAIM] WCAG 2.0: multiple buttons with the same name
> >>>> accessible
> >>>>
> >>>> Hi all,
> >>>>
> >>>> I haven't been able to find an answer to this in the WCAG 2.0 so
> >>>> I thought I'd ask in this forum for your opinions. Is it allowed
> >>>> to have multiple buttons with the same name on a webpage? I'm
> >>>> wondering if it's similar to the guidelines for links where
> >>>> screen readers would see a list of links with multiple "click here" which isn't good.
> >>>>
> >>>> For example, something like below where the text between the
> >>>> square brackets represents the button names:
> >>>>
> >>>> H2 Blah blah blah
> >>>> [start]
> >>>>
> >>>> H2 Blah blah blah
> >>>> [modify] [stop]
> >>>>
> >>>> H2 Blah blah blah
> >>>> [modify] [stop]
> >>>>
> >>>> Thanks, Rob.
> >>>> > >>>> > >>>> > >>>>
> >>>> > >>>> > >>>> > >>> > >>> > >>> list messages to <EMAIL REMOVED>
> >>> > >>> > >>> list messages to <EMAIL REMOVED>
> >> > >> > >> list messages to <EMAIL REMOVED>
> >> > >> > >> list messages to <EMAIL REMOVED>
> > > > > > list
> messages to <EMAIL REMOVED>
> > > > > > list messages to <EMAIL REMOVED>
>
> > > list messages to <EMAIL REMOVED>
>