E-mail List Archives

Thread: Radio Buttons in a Data Table

for

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

From: David Ashleydale
Date: Tue, Jul 10 2012 4:20PM
Subject: Radio Buttons in a Data Table
No previous message | Next message →

Hi,

I wanted to see if anyone here has an opinion on the use of radio buttons
inside a data table. The header of each row is a type of product and the
columns are product features. There is a radio button in each data cell.
Not every feature is available for every product, so there's not a radio
button in every column for every product. This set up allows users to
choose one available feature for every product -- the radio buttons in each
row are in the same "set" so only one can be chosen in each row.

For those of you that can see images, here is an image of something similar
to what I'm talking about:
[image: Table of Radio Buttons Survey Question]
What is the best way to make a set up like this more accessible? Normally,
I try to code radio buttons in fieldsets, but that isn't possible if each
radio button is in its own table cell. Also, the radio buttons can't have
explicit labels -- all of the radio buttons in one column share one "label"
-- the column header.

Normally, I would try to suggest that this design not be used -- I don't
like mixing forms with data tables. But visually, it is more compact than
repeating the labels for every radio button.

My initial thought is to add a TITLE attribute to each of the radio buttons
explaining which product and feature it is for. Will that be sufficient or
are there other things I could do to make this design more accessible?

Thanks,
David

From: Tony Olivero
Date: Tue, Jul 10 2012 4:28PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | Next message →

David,

If you're absolutely wedded to this setup, and I don't recommend it because
it doesn't translate well into progressive enhancement as you'll see in a
minute, you basically have two solutions: ARIA and off screen text.

For the ARIA solution, You can give each column header an id, and use that
id as part of an aria-labelledby attribute on each radio button. Problem
with this is not all screen access technology/browser combinations support
ARIA yet.

For the off-screen text solution you have to code a CSS selector that's
positioned off screen, and basically a pixel in size with no overflow.
You'll have to use a label/span combination with the off-screen span holding
the label text. I know some people are wary of using too much off-screen
text because they fear search engine's will lower their pagerank because of
it.

Title is a possibility, but you will have to instruct screen access software
users to (and possibly how to) adjust their preferences to read this
attribute as it is not a default in most programs.

HTH,
Tony

-----Original Message-----
From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, July 10, 2012 17:20
To: WebAIM Discussion List
Subject: [WebAIM] Radio Buttons in a Data Table

Hi,

I wanted to see if anyone here has an opinion on the use of radio buttons
inside a data table. The header of each row is a type of product and the
columns are product features. There is a radio button in each data cell.
Not every feature is available for every product, so there's not a radio
button in every column for every product. This set up allows users to
choose one available feature for every product -- the radio buttons in each
row are in the same "set" so only one can be chosen in each row.

For those of you that can see images, here is an image of something similar
to what I'm talking about:
[image: Table of Radio Buttons Survey Question]
What is the best way to make a set up like this more accessible? Normally,
I try to code radio buttons in fieldsets, but that isn't possible if each
radio button is in its own table cell. Also, the radio buttons can't have
explicit labels -- all of the radio buttons in one column share one "label"
-- the column header.

Normally, I would try to suggest that this design not be used -- I don't
like mixing forms with data tables. But visually, it is more compact than
repeating the labels for every radio button.

My initial thought is to add a TITLE attribute to each of the radio buttons
explaining which product and feature it is for. Will that be sufficient or
are there other things I could do to make this design more accessible?

Thanks,
David

From: David Ashleydale
Date: Tue, Jul 10 2012 4:32PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | Next message →

"Title is a possibility, but you will have to instruct screen access
software users to (and possibly how to) adjust their preferences to read
this attribute as it is not a default in most programs."

I thought TITLE was not read by default on links, but it is on form fields
like radio buttons.

David

From: Tony Olivero
Date: Tue, Jul 10 2012 4:37PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | Next message →

I'll have to retest with NVDA (and someone else will have to speak to
Window-Eyes), but it never has been read when I've used JAWS. Though the
last time I did test this, title wasn't read by default. I'm willing to
admit I'm wrong if someone else has more current info.
-----Original Message-----
From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, July 10, 2012 17:33
To: WebAIM Discussion List
Subject: Re: [WebAIM] Radio Buttons in a Data Table

"Title is a possibility, but you will have to instruct screen access
software users to (and possibly how to) adjust their preferences to read
this attribute as it is not a default in most programs."

