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: Olaf Drümmer
Date: Nov 21, 2014 2:15AM

+1

Olaf

PS: This is one of the best descriptions of how one should address a topic like this I have read in many years.

On 21 Nov 2014, at 06:17, Cliff Tyllick < <EMAIL REMOVED> > wrote:

> Jason, I think you're right on target.
> Another way to think of this issue is that when users in general use the full capabilities of their devices, they detect and can comprehend the structure of the content, so the purpose of the link is clear.
> If a person using a screen reader either reads the page top to bottom or skims from one heading to the next until they find a section they want to read and then read that section, the context of any ambiguously worded link they encounter is already clear.
> When a person who can see does the same, the context is clear.
> It is when users in general choose not to use the full capabilities of their devices that the purpose of the link is ambiguous.
> For a person using a screen reader, asking for an alphabetical list of all links on the page is choosing not to use the full capabilities of the screen reader.
> But a person who can see—even a person who can see well—can make the same choice by dramatically reducing the size of the browser window. For example, even though I have a reasonably large monitor, sometimes I use only one-sixteenth of its area to read Web content. (Why? Because I need the rest of the screen for a mandatory training video.) In this view, a "Read more…" link has no context because the heading can't fit in the window I've created.
> That passes success criterion 2.4.4. The purpose of each link is clear "except where the purpose of the link would be ambiguous to users in general."
>
> As you point out, Jason, the question is not whether this is the best way to design content. (My answer: "It depends." Adding more words to each teaser's "Read more..." link risks cluttering the page, making it more difficult for people with attention deficits to recognize the overall pattern of "Heading—teaser—Read more.")
>
> The question is whether a link is accessible when you need to know the heading before it if you are to know the purpose if the link.
>
> The answer is yes.
>
> In another thread, Lucy Greco asked what could be done to clarify the purpose of each "Read more..." link in the list produced by a screen reader. Getting the screen reader to expose an ARIA property of each link is one idea. But what if screen readers offered this option: "List all links between this heading and the next heading of the same level"?
> Then, when confronted with a list of links with the same wording, the person using the screen reader could switch to a list of headings. When they get to the heading they care about, then they could ask for a list of all links under that heading. If the last link is "Read more," then they know to expect a complete article on the topic of that heading.
>
> Wouldn't that make the experience of using AT more like the experience of skimming the page visually?
> And wouldn't that make H80 work well for people who cannot see?
> Seems to me it would.
> Cliff Tyllick
>
>
> From: Jason Kiss < <EMAIL REMOVED> >
> To: WebAIM Discussion List < <EMAIL REMOVED> >
> Sent: Thursday, November 20, 2014 4:17 PM
> Subject: Re: [WebAIM] Preceding headings and link context [was Re: WCAG 2.0: multiple buttons with the same name accessible]
>
> Thanks, Andrew. I appreciate the reply, and yes, it does help. I've a
> follow up question below.
>
> On Fri, Nov 21, 2014 at 10:42 AM, Andrew Kirkpatrick < <EMAIL REMOVED> > wrote:
>
> <snip>
>
>> So, what does that mean? You could make an argument that by providing a custom attribute with more information for a link with poor link text that you are enabling programmatic determinability. And you'd be right that assistive technologies can get to the information, but then the question of accessibility support kicks in - the information needs to be programmatically available AND there needs to be user agent support so people can actually use what you create. In the case of the prior heading there is some assistive technology support, and since the providers are determining what browsers and AT are part of their conformance claims, it is possible that a provider might say "you need to use IE or FF with JAWS" as part of that claim.
>
> 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?
>
> Thanks,
>
> Jason
>
>
>>
>> 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.html
>>
>>
>>
>>
>>
>> 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>
>> >> >> >> >> > > > >
>
>
> > >