W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2016

RE: Are visible labels required per WCAG 2.0?

From: Jonathan Avila <jon.avila@ssbbartgroup.com>
Date: Tue, 22 Mar 2016 22:41:37 +0000
To: Phill Jenkins <pjenkins@us.ibm.com>, W3C WAI Interest Group <w3c-wai-ig@w3.org>
Message-ID: <BY2PR03MB27265785D434B3A8AA1636F9B800@BY2PR03MB272.namprd03.prod.outlook.com>
Phil, SC 3.3.2 Labels or Instructions requires that all input has a label or instructions.  Labels can be in the form of images labels can be applied to fields as a group such as a 3 part phone number field.  But they have to be there.  The definition of label in WCAG is defined as being always available to all users.

As for tables and non-input elements it is not as clear.

Jonathan


From: Phill Jenkins [mailto:pjenkins@us.ibm.com]
Sent: Tuesday, March 22, 2016 6:12 PM
To: W3C WAI Interest Group <w3c-wai-ig@w3.org>
Subject: Are visible labels required per WCAG 2.0?

I'm starting this thread because I believe there is a need for "perceivable" information by all users, including those  who are sighted but may have vision impairments, reading impairments, cognitive impairments, aging, or are learning about new content or a new application.


There are differing opinions and interpretations on whether visible labels are required by WCAG 2.0 on things like form elements, row and column headings, and interactive elements (widgets). Often the argument is made that when such relationships and labels are visible to one set of sighted users, that those relationships and labels can be made to be perceivable to assistive technology users as well, but not the other way around.  I even advocate as a best practice that most any and all information perceivable to an assistive technology user should be made visible to sighted users too.

Some common interactive elements or widgets can sometimes be an exception, for example:
        1. do all carousel widgets need a visible label?
        2. do all expandable/collapsable tree widgets need a visible label?
        3. Once you know what the widget is, do you really want to clutter up the visible display with labels?

Some rows and columns in a data table can sometimes be an exception, for example: columns in data tables have an implied heading, or a row has no row heading (or only one that is implied) because of the type of information in that column or row. A column with just dates may have an implied heading of "Date", but no visible heading.

Some form controls can sometimes have an implied label, for example when there are 5 radio buttons in a series, with the 1st one labeled Strongly Agree, the last one labeled Strongly Disagree One, the middle radio button visible labeled "Neutral", but the 2nd and 4th radio buttons are not visible labeled because of limited space.

Many subject matter experts interpret WCAG as not requiring a visible label on all form elements, row and column headings, or all interactive elements, because many interpret the following from WCAG 2.0 Success Criteria:

1.3.3 Info and Relationships says that when a label is presented visually, that it also be programmatically determined, but not that is has to be presented visibly.

2.4.2 Page Titleddoes require a page title, and it implies that they be "perceivable" to all users when it says: "this success criterion benefits all users in allowing users to quickly and easily identify whether the information contained in the Web page is relevant to their needs."

2.4.6 Headings and Labels does not require headings or labels. This success criterion requires that if headings or labels are provided, they be descriptive. ('descriptive' is subjective, which is one reason its level AA). Also note that, if headings or labels are provided, they must meet 1.3.1.

4.1.2 Name, Role, Value says that the name has to be programmatically determined - not that it has to be visible.


WCAG References and links:
1.3.1<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#content-structure-separation-programmatic>Info and Relationships: Information, structure<https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#structuredef>, and relationships<https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#relationshipsdef>conveyed through presentation<https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#presentationdef>can be programmatically determined<https://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html#programmaticallydetermineddef> or are available in text. (Level A)

2.4.2<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-title>Page Titled: Web pages<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-title.html#webpagedef> have titles that describe topic or purpose. (Level A)

2.4.6<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#navigation-mechanisms-descriptive>Headings and Labels: Headings and labels<https://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-descriptive.html#labeldef>describe topic or purpose. (Level AA)

4.1.2<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#ensure-compat-rsv>Name, Role, Value: For all user interface components<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#user-interface-componentdef> (including but not limited to: form elements, links and components generated by scripts), the name<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#namedef>and role<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#roledef>can be programmatically determined<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#programmaticallydetermineddef>; states, properties, and values that can be set by the user can be programmatically set<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#programmaticallysetdef>; and notification of changes to these items is available to user agents<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#useragentdef>, including assistive technologies<https://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html#atdef>. (Level A)

Note: This success criterion is primarily for Web authors who develop or script their own user interface components. For example, standard HTML controls already meet this success criterion when used according to specification.


UAAG 1.0 did have Guideline 2 "Ensure that users have access to all content, notably conditional content<https://www.w3.org/TR/UAAG10/glossary.html#def-conditional-content> that may have been provided to meet the requirements of the [WCAG]
UAAG 2.0 Draft does not seem to have a success criteria to render the invisible labels that were added to meet success criteria.
Is there a gap in the requirements between WCAG and UAAG that disproportionately affect sighted users with cognitive disabilities?

Does anyone have a difffering opinon or interpretation of WCAG 2.0.  Seems to me that for better visual preceivability, better cognitive understanding, and better interactive expereince that everyone, including those using unaided browsers should be able to determine the label of the form element,, column or row heading, and label of the interactive elements (software widgets)?
___________
Regards,
Phill Jenkins,
Accessibility Business Development Executive
IBM Research - IBM Accessibility
ibm.com/able<http://www.ibm.com/able>
facebook.com/IBMAccessibility<http://www.facebook.com/IBMAccessibility>
twitter.com/IBMAccess<http://twitter.com/IBMAccess>
Received on Tuesday, 22 March 2016 22:42:09 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 22 March 2016 22:42:10 UTC