E-mail List Archives

Search E-mail List Archives for

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

From: Susan Grossman
Date: Thu, Mar 28 2013 4:07PM
Subject: Labels on Checkboxes in data tables
No previous message | Next message →

Get a lot of push back on putting labels in data tables that contain form
elements. Generally they want to move off screen all the labels so they
aren't visible.

I push back on check boxes/radio buttons because having a visible label
gives users that larger area to select.

The push back is that it's too cluttered in a selection column having the
word "select" over the button/box. When doing government sites, they just
go ahead and put the labels into the cell.

So, opinions on whether the trend is going to all labels being hidden if
the inputs of any type are in a table cell would be appreciate. Links
extremely helpful on examples or write-ups.

Thank you for your time -

--
*Susan R. Grossman*
= EMAIL ADDRESS REMOVED =

From: Paul J. Adam
Date: Thu, Mar 28 2013 4:21PM
Subject: Re: Labels on Checkboxes in data tables
← Previous message | Next message →

If the design cannot handle a visible label then just use an aria-label and/or a title attribute to give the form control an accessible name. Proper row and column headers may also be necessary.

Paul J. Adam
Accessibility Evangelist
www.deque.com

On Mar 28, 2013, at 5:07 PM, Susan Grossman < = EMAIL ADDRESS REMOVED = > wrote:

> Get a lot of push back on putting labels in data tables that contain form
> elements. Generally they want to move off screen all the labels so they
> aren't visible.
>
> I push back on check boxes/radio buttons because having a visible label
> gives users that larger area to select.
>
> The push back is that it's too cluttered in a selection column having the
> word "select" over the button/box. When doing government sites, they just
> go ahead and put the labels into the cell.
>
> So, opinions on whether the trend is going to all labels being hidden if
> the inputs of any type are in a table cell would be appreciate. Links
> extremely helpful on examples or write-ups.
>
> Thank you for your time -
>
> --
> *Susan R. Grossman*
> = EMAIL ADDRESS REMOVED =
> > >

From: Roger Hudson
Date: Thu, Mar 28 2013 5:13PM
Subject: Re: Labels on Checkboxes in data tables
← Previous message | Next message →

While I agree with the general idea that it is possible to provide an
identifying name to a form input without using a visible label, it might
cause some problem with complying with WCAG 2 at AA - in particular SC
2.4.6.


Roger Hudson
Web Usability
Web: www.usability.com.au
Twitter: http://twitter.com/rogerhudson
Email: = EMAIL ADDRESS REMOVED =

From: Birkir R. Gunnarsson
Date: Thu, Mar 28 2013 6:02PM
Subject: Re: Labels on Checkboxes in data tables
← Previous message | Next message →

I did copy and paste the url to this article off of Twitter once, not
sure how applicable it is, but it does make a good point regarding
labels and input fields:
http://laurakalbag.com/labels-in-input-fields-arent-such-a-good-idea/
I also thought fields without labels were harder to interact with on a
cell phone screen, but I can't locate the resources at the moment.
Cheers
-B

On 3/28/13, Roger Hudson < = EMAIL ADDRESS REMOVED = > wrote:
> While I agree with the general idea that it is possible to provide an
> identifying name to a form input without using a visible label, it might
> cause some problem with complying with WCAG 2 at AA - in particular SC
> 2.4.6.
>
>
> Roger Hudson
> Web Usability
> Web: www.usability.com.au
> Twitter: http://twitter.com/rogerhudson
> Email: = EMAIL ADDRESS REMOVED =
>
>
>
>
>

From: Elle
Date: Thu, Mar 28 2013 9:52PM
Subject: Re: Labels on Checkboxes in data tables
← Previous message | Next message →

Respectfully, I have to say that I would never recommend form elements to
be coded without visible labels (in all cases except, perhaps, a search
field). While providing offscreen labels for form elements certainly can
provide technical solutions for screen reader users, it really does nothing
to address the needs for low-vision users or users with cognitive
disabilities. Both user groups need to be able to understand what's
required of them when encountering a form element. It may not be a popular
position, but I'd suggest that without a visual indication of its purpose,
a form element is inaccessible. I agree with Roger, but I would say that
this is 3.3.2 that's not being met.

*3.3.2 <http://www.w3.org/TR/2008/REC-WCAG20-20081211/#minimize-error-cues>;
Labels
or Instructions:*
Labels<http://www.w3.org/TR/UNDERSTANDING-WCAG20/minimize-error-cues.html#labeldef>;
or
instructions are provided when content requires user input. (Level A)