I thought TITLE was not read by default on links, but it is on form fields
like radio buttons.

David

From: David Ashleydale
Date: Tue, Jul 10 2012 4:55PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | Next message →

"If you're absolutely wedded to this setup, and I don't recommend it
because it doesn't translate well into progressive enhancement..."

And if you have time, I would love to hear your ideas for a different
design. The people that own this page basically told me that they will
consent to a new design if they have to, but that it will cost them time
and money that they are reluctant to spend. They want to know, "Is there a
way to use this design and still conform to WCAG and HTML standards?" If
not, they will bite the bullet because they do want to meet the standards.
But they really want to stick with this if it's at all possible.

Thanks,
David


On Tue, Jul 10, 2012 at 3:28 PM, Tony Olivero < = EMAIL ADDRESS REMOVED = > wrote:

> David,
>
> If you're absolutely wedded to this setup, and I don't recommend it because
> it doesn't translate well into progressive enhancement as you'll see in a
> minute, you basically have two solutions: ARIA and off screen text.
>
> For the ARIA solution, You can give each column header an id, and use that
> id as part of an aria-labelledby attribute on each radio button. Problem
> with this is not all screen access technology/browser combinations support
> ARIA yet.
>
> For the off-screen text solution you have to code a CSS selector that's
> positioned off screen, and basically a pixel in size with no overflow.
> You'll have to use a label/span combination with the off-screen span
> holding
> the label text. I know some people are wary of using too much off-screen
> text because they fear search engine's will lower their pagerank because of
> it.
>
> Title is a possibility, but you will have to instruct screen access
> software
> users to (and possibly how to) adjust their preferences to read this
> attribute as it is not a default in most programs.
>
> HTH,
> Tony
>
> -----Original Message-----
> From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, July 10, 2012 17:20
> To: WebAIM Discussion List
> Subject: [WebAIM] Radio Buttons in a Data Table
>
> Hi,
>
> I wanted to see if anyone here has an opinion on the use of radio buttons
> inside a data table. The header of each row is a type of product and the
> columns are product features. There is a radio button in each data cell.
> Not every feature is available for every product, so there's not a radio
> button in every column for every product. This set up allows users to
> choose one available feature for every product -- the radio buttons in each
> row are in the same "set" so only one can be chosen in each row.
>
> For those of you that can see images, here is an image of something similar
> to what I'm talking about:
> [image: Table of Radio Buttons Survey Question]
> What is the best way to make a set up like this more accessible? Normally,
> I try to code radio buttons in fieldsets, but that isn't possible if each
> radio button is in its own table cell. Also, the radio buttons can't have
> explicit labels -- all of the radio buttons in one column share one "label"
> -- the column header.
>
> Normally, I would try to suggest that this design not be used -- I don't
> like mixing forms with data tables. But visually, it is more compact than
> repeating the labels for every radio button.
>
> My initial thought is to add a TITLE attribute to each of the radio buttons
> explaining which product and feature it is for. Will that be sufficient or
> are there other things I could do to make this design more accessible?
>
> Thanks,
> David
> > > >
> > > >

From: Tony Olivero
Date: Tue, Jul 10 2012 5:04PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | Next message →

Believe me, I understand having to work within design parameters. My concern
is only over how to best make it accessible.

Your best bet might be to do a combination of title and off-screen text.
That is: put the title attribute on your radio buttons and then use
offscreen text on the first one to tell the user that if there program is
not reading the radio button value to switch it to using title instead of
label.

It's definitely a workable solution, just moderately more involved for the
user, but that may not be an entirely bad thing either. :)

I'd love to say use ARIA labeled by and be done with it, because I think
it's the best solution for a table like this, but I know Window-eyes at
least flat out doesn't support it yet.


Tony

-----Original Message-----
From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, July 10, 2012 17:55
To: WebAIM Discussion List
Subject: Re: [WebAIM] Radio Buttons in a Data Table

"If you're absolutely wedded to this setup, and I don't recommend it
because it doesn't translate well into progressive enhancement..."

And if you have time, I would love to hear your ideas for a different
design. The people that own this page basically told me that they will
consent to a new design if they have to, but that it will cost them time
and money that they are reluctant to spend. They want to know, "Is there a
way to use this design and still conform to WCAG and HTML standards?" If
not, they will bite the bullet because they do want to meet the standards.
But they really want to stick with this if it's at all possible.

