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 25, 2014 5:23PM


hello:
i want it to be clear that when i test i test for many different types
of disabilities and just one example ware this techneck would not work
is if you had ten links with the same name you have now made it harder
for both a speech in and a speech out user. any time you would like to see
me use a screen reader i am always open to it as its in portent to stay
engaged with the user and i consider my self the user Lucy



--
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 Tue, Nov 25, 2014 at 4:12 AM, Andrew Kirkpatrick < <EMAIL REMOVED> >
wrote:

> <quote>
> If the concern of the Working Group was that some people would consider
> using more than 5 links, then the clearer way to present that concern would
> be to add an example with too many links between headings and label that
> example as a failure. As the proposed revisions to the materials stand now,
> a person who wants to draw advice from the advisory technique of H80 has no
> clear idea of what the Working Group intends for that advice to be.
> </quote>
>
> Cliff, the above wasn't the concern of the working group as I recall it.
> I'm sure that there are limits to what is practical and but while there may
> be situations where 20 links is ok there are also situations where 20 is
> way too much.
>
> What proposed revisions are you talking about?
>
>
> AWK
>
>
>
> --
> 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 Mon, Nov 24, 2014 at 12:19 PM, Andrew Kirkpatrick < <EMAIL REMOVED> >
> wrote:
>
> > Cliff,
> > I'm not sure why you think that it is inconsistent? The examples are
> > brief, but that doesn't mean that it might not be applied to a longer
> > list of links. The test procedure indicates that you just need to
> > find the preceding heading, not the preceding heading when the list of
> > links has no more than 5 members.
> >
> > AWK
> >
> > -----Original Message-----
> > From: <EMAIL REMOVED> [mailto:
> > <EMAIL REMOVED> ] On Behalf Of Cliff Tyllick
> > Sent: Sunday, November 23, 2014 12:47 AM
> > To: WebAIM Discussion List
> > Subject: Re: [WebAIM] Preceding headings and link context [was Re:
> > WCAG
> > 2.0: multiple buttons with the same name accessible]
> >
> > Andrew,
> > With all due respect to the WCAG Working Group, I think they've taken
> > the review of H80 too far into the realm of the hypothetical.
> > <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 ... (after using the heading
> > shortcut) it could be that the user needs to navigate through many
> > links that stand between the heading and the original link. </quote>
> > If the user needs to navigate through many links to get from the
> > heading to the original link, the implementation is inconsistent with
> H80.
> > Each of the three example implementations in H80 has:- precise and
> > meaningful headings
> > - a consistent pattern of content between headings- a small number of
> > links in that pattern--five at the most- only one or two words in each
> > link When wouldn't H80 work? I can think of only three cases:- When
> > the preceding heading is not informative enough.
> > - When there is no consistent pattern of links between headings.- When
> > the content of all links in that pattern strains the capacity of
> > short-term memory--either because there are too many links or because
> > the links contain too many words.
> >
> > But, as I've noted above, none of these cases are consistent with H80.
> > So rather than relegate H80 to the nebulous category of "advisory"
> > techniques, the Working Group could have developed appropriate
> > counterexamples to illustrate failure:- H###: Relying on a heading
> > that provides too little context
> > - H###: Inconsistent pattern of links- H###: Too much information in
> > the links
> >
> > Cliff Tyllick
> >
> > From: Andrew Kirkpatrick < <EMAIL REMOVED> >
> > To: WebAIM Discussion List < <EMAIL REMOVED> >
> > Sent: Friday, November 21, 2014 9:25 PM
> > Subject: Re: [WebAIM] Preceding headings and link context [was Re:
> >WCAG
> > 2.0: multiple buttons with the same name accessible]
> >
> > 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>
> > > > > > list messages to <EMAIL REMOVED>
> > > > > > list messages to <EMAIL REMOVED>
> >
> >
> >
> > > > > > list messages to <EMAIL REMOVED>
> > > > > > list messages to <EMAIL REMOVED>
> >
> > > messages to <EMAIL REMOVED>
>
>
>
> > > messages to <EMAIL REMOVED>
> > > >