Susan, I believe that your challenge really is a flaw in the overall design
of the form itself and also possibly the framework being used (given that
you're talking about putting form elements in a data table). This is the
reason why we always try to get accessibility integrated earlier in a web
project than the code implementation phase when all those decisions have
been made. Some accessibility issues really are design issues, not code
issues. And, a design that doesn't support visually labeled form elements
is likely to be a general usability issue, too, which will cause errors for
lots of people.

Birkir, while I understand the issues raised in the article you posted,
there are solutions to providing "placeholder text" that still maintain
usability and accessibility - you can code the text as part of the label
attribute so that it's always associated with the label for screen reader
users. This also follows a progressive enhancement approach, as the
information would still be available if JavaScript was disabled. Then, you
can use JavaScript to visually position that text over the input field.
When the field gets focus, the text doesn't have to disappear. You can
script it to appear directly above or below the associated field to serve
as a reminder for sighted users. This solution keeps the form uncluttered
but respects proximity needs for low-vision users.


Cheers,
Elle

From: Detlev Fischer
Date: Fri, Mar 29 2013 2:52AM
Subject: Re: Labels on Checkboxes in data tables
← Previous message | Next message →

I thought I throw in a WAI-ARIA example of a data table where column and row headings are linked to inputs in the cells - in this case text inputs - via aria-labelledby.

http://3needs.org/en/testing/code/aria-labelledby-simple-table.html

The original example is by Jim Thatcher. I just added some screen reader testing.

The advantage here is that both row and column headers are used to label the input and using a native label with both inside the cells would be quite redundant.

I think whether this is an OK way to label form elements in tables in terms of WCAG 2.0 compliance is hard to determine without regard to the overall context. In a simple and very short table as provided in the example, doing without visible label may be OK even for low vision users. But if you think of a matrix with longer rows of checkboxes (like Likert scale ratings) in a huge multi-row table, there certainly wouldn't be enough visual context for low vision users using magnification software or text size cranked up.

Note also that WAI-ARIA techniques have not reached the status of WCAG sufficient technique so far.

Best - Detlev

On 28 Mar 2013, at 23:07, Susan Grossman wrote:

> Get a lot of push back on putting labels in data tables that contain form
> elements. Generally they want to move off screen all the labels so they
> aren't visible.
>
> I push back on check boxes/radio buttons because having a visible label
> gives users that larger area to select.
>
> The push back is that it's too cluttered in a selection column having the
> word "select" over the button/box. When doing government sites, they just
> go ahead and put the labels into the cell.
>
> So, opinions on whether the trend is going to all labels being hidden if
> the inputs of any type are in a table cell would be appreciate. Links
> extremely helpful on examples or write-ups.
>
> Thank you for your time -
>
> --
> *Susan R. Grossman*
> = EMAIL ADDRESS REMOVED =
> > > --
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

Tel +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites

From: Detlev Fischer
Date: Fri, Mar 29 2013 8:55AM
Subject: Re: Labels on Checkboxes in data tables
← Previous message | No next message

In addition to my statement that WAI-ARIA techniques have not reached the status of WCAG sufficient technique so far, I'd like to clarify that ARIA techniques may still be used to claim conformance provided that they have sufficient accessibility support.

Whether or not a technique has already been published in the informational resources of WCAG 2.0 is not the decisive criterion. Instead, whether or not a technique can be deemed sufficient will depend on the current level of support in the context of use of the site that includes it.

Some aria roles and properties properties are better supported than others across the spectrum of browsers & assistive technologies. In constrained environments (company intranets, for example) accessibility support may be demonstrated by showing that the particular set of OS, browser and screen reader deployed supports the technique used. For public internet sites, it is an open call whether the share of supporting browsers & AT is already high enough to declare a technique accessibility supported. We all know that the speed of updating technologies varies a lot across countries and institutions.

Detlev

On 29 Mar 2013, at 09:52, Detlev Fischer wrote:

> I thought I throw in a WAI-ARIA example of a data table where column and row headings are linked to inputs in the cells - in this case text inputs - via aria-labelledby.
>
> http://3needs.org/en/testing/code/aria-labelledby-simple-table.html
>
> The original example is by Jim Thatcher. I just added some screen reader testing.
>
> The advantage here is that both row and column headers are used to label the input and using a native label with both inside the cells would be quite redundant.
>
> I think whether this is an OK way to label form elements in tables in terms of WCAG 2.0 compliance is hard to determine without regard to the overall context. In a simple and very short table as provided in the example, doing without visible label may be OK even for low vision users. But if you think of a matrix with longer rows of checkboxes (like Likert scale ratings) in a huge multi-row table, there certainly wouldn't be enough visual context for low vision users using magnification software or text size cranked up.
>
> Note also that WAI-ARIA techniques have not reached the status of WCAG sufficient technique so far.
>
> Best - Detlev
>
> On 28 Mar 2013, at 23:07, Susan Grossman wrote:
>
>> Get a lot of push back on putting labels in data tables that contain form
>> elements. Generally they want to move off screen all the labels so they
>> aren't visible.
>>
>> I push back on check boxes/radio buttons because having a visible label
>> gives users that larger area to select.
>>
>> The push back is that it's too cluttered in a selection column having the
>> word "select" over the button/box. When doing government sites, they just
>> go ahead and put the labels into the cell.
>>
>> So, opinions on whether the trend is going to all labels being hidden if
>> the inputs of any type are in a table cell would be appreciate. Links
>> extremely helpful on examples or write-ups.
>>
>> Thank you for your time -
>>
>> --
>> *Susan R. Grossman*
>> = EMAIL ADDRESS REMOVED =
>> >> >> >
> --
> Detlev Fischer
> testkreis - das Accessibility-Team von feld.wald.wiese
> c/o feld.wald.wiese
> Thedestraße 2
> 22767 Hamburg
>
> Tel +49 (0)40 439 10 68-3
> Mobil +49 (0)1577 170 73 84
> Fax +49 (0)40 439 10 68-5
>
> http://www.testkreis.de
> Beratung, Tests und Schulungen für barrierefreie Websites
>
>
>
>
> > > --
Detlev Fischer
testkreis - das Accessibility-Team von feld.wald.wiese
c/o feld.wald.wiese
Thedestraße 2
22767 Hamburg

Tel +49 (0)40 439 10 68-3
Mobil +49 (0)1577 170 73 84
Fax +49 (0)40 439 10 68-5

http://www.testkreis.de
Beratung, Tests und Schulungen für barrierefreie Websites