Thanks,
David


On Tue, Jul 10, 2012 at 3:28 PM, Tony Olivero < = EMAIL ADDRESS REMOVED = > wrote:

> David,
>
> If you're absolutely wedded to this setup, and I don't recommend it
because
> it doesn't translate well into progressive enhancement as you'll see in a
> minute, you basically have two solutions: ARIA and off screen text.
>
> For the ARIA solution, You can give each column header an id, and use that
> id as part of an aria-labelledby attribute on each radio button. Problem
> with this is not all screen access technology/browser combinations support
> ARIA yet.
>
> For the off-screen text solution you have to code a CSS selector that's
> positioned off screen, and basically a pixel in size with no overflow.
> You'll have to use a label/span combination with the off-screen span
> holding
> the label text. I know some people are wary of using too much off-screen
> text because they fear search engine's will lower their pagerank because
of
> it.
>
> Title is a possibility, but you will have to instruct screen access
> software
> users to (and possibly how to) adjust their preferences to read this
> attribute as it is not a default in most programs.
>
> HTH,
> Tony
>
> -----Original Message-----
> From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, July 10, 2012 17:20
> To: WebAIM Discussion List
> Subject: [WebAIM] Radio Buttons in a Data Table
>
> Hi,
>
> I wanted to see if anyone here has an opinion on the use of radio buttons
> inside a data table. The header of each row is a type of product and the
> columns are product features. There is a radio button in each data cell.
> Not every feature is available for every product, so there's not a radio
> button in every column for every product. This set up allows users to
> choose one available feature for every product -- the radio buttons in
each
> row are in the same "set" so only one can be chosen in each row.
>
> For those of you that can see images, here is an image of something
similar
> to what I'm talking about:
> [image: Table of Radio Buttons Survey Question]
> What is the best way to make a set up like this more accessible? Normally,
> I try to code radio buttons in fieldsets, but that isn't possible if each
> radio button is in its own table cell. Also, the radio buttons can't have
> explicit labels -- all of the radio buttons in one column share one
"label"
> -- the column header.
>
> Normally, I would try to suggest that this design not be used -- I don't
> like mixing forms with data tables. But visually, it is more compact than
> repeating the labels for every radio button.
>
> My initial thought is to add a TITLE attribute to each of the radio
buttons
> explaining which product and feature it is for. Will that be sufficient or
> are there other things I could do to make this design more accessible?
>
> Thanks,
> David
> > > >
> > > >

From: Morin, Gary (NIH/OD) [E]
Date: Wed, Jul 11 2012 12:38PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | Next message →

