WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: WCAG 2.0: multiple buttons with the same nameaccessible

for

From: Jonathan Avila
Date: Nov 19, 2014 3:43PM

> 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 REMOVED> <mailto: <EMAIL 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 REMOVED> <mailto: <EMAIL 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.

-----Original Message-----
From: Lucy Greco [mailto: <EMAIL REMOVED> ]
Sent: Wednesday, November 19, 2014 12:09 PM
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0: multiple buttons with the same name
accessible

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 REMOVED> <mailto: <EMAIL 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?

-----Original Message-----
From: Paul Adam [mailto: <EMAIL REMOVED> ]
Sent: Wednesday, November 19, 2014 10:53 AM
To: WebAIM Discussion List
Subject: Re: [WebAIM] WCAG 2.0: multiple buttons with the same name
accessible

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 REMOVED> <mailto: <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> >
[mailto: <EMAIL REMOVED> ] On Behalf Of Paul Adam
Sent: Wednesday, November 19, 2014 12:41 PM
To: <EMAIL REMOVED> <mailto: <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> <mailto: <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> >
[mailto: <EMAIL REMOVED> ] On Behalf Of Wloch,
Rob
Sent: 19 November 2014 16:05
To: ' <EMAIL REMOVED> <mailto: <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> <mailto: <EMAIL REMOVED> >

list messages to <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >
list messages to <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >
list messages to <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >
list messages to <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >
list messages to <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >

messages to <EMAIL REMOVED> <mailto: <EMAIL REMOVED> >