WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: WCAG 2.0: multiple buttons with the same name accessible

for

Number of posts in this thread: 29 (In chronological order)

From: Wloch, Rob
Date: Wed, Nov 19 2014 9:04AM
Subject: WCAG 2.0: multiple buttons with the same name accessible
No previous message | Next message →

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.

From: Don Mauck
Date: Wed, Nov 19 2014 9:19AM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

With buttons, it depends. If those buttons are within a table such as an apply or a save button ETC. on each row, that is not a violation. If you have two "save" buttons there might be one at the top of the screen and one at the bottom of the screen. That really can help those who use a screen magnifier.
So, does your issue meet any of these criteria's?

From: Wloch, Rob
Date: Wed, Nov 19 2014 9:36AM
Subject: Re: WCAG 2.0: multiple buttons with the same nameaccessible
← Previous message | Next message →

Thank you Don.

In this case, it would just be separate <h2> sections so no tables.

From: Bim Egan
Date: Wed, Nov 19 2014 9:40AM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

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




From: Paul Adam
Date: Wed, Nov 19 2014 10:40AM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

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 ADDRESS 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
>
>
>
>
>

From: Jonathan Avila
Date: Wed, Nov 19 2014 10:45AM
Subject: Re: WCAG 2.0: multiple buttons with the same nameaccessible
← Previous message | Next message →

> 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

From: Paul Adam
Date: Wed, Nov 19 2014 10:53AM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

So it's ok if I have 10 buttons on the page that all say "Delete"? But
not ok if I have 10 "read more" links?

Sent from my iPhone

On Nov 19, 2014, at 11:46 AM, Jonathan Avila < = EMAIL ADDRESS 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
>
>

From: Don Mauck
Date: Wed, Nov 19 2014 10:59AM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

I agree, it certainly seems that in this case buttons should be treated the same way links are. Is this an oversight from the WC3?

From: Lucy Greco
Date: Wed, Nov 19 2014 12:09PM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

hello:
forget about the rules for a second here. no its not OK to have buttons
with the same name!!
if they do different actions or take the same action on different elements.
yes a list of buttons can be used to move through the page and heading or
no heading before the button, in that list if the buttons do not do the
same thing the same name would drive me nuts.
yes if the button does the same thing to the same element its OK like the
example of save at the top and the bottom but save for ten different parts
of the page should not and would not be accessible .
some times we focus so much on the standered that we are forgetting its
reel users we are afecting here and we need to remember users come at every
thing in a diferent way. even in the table example given here i disagree if
there is no way to know witch item your removing or paying $10000 for the
button is a waist of web space. 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 Wed, Nov 19, 2014 at 9:59 AM, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:

> I agree, it certainly seems that in this case buttons should be treated
> the same way links are. Is this an oversight from the WC3?
>
>

From: Don Mauck
Date: Wed, Nov 19 2014 12:25PM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

Wouldn't the table issue you bring up be a result of either not coding the table correctly or not using you AT product correctly with whatever table reading commands they use. I would argue that if you have correct row and column headings you would know what you're buying, deleting, or anything else you can do with that row, just my thoughts.

From: Andrew Kirkpatrick
Date: Wed, Nov 19 2014 2:30PM
Subject: Re: WCAG 2.0: multiple buttons with the same nameaccessible
← Previous message | Next message →

My understanding is the same as Jon's. Yes, it seems a problem if a button says "delete" and that is ok while a link that says "read more" may not be ok. I think that the WG may have been thinking about links as a type of control for one use and buttons as a different type used for another, but certainly we've seen that these control types are used interchangeably perhaps more than other pairings. The language of 2.4.4 does say links rather clearly, so I'm inclined to think that this needs to be added to the WCAG WG's list of issues that we need to keep in mind when at some future time we look at requirements for a new version or extension of WCAG. I've added this to our list.

I do think that it is a hard issue. For example, if I make a web-based rich text editor and have a button for "copy" it is very reasonable for a person to ask "copy what?", which is similar to asking "delete what?" or "read more of what?". So I do think that buttons need to be clearly identifiable, as do links, but we need to think about how to clearly identify what is required.

AWK


From: Lucy Greco
Date: Wed, Nov 19 2014 2:32PM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

actualy the table can be marked up properly and this still will be a
problem in the form fields list or the buttons list. this goes back to the
problem i spoke about here the other day that the only information past
through when the screen reader user is using a list be it the links list or
button list or what have you is the label the describe by or table headers
do not get past through.



--
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 Wed, Nov 19, 2014 at 11:25 AM, Don Mauck < = EMAIL ADDRESS REMOVED = > wrote:

> Wouldn't the table issue you bring up be a result of either not coding the
> table correctly or not using you AT product correctly with whatever table
> reading commands they use. I would argue that if you have correct row and
> column headings you would know what you're buying, deleting, or anything
> else you can do with that row, just my thoughts.
>
>

From: Don Mauck
Date: Wed, Nov 19 2014 3:18PM
Subject: Re: WCAG 2.0: multiple buttons with the same nameaccessible
← Previous message | Next message →

Good to know. It certainly seems that it merits more discussion.

From: Jonathan Avila
Date: Wed, Nov 19 2014 3:43PM
Subject: Re: WCAG 2.0: multiple buttons with the same nameaccessible
← Previous message | Next message →

> the table can be marked up properly and this still will be a
problem in the form fields list or the buttons list.

This sounds like a screen reader bug/enhancement. AT makers and site authors have to share the responsibility. When relationships are exposed programmatically this is a strong case/need for AT follow through.

Jon

On Nov 19, 2014, at 4:37 PM, Lucy Greco < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:

actualy the table can be marked up properly and this still will be a
problem in the form fields list or the buttons list. this goes back to the
problem i spoke about here the other day that the only information past
through when the screen reader user is using a list be it the links list or
button list or what have you is the label the describe by or table headers
do not get past through.



--
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 Wed, Nov 19, 2014 at 11:25 AM, Don Mauck < = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >> wrote:

Wouldn't the table issue you bring up be a result of either not coding the
table correctly or not using you AT product correctly with whatever table
reading commands they use. I would argue that if you have correct row and
column headings you would know what you're buying, deleting, or anything
else you can do with that row, just my thoughts.

From: Wloch, Rob
Date: Wed, Nov 19 2014 4:07PM
Subject: Re: WCAG 2.0: multiple buttons with the samenameaccessible
← Previous message | Next message →

Thank you everyone for your comments on this. My take from what I've read everyone say is that it technically passes based on the current WCAG 2.0 but probably isn't really a good thing to do. Technique H80 seems to be the closest thing that the WCAG 2.0 has for this scenario but for links rather than buttons.

From: Sailesh Panchang
Date: Thu, Nov 20 2014 6:49AM
Subject: Re: WCAG 2.0: multiple buttons with the same name accessible
← Previous message | Next message →

Rob,
This will be a violation of SC 2.4.6 (AA). The intent is "Descriptive
labels help users identify specific components within the content".
I have always failed this under SC 2.4.6.
Perhaps the following example will help you
http://mars.dequecloud.com/demo/form-markup.htm#tech9

Thanks,
Sailesh Panchang


On 11/19/14, Wloch, Rob < = EMAIL ADDRESS REMOVED = > wrote:
> Thank you everyone for your comments on this. My take from what I've read
> everyone say is that it technically passes based on the current WCAG 2.0 but
> probably isn't really a good thing to do. Technique H80 seems to be the
> closest thing that the WCAG 2.0 has for this scenario but for links rather
> than buttons.
>
>

From: Jason Kiss
Date: Thu, Nov 20 2014 1:24PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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 ADDRESS 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
>
>

From: Andrew Kirkpatrick
Date: Thu, Nov 20 2014 2:42PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

Jason,

The following is my belief of how the situation can be viewed but doesn't represent an official WCAG working group statement.

The understanding and techniques documents don't prohibit using the preceding heading at all - they don't "prohibit" anything. As you indicate, the techniques and understanding documents are non-normative, so if you are required to conform to WCAG 2.0 AA you don't have to do anything specific mentioned in the techniques document as only the standard and its success criteria are normative.

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.

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

From: Jason Kiss
Date: Thu, Nov 20 2014 3:17PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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 ADDRESS 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
>
>

From: Olaf Drümmer
Date: Fri, Nov 21 2014 2:15AM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

+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 ADDRESS 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 ADDRESS REMOVED = >
> To: WebAIM Discussion List < = EMAIL ADDRESS 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 ADDRESS 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
>>
>>

From: Andrew Kirkpatrick
Date: Fri, Nov 21 2014 8:25PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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
>
>

From: jason
Date: Sun, Nov 23 2014 2:15PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

Thanks, Cliff and Andrew. Much appreciated.

Jason Kiss





> On 22/11/2014, at 4:25 pm, Andrew Kirkpatrick < = EMAIL ADDRESS 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
>>
>>

From: Lucy Greco
Date: Mon, Nov 24 2014 12:59PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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 ADDRESS REMOVED = <
= EMAIL ADDRESS REMOVED = > wrote:

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

From: Andrew Kirkpatrick
Date: Mon, Nov 24 2014 1:06PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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

From: Andrew Kirkpatrick
Date: Mon, Nov 24 2014 1:19PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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

From: Lucy Greco
Date: Mon, Nov 24 2014 1:55PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

thanks for pointing that out. but that is not really an ideal way to find
what your reading after all if i as a advanced screen reader user did not
know that how many people do. also the information is quite verbose and it
does not read the header when i need it, for example when i tab to it or
in the links list i am not going to get a page title every time i want to
know what the context is. getting a page title is not at all intuative and
doing this for every link even the thought of it makes my hands hurt.
in that case why couldn't the link have been labeled reports by date that
would have been much simpler to code to. 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 Mon, Nov 24, 2014 at 12:19 PM, Andrew Kirkpatrick < = EMAIL ADDRESS 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
>
>

From: Andrew Kirkpatrick
Date: Tue, Nov 25 2014 5:12AM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

<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 ADDRESS 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
>
>

From: Lucy Greco
Date: Tue, Nov 25 2014 5:23PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | Next message →

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 ADDRESS 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 ADDRESS 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
> >
> >

From: Andrew Kirkpatrick
Date: Tue, Nov 25 2014 5:59PM
Subject: Re: Preceding headings and link context [wasWCAG 2.0: multiple buttons with the same name accessible]
← Previous message | No next message

Sounds good. Have a great holiday Cliff (and others too!).
AWK