Anthony, if you have some working pages that you'd like tested with speech recognition software (Dragon Naturally Speaking, v. 11), let me know. I'd be happy to try them out. To date, I find radio buttons and check boxes both far more usable than drop-down menus (which I've never successfully navigated), and it'd be helpful to know what the formatting techniques are that are being used, so that I can pass them along to developers.

Gary M.


-----Original Message-----
From: Tony Olivero [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, July 10, 2012 6:38 PM
To: 'WebAIM Discussion List'
Subject: Re: [WebAIM] Radio Buttons in a Data Table

I'll have to retest with NVDA (and someone else will have to speak to Window-Eyes), but it never has been read when I've used JAWS. Though the last time I did test this, title wasn't read by default. I'm willing to admit I'm wrong if someone else has more current info.
-----Original Message-----
From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
Sent: Tuesday, July 10, 2012 17:33
To: WebAIM Discussion List
Subject: Re: [WebAIM] Radio Buttons in a Data Table

"Title is a possibility, but you will have to instruct screen access software users to (and possibly how to) adjust their preferences to read this attribute as it is not a default in most programs."

I thought TITLE was not read by default on links, but it is on form fields like radio buttons.

David

From: James Nurthen
Date: Wed, Jul 11 2012 3:40PM
Subject: Re: Radio Buttons in a Data Table
← Previous message | No next message

Off-screen labels is a bad idea Radio Buttons (and checkboxes)

If there is a valid label associated with a radio button (or checkbox) then
IE will draw the focus indicator around the text rather than around the
button itself. So if this label is off-screen there will be no visible
focus indicator for the radio button.

In the situations where there is no conventional label for a radio button
then using title (or aria-label or aria-labelledby if your browsers support
them fully) is the preferred approach.

Regards,
James


On Tue, Jul 10, 2012 at 4:04 PM, Tony Olivero < = EMAIL ADDRESS REMOVED = > wrote:

> Believe me, I understand having to work within design parameters. My
> concern
> is only over how to best make it accessible.
>
> Your best bet might be to do a combination of title and off-screen text.
> That is: put the title attribute on your radio buttons and then use
> offscreen text on the first one to tell the user that if there program is
> not reading the radio button value to switch it to using title instead of
> label.
>
> It's definitely a workable solution, just moderately more involved for the
> user, but that may not be an entirely bad thing either. :)
>
> I'd love to say use ARIA labeled by and be done with it, because I think
> it's the best solution for a table like this, but I know Window-eyes at
> least flat out doesn't support it yet.
>
>
> Tony
>
> -----Original Message-----
> From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
> Sent: Tuesday, July 10, 2012 17:55
> To: WebAIM Discussion List
> Subject: Re: [WebAIM] Radio Buttons in a Data Table
>
> "If you're absolutely wedded to this setup, and I don't recommend it
> because it doesn't translate well into progressive enhancement..."
>
> And if you have time, I would love to hear your ideas for a different
> design. The people that own this page basically told me that they will
> consent to a new design if they have to, but that it will cost them time
> and money that they are reluctant to spend. They want to know, "Is there a
> way to use this design and still conform to WCAG and HTML standards?" If
> not, they will bite the bullet because they do want to meet the standards.
> But they really want to stick with this if it's at all possible.
>
> Thanks,
> David
>
>
> On Tue, Jul 10, 2012 at 3:28 PM, Tony Olivero < = EMAIL ADDRESS REMOVED = > wrote:
>
> > David,
> >
> > If you're absolutely wedded to this setup, and I don't recommend it
> because
> > it doesn't translate well into progressive enhancement as you'll see in a
> > minute, you basically have two solutions: ARIA and off screen text.
> >
> > For the ARIA solution, You can give each column header an id, and use
> that
> > id as part of an aria-labelledby attribute on each radio button. Problem
> > with this is not all screen access technology/browser combinations
> support
> > ARIA yet.
> >
> > For the off-screen text solution you have to code a CSS selector that's
> > positioned off screen, and basically a pixel in size with no overflow.
> > You'll have to use a label/span combination with the off-screen span
> > holding
> > the label text. I know some people are wary of using too much off-screen
> > text because they fear search engine's will lower their pagerank because
> of
> > it.
> >
> > Title is a possibility, but you will have to instruct screen access
> > software
> > users to (and possibly how to) adjust their preferences to read this
> > attribute as it is not a default in most programs.
> >
> > HTH,
> > Tony
> >
> > -----Original Message-----
> > From: David Ashleydale [mailto: = EMAIL ADDRESS REMOVED = ]
> > Sent: Tuesday, July 10, 2012 17:20
> > To: WebAIM Discussion List
> > Subject: [WebAIM] Radio Buttons in a Data Table
> >
> > Hi,
> >
> > I wanted to see if anyone here has an opinion on the use of radio buttons
> > inside a data table. The header of each row is a type of product and the
> > columns are product features. There is a radio button in each data cell.
> > Not every feature is available for every product, so there's not a radio
> > button in every column for every product. This set up allows users to
> > choose one available feature for every product -- the radio buttons in
> each
> > row are in the same "set" so only one can be chosen in each row.
> >
> > For those of you that can see images, here is an image of something
> similar
> > to what I'm talking about:
> > [image: Table of Radio Buttons Survey Question]
> > What is the best way to make a set up like this more accessible?
> Normally,
> > I try to code radio buttons in fieldsets, but that isn't possible if each
> > radio button is in its own table cell. Also, the radio buttons can't have
> > explicit labels -- all of the radio buttons in one column share one
> "label"
> > -- the column header.
> >
> > Normally, I would try to suggest that this design not be used -- I don't
> > like mixing forms with data tables. But visually, it is more compact than
> > repeating the labels for every radio button.
> >
> > My initial thought is to add a TITLE attribute to each of the radio
> buttons
> > explaining which product and feature it is for. Will that be sufficient
> or
> > are there other things I could do to make this design more accessible?
> >
> > Thanks,
> > David
> > > > > > > >
> > > > > > > >
> > > >
> > > >