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
> >>
> >> -----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-refs.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>
> > > > > messages to <EMAIL REMOVED>
> > > > > > >
> > > >