E-mail List Archives

Search E-mail List Archives for

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

From: Paul J. Adam
Date: Wed, Nov 18 2015 1:48PM
Subject: Does WCAG require that when you click a label it checks the checkbox or radio button?
No previous message | Next message →

It seems most people are saying that it's only a "Best Practice" that when you click a label for a checkbox or radio button that the box gets checked.

My argument is that if you don't make the label check the box then you're failing WCAG's info and relationships requirement.

As an example see this demo on creating an ARIA checkbox:

https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html <https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html>

Standard checkbox coding with FOR/ID looks like this:

<input id="signup" type="checkbox" />
<label for="signup">Sign me up!</label>

When you click the label "Sign me up!" it checks the box.

I'm hearing from most people that the use of a title attribute as an accessible name on a checkbox without a clickable label passes WCAG and the label connection is not required.

So the code is WCAG Compliant?
<input title="Sign me up!" type="checkbox" />
<label>Sign me up!</label>

There have been other experts who said they'd consider it a failure so maybe I'm not crazy? ;)

I see that WebAIM's checklist reads about 1.3.1:
http://webaim.org/standards/wcag/checklist <http://webaim.org/standards/wcag/checklist>;

Success Criteria WebAIM's Recommendations
1.3.1 Info and Relationships <http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic>;
(Level A)
Semantic markup <http://webaim.org/techniques/semanticstructure/>; is used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately.
Tables <http://webaim.org/techniques/tables/data>; are used for tabular data. Where necessary, data cells are associated with their headers. Data table captions and summaries are used where appropriate.
Text labels are associated with form input elements. Related form elements are grouped with fieldset/legend.
"Text labels are associated with form input elements. Related form elements are grouped with fieldset/legend."

What's the WebAIM definition of "associated"? My definition is that when you click the label it checks the checkbox :)

What are your thoughts?

Thanks!

Paul J. Adam
Accessibility Evangelist
www.deque.com

From: Sean Curtis
Date: Wed, Nov 18 2015 2:10PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

I think you're right — the label is actually the thing that fails here. It isn't associated with the required element.

From a purely UX perspective I'd reject whatever pull request that code was on.

Cheers,

Sean

> On 19 Nov 2015, at 7:48 AM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
> It seems most people are saying that it's only a "Best Practice" that when you click a label for a checkbox or radio button that the box gets checked.
>
> My argument is that if you don't make the label check the box then you're failing WCAG's info and relationships requirement.
>
> As an example see this demo on creating an ARIA checkbox:
>
> https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html <https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html>
>
> Standard checkbox coding with FOR/ID looks like this:
>
> <input id="signup" type="checkbox" />
> <label for="signup">Sign me up!</label>
>
> When you click the label "Sign me up!" it checks the box.
>
> I'm hearing from most people that the use of a title attribute as an accessible name on a checkbox without a clickable label passes WCAG and the label connection is not required.
>
> So the code is WCAG Compliant?
> <input title="Sign me up!" type="checkbox" />
> <label>Sign me up!</label>
>
> There have been other experts who said they'd consider it a failure so maybe I'm not crazy? ;)
>
> I see that WebAIM's checklist reads about 1.3.1:
> http://webaim.org/standards/wcag/checklist <http://webaim.org/standards/wcag/checklist>;
>
> Success Criteria WebAIM's Recommendations
> 1.3.1 Info and Relationships <http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic>;
> (Level A)
> Semantic markup <http://webaim.org/techniques/semanticstructure/>; is used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>), emphasized or special text (<strong>, <code>, <abbr>, <blockquote>, for example), etc. Semantic markup is used appropriately.
> Tables <http://webaim.org/techniques/tables/data>; are used for tabular data. Where necessary, data cells are associated with their headers. Data table captions and summaries are used where appropriate.
> Text labels are associated with form input elements. Related form elements are grouped with fieldset/legend.
> "Text labels are associated with form input elements. Related form elements are grouped with fieldset/legend."
>
> What's the WebAIM definition of "associated"? My definition is that when you click the label it checks the checkbox :)
>
> What are your thoughts?
>
> Thanks!
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
> > > >

From: Patrick H. Lauke
Date: Wed, Nov 18 2015 2:13PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 18/11/2015 20:48, Paul J. Adam wrote:
> It seems most people are saying that it's only a "Best Practice" that
> when you click a label for a checkbox or radio button that the box
> gets checked.
>
> My argument is that if you don't make the label check the box then
> you're failing WCAG's info and relationships requirement.
>
> As an example see this demo on creating an ARIA checkbox:
>
> https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html
> <https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html>
>
> Standard checkbox coding with FOR/ID looks like this:
>
> <input id="signup" type="checkbox" /> <label for="signup">Sign me
> up!</label>
>
> When you click the label "Sign me up!" it checks the box.
>
> I'm hearing from most people that the use of a title attribute as an
> accessible name on a checkbox without a clickable label passes WCAG
> and the label connection is not required.
>
> So the code is WCAG Compliant? <input title="Sign me up!"
> type="checkbox" /> <label>Sign me up!</label>
>
> There have been other experts who said they'd consider it a failure
> so maybe I'm not crazy? ;)
>
> I see that WebAIM's checklist reads about 1.3.1:
> http://webaim.org/standards/wcag/checklist
> <http://webaim.org/standards/wcag/checklist>;
>
> Success Criteria WebAIM's Recommendations 1.3.1 Info and
> Relationships
> <http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic>;
>
>
(Level A)
> Semantic markup <http://webaim.org/techniques/semanticstructure/>; is
> used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>),
> emphasized or special text (<strong>, <code>, <abbr>, <blockquote>,
> for example), etc. Semantic markup is used appropriately. Tables
> <http://webaim.org/techniques/tables/data>; are used for tabular data.
> Where necessary, data cells are associated with their headers. Data
> table captions and summaries are used where appropriate. Text labels
> are associated with form input elements. Related form elements are
> grouped with fieldset/legend. "Text labels are associated with form
> input elements. Related form elements are grouped with
> fieldset/legend."
>
> What's the WebAIM definition of "associated"? My definition is that
> when you click the label it checks the checkbox :)
>
> What are your thoughts?

Note that the actual wording of the WCAG SC does not mention anything
specific about "associated".

"1.3.1 Info and Relationships: Information, structure, and relationships
conveyed through presentation can be programmatically determined or are
available in text. (Level A)"

and, per the "Understanding..." doc
http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html

"The intent of this Success Criterion is to ensure that information and
relationships that are implied by visual or auditory formatting are
preserved when the presentation format changes."

Now, we can have a philosophical, hair-splitting discussion about
whether (for whatever reason) not marking up visible label text as a
<label>, and instead injecting it some other way (e.g. with aria-label,
or title, or some other method that takes part in the accessible name
algorithm) is a way of "programmatically determining" (though
duplicating) the relationship or not, and whether this would (in an
unnecessarily convoluted way, granted) "preserve" the info/relationship.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Lucy Greco
Date: Wed, Nov 18 2015 2:17PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

lets drop the spec and every thing else and think of this in a reel life
case
a low vision user sees the label only and is not able to find the check
box it self being referred to yes this fails if that person can't click
the only thing they can see that refers to the item they want. let stop
getting stuck on the spec and say does this work yay or nay and i say nay


On Wed, Nov 18, 2015 at 1:13 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 18/11/2015 20:48, Paul J. Adam wrote:
>
>> It seems most people are saying that it's only a "Best Practice" that
>> when you click a label for a checkbox or radio button that the box
>> gets checked.
>>
>> My argument is that if you don't make the label check the box then
>> you're failing WCAG's info and relationships requirement.
>>
>> As an example see this demo on creating an ARIA checkbox:
>>
>>
>> https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html
>> <
>> https://accessibility.oit.ncsu.edu/training/accessibility-handbook/aria-checkbox.html
>> >
>>
>> Standard checkbox coding with FOR/ID looks like this:
>>
>> <input id="signup" type="checkbox" /> <label for="signup">Sign me
>> up!</label>
>>
>> When you click the label "Sign me up!" it checks the box.
>>
>> I'm hearing from most people that the use of a title attribute as an
>> accessible name on a checkbox without a clickable label passes WCAG
>> and the label connection is not required.
>>
>> So the code is WCAG Compliant? <input title="Sign me up!"
>> type="checkbox" /> <label>Sign me up!</label>
>>
>> There have been other experts who said they'd consider it a failure
>> so maybe I'm not crazy? ;)
>>
>> I see that WebAIM's checklist reads about 1.3.1:
>> http://webaim.org/standards/wcag/checklist
>> <http://webaim.org/standards/wcag/checklist>;
>>
>> Success Criteria WebAIM's Recommendations 1.3.1 Info and
>> Relationships
>> <http://www.w3.org/TR/WCAG20/#content-structure-separation-programmatic>;
>>
>>
>> (Level A)
>
>> Semantic markup <http://webaim.org/techniques/semanticstructure/>; is
>> used to designate headings (<h1>), lists (<ul>, <ol>, and <dl>),
>> emphasized or special text (<strong>, <code>, <abbr>, <blockquote>,
>> for example), etc. Semantic markup is used appropriately. Tables
>> <http://webaim.org/techniques/tables/data>; are used for tabular data.
>> Where necessary, data cells are associated with their headers. Data
>> table captions and summaries are used where appropriate. Text labels
>> are associated with form input elements. Related form elements are
>> grouped with fieldset/legend. "Text labels are associated with form
>> input elements. Related form elements are grouped with
>> fieldset/legend."
>>
>> What's the WebAIM definition of "associated"? My definition is that
>> when you click the label it checks the checkbox :)
>>
>> What are your thoughts?
>>
>
> Note that the actual wording of the WCAG SC does not mention anything
> specific about "associated".
>
> "1.3.1 Info and Relationships: Information, structure, and relationships
> conveyed through presentation can be programmatically determined or are
> available in text. (Level A)"
>
> and, per the "Understanding..." doc
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/content-structure-separation-programmatic.html
>
> "The intent of this Success Criterion is to ensure that information and
> relationships that are implied by visual or auditory formatting are
> preserved when the presentation format changes."
>
> Now, we can have a philosophical, hair-splitting discussion about whether
> (for whatever reason) not marking up visible label text as a <label>, and
> instead injecting it some other way (e.g. with aria-label, or title, or
> some other method that takes part in the accessible name algorithm) is a
> way of "programmatically determining" (though duplicating) the relationship
> or not, and whether this would (in an unnecessarily convoluted way,
> granted) "preserve" the info/relationship.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>
> > > > >



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

From: Patrick H. Lauke
Date: Wed, Nov 18 2015 2:32PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 18/11/2015 21:17, Lucy Greco wrote:
> lets drop the spec and every thing else and think of this in a reel life
> case
> a low vision user sees the label only and is not able to find the check
> box it self being referred to yes this fails if that person can't click
> the only thing they can see that refers to the item they want. let stop
> getting stuck on the spec and say does this work yay or nay and i say nay

Sure, but the original question was about whether or not this fails WCAG
2.0. There are many things that nominally pass the word and letter of
WCAG, but are still suboptimal or outright broken...but if the context
is an actual audit, you have to pass/fail based specifically on the spec
(or at least document your interpretation of the spec). This is not to
say that even if you pass something, you can't make very strong
recommendations about dropping a certain pattern or technique used.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Moore,Michael (Accessibility) (HHSC)
Date: Wed, Nov 18 2015 6:23PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

I think that this is another example of what happens when we attempt to test in accessibility rather than design for accessibility. I have been involved in more projects than I care to remember where the last step before release is the accessibility audit. Problems found at this point tend to result in blown schedules and costly repairs. In that situation, I would be more likely to pass 1.3.1 since the use of a span does not convey any incorrect structure. I would also include a note that the use of title in that instance is not best practice and should be corrected in conjunction with a future update. I would also request that design specifications/style guide/coding guide be updated to require that visible labels use the label element and the for attribute.

The example below actually demonstrates two accessibility problems that could have been avoided if the design and development teams included accessibility SMEs. If someone using a screen magnifier cannot find the checkbox beside the label there is likely way to much white space between the label and the checkbox. Using the label element rather than the title to bind the accessible name to the checkbox and increase the click area provides better usability for mouse users and support for people using screen readers.

Mike Moore
Accessibility Coordinator
Texas Health and Human Services Commission
Civil Rights Office
(512) 438-3431 (Office)

From: Jonathan Avila
Date: Wed, Nov 18 2015 8:34PM
Subject: Re: Does WCAG require that when you click a label it checksthe checkbox or radio button?
← Previous message | Next message →

> It seems most people are saying that it's only a "Best Practice" that when you click a label for a checkbox or radio button that the box gets checked.

Yes, that is how I read WCAG 2. There are techniques such as H65 that are deemed sufficient to meet SC 1.3.1 (http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H65) While the text of H65 implies it's only for situations where there can't be text associated visually, however, the check in the technique does not mandate this.

Keep in mind the following:
* aria-labelledby can be used to associate labels and form fields but browsers do not support the user clicking/touching the label to focus/check the field. So you have a case where the technical criteria is met but the functional benefits are not attained.
* SC 3.3.2 Labels and Instructions does require that visual labels be present. So a visual label is always needed -- although labels don't have to be text -- they could be icons or other controls and they don't have to be associated programmatically. On a related note the programmatic name and label should match to support users of speech recognition.

Jonathan
--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Sailesh Panchang
Date: Thu, Nov 19 2015 7:14AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

ARIA16 (aria-labelledby) notes: "Clicking on a label focuses the
associated form field. This does not occur with aria-labelledby. If
this behaviour is required then use label or implement this
functionality using scripting".
I do note that ARIA16 is called 'Using aria-labelledby to provide a
name for user interface controls' i.e. for 4.1.2 but it is listed as
sufficient for 1.3.1 too.
So a div role=checkbox and aria-labelledby= xxx> type of control, will
pass WCAG2 (including 1.3.1)  even if  clicking label does not
activate the checkbox on that platform.
It was clear in HTML4: When a  LABEL  element receives  focus, it
passes the focus on to its associated control. This is a UA function.
Unfortunately WCAG2 does not mandate this label functionality.
If I am interpreting this right, in HTML5 it says: the UA should match
the platform's label behavior. The default activation  behavior for a
label is to do nothing.
And even on a platform where the label moves focus to the control, no
WCAG2 SC requires this.
So an accessibility feature built in to browser functionality is being
watered down or not given due respect even though it helps a group of
users.
Unfortunately therefore, one cannot call a 'fail' when a form control
with a visible label relies on title / aria-label / aria-labelledby
to convey purpose of control instead of the HTML LABEL element
implicitly or with explicit association.

Best regards,
Sailesh Panchang


On 11/18/15, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>> It seems most people are saying that it's only a "Best Practice" that when
>> you click a label for a checkbox or radio button that the box gets
>> checked.
>
> Yes, that is how I read WCAG 2. There are techniques such as H65 that are
> deemed sufficient to meet SC 1.3.1
> (http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H65) While the text
> of H65 implies it's only for situations where there can't be text associated
> visually, however, the check in the technique does not mandate this.
>
> Keep in mind the following:
> * aria-labelledby can be used to associate labels and form fields but
> browsers do not support the user clicking/touching the label to focus/check
> the field. So you have a case where the technical criteria is met but the
> functional benefits are not attained.
> * SC 3.3.2 Labels and Instructions does require that visual labels be
> present. So a visual label is always needed -- although labels don't have
> to be text -- they could be icons or other controls and they don't have to
> be associated programmatically. On a related note the programmatic name and
> label should match to support users of speech recognition.
>
> Jonathan
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED =
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Paul Adam
Date: Thu, Nov 19 2015 9:09AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

H65 has no examples with radio buttons or checkboxes. I can't find any examples in WCAG's documentation that show a radio button or checkout without a clickable label.

H65: Using the title attribute to identify form controls when the label element cannot be used

In my examples the visible <label> can can be used and if not the developer can use an aria-labelledby string reference and JavaScript to make a "faux" label that would check the checkbox.

I think WCAG does require you emulate the native behavior of a checkbox with a clickable label if you were to make an ARIA checkbox.

I also think if you use role=button you're required to make it work with the spacebar key like a native <button> element but maybe I'm wrong there too! ;)

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 18, 2015, at 9:34 PM, Jonathan Avila < = EMAIL ADDRESS REMOVED = > wrote:
>
>> It seems most people are saying that it's only a "Best Practice" that when you click a label for a checkbox or radio button that the box gets checked.
>
> Yes, that is how I read WCAG 2. There are techniques such as H65 that are deemed sufficient to meet SC 1.3.1 (http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H65 <http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/H65>;) While the text of H65 implies it's only for situations where there can't be text associated visually, however, the check in the technique does not mandate this.
>
> Keep in mind the following:
> * aria-labelledby can be used to associate labels and form fields but browsers do not support the user clicking/touching the label to focus/check the field. So you have a case where the technical criteria is met but the functional benefits are not attained.
> * SC 3.3.2 Labels and Instructions does require that visual labels be present. So a visual label is always needed -- although labels don't have to be text -- they could be icons or other controls and they don't have to be associated programmatically. On a related note the programmatic name and label should match to support users of speech recognition.
>
> Jonathan
> --
> Jonathan Avila
> Chief Accessibility Officer
> SSB BART Group
> = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = >
>
> 703-637-8957 (o)
> Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter
>
>
>

From: Paul Adam
Date: Thu, Nov 19 2015 9:16AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

ARIA16 has no examples with radio buttons or checkboxes and the example that has a <label> includes the FOR/ID association to connected it to a <select> input. http://www.w3.org/TR/WCAG20-TECHS/ARIA16.html

I've not found any examples in WCAG's docs that show radio button or checkboxes without clickable labels.

Techniques are all informative, the normative part says "Info and Relationships" are required for 1.3.1 to me that requires a programmatic relationship not just an accessible name.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 8:14 AM, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
>
> ARIA16 (aria-labelledby) notes: "Clicking on a label focuses the
> associated form field. This does not occur with aria-labelledby. If
> this behaviour is required then use label or implement this
> functionality using scripting".
> I do note that ARIA16 is called 'Using aria-labelledby to provide a
> name for user interface controls' i.e. for 4.1.2 but it is listed as
> sufficient for 1.3.1 too.
> So a div role=checkbox and aria-labelledby= xxx> type of control, will
> pass WCAG2 (including 1.3.1) even if clicking label does not
> activate the checkbox on that platform.
> It was clear in HTML4: When a LABEL element receives focus, it
> passes the focus on to its associated control. This is a UA function.
> Unfortunately WCAG2 does not mandate this label functionality.
> If I am interpreting this right, in HTML5 it says: the UA should match
> the platform's label behavior. The default activation behavior for a
> label is to do nothing.
> And even on a platform where the label moves focus to the control, no
> WCAG2 SC requires this.
> So an accessibility feature built in to browser functionality is being
> watered down or not given due respect even though it helps a group of
> users.
> Unfortunately therefore, one cannot call a 'fail' when a form control
> with a visible label relies on title / aria-label / aria-labelledby
> to convey purpose of control instead of the HTML LABEL element
> implicitly or with explicit association.
>
> Best regards,
> Sailesh Panchang

From: Patrick H. Lauke
Date: Thu, Nov 19 2015 9:34AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 19/11/2015 16:09, Paul Adam wrote:
> I think WCAG does require you emulate the native behavior of a checkbox with a clickable label if you were to make an ARIA checkbox.
>
> I also think if you use role=button you're required to make it work with the spacebar key like a native <button> element but maybe I'm wrong there too! ;)

[citation needed]

*smile*

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: John Foliot
Date: Thu, Nov 19 2015 9:51AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Paul Adam wrote:
>
> I think WCAG does require you emulate the native behavior of a checkbox with a
> clickable label if you were to make an ARIA checkbox.

Can you kindly point us to the normative text in WCAG that leads you to believe this?

>
> I also think if you use role=button you're required to make it work with the
> spacebar key like a native <button> element but maybe I'm wrong there too! ;)

Can you kindly point us to the normative text in WCAG that leads you to believe this?

JF

From: Paul Adam
Date: Thu, Nov 19 2015 9:57AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html

2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)

I'm choosing NOT to water down WCAG and say that a button element only has to work with enter key when in reality all native <button>s work with enter and spacebar.

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

I'm saying that if you use the role of button but you don't implement that role like a native button then you're not meeting Name, Role, Value.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 10:51 AM, John Foliot < = EMAIL ADDRESS REMOVED = > wrote:
>
> Paul Adam wrote:
>>
>> I think WCAG does require you emulate the native behavior of a checkbox with a
>> clickable label if you were to make an ARIA checkbox.
>
> Can you kindly point us to the normative text in WCAG that leads you to believe this?
>
>>
>> I also think if you use role=button you're required to make it work with the
>> spacebar key like a native <button> element but maybe I'm wrong there too! ;)
>
> Can you kindly point us to the normative text in WCAG that leads you to believe this?
>
> JF
>
> > > >

From: Patrick H. Lauke
Date: Thu, Nov 19 2015 10:04AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 19/11/2015 16:57, Paul Adam wrote:
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html
>
> 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
>
> I'm choosing NOT to water down WCAG and say that a button element only has to work with enter key when in reality all native <button>s work with enter and spacebar.

You talk of "watering down", but: unless there is normative text that
specifically says so, all we're "watering down" here is *your*
interpretation.

> http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
> 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
>
> I'm saying that if you use the role of button but you don't implement that role like a native button then you're not meeting Name, Role, Value.

Again, that seems to be more *your* interpretation, rather than what
WCAG actually normatively says.

To be clear: I understand that in practice these things should be done
(and indeed, in many reports for clients, I've been known to write
lengthy stretches starting with "Although X meets the letter of WCAG, we
however strongly advise that..."). But, if you are tasked with auditing
against WCAG, it's best IMHO not to fail a particular SC based on your
expanded interpretation that is nowhere in the actual normative text.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Paul Adam
Date: Thu, Nov 19 2015 10:07AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

It says All functionality is operable through keyboard interface. It does not say "and the Enter key alone is sufficient" or this or that key must work.

If it does not operate with the keyboard like a real <button> then how is it keyboard operable?

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 11:04 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 19/11/2015 16:57, Paul Adam wrote:
>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/keyboard-operation-keyboard-operable.html
>>
>> 2.1.1 Keyboard: All functionality of the content is operable through a keyboard interface without requiring specific timings for individual keystrokes, except where the underlying function requires input that depends on the path of the user's movement and not just the endpoints. (Level A)
>>
>> I'm choosing NOT to water down WCAG and say that a button element only has to work with enter key when in reality all native <button>s work with enter and spacebar.
>
> You talk of "watering down", but: unless there is normative text that specifically says so, all we're "watering down" here is *your* interpretation.
>
>> http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html
>> 4.1.2 Name, Role, Value: For all user interface components (including but not limited to: form elements, links and components generated by scripts), the name and role can be programmatically determined; states, properties, and values that can be set by the user can be programmatically set; and notification of changes to these items is available to user agents, including assistive technologies. (Level A)
>>
>> I'm saying that if you use the role of button but you don't implement that role like a native button then you're not meeting Name, Role, Value.
>
> Again, that seems to be more *your* interpretation, rather than what WCAG actually normatively says.
>
> To be clear: I understand that in practice these things should be done (and indeed, in many reports for clients, I've been known to write lengthy stretches starting with "Although X meets the letter of WCAG, we however strongly advise that..."). But, if you are tasked with auditing against WCAG, it's best IMHO not to fail a particular SC based on your expanded interpretation that is nowhere in the actual normative text.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Patrick H. Lauke
Date: Thu, Nov 19 2015 11:00AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 19/11/2015 17:07, Paul Adam wrote:
> It says All functionality is operable through keyboard interface. It does not say "and the Enter key alone is sufficient" or this or that key must work.

Is the Enter key part of the keyboard interface? Yes.

If a faked button reacts when the user hits Enter, and Enter is part of
the keyboard interface, does that mean that the faked button is operable
through keyboard interface? Yes.

> If it does not operate with the keyboard like a real <button> then how is it keyboard operable?

There is no normative requirement about "operating like a *real*" this
or the other in the SC.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Paul Adam
Date: Thu, Nov 19 2015 11:17AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

So WCAG is fine if let's say I make all my buttons operable with the Escape key only. No enter or space bar must press escape to activate the buttons. That would not fail keyboard operable? If not, WCAG indeed has many loopholes.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 12:00 PM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
> On 19/11/2015 17:07, Paul Adam wrote:
>> It says All functionality is operable through keyboard interface. It does not say "and the Enter key alone is sufficient" or this or that key must work.
>
> Is the Enter key part of the keyboard interface? Yes.
>
> If a faked button reacts when the user hits Enter, and Enter is part of the keyboard interface, does that mean that the faked button is operable through keyboard interface? Yes.
>
>> If it does not operate with the keyboard like a real <button> then how is it keyboard operable?
>
> There is no normative requirement about "operating like a *real*" this or the other in the SC.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Chagnon | PubCom.com
Date: Thu, Nov 19 2015 12:12PM
Subject: Re: Does WCAG require that when you click a label itchecks the checkbox or radio button?
← Previous message | Next message →

Paul Adam wrote:
"WCAG indeed has many loopholes."

In a way, yes, you're right about that.
To me, WCAG is one of the most poorly written, organized, and presented set of regulations/standards/guidelines I've ever had to deal with. That's my opinion based on 30+ years of professional editing and publishing of US Federal regulations, legislation, and standards.

To any of us in the professional communications and publishing industries, it's very clear to us that W3C/WAI needs to hire some professional writers and editors to put this information in a better state -- less redundancy, less confusion, clearer language and better understanding.

Part of accessibility is the use of plain language, a movement started decades ago by governments worldwide to make our content more understandable to a diverse population.

As it is now, WCAG is the antithesis of plain language.

No matter how well-intentioned all the creators of WCAG are, when it comes time for accessibility lawsuits and formal complaints, this type of poorly-written gibberish will undermine our cases and only serve to line the pockets of lawyers who could easily argue to dismiss the accessibility case.

This confusion also spawns so much of our email posts on this list.

WAI, please use plain language.

And hire professional writers and editors to overhaul the language and presentation of WCAG -- not necessarily the standards themselves, but their presentation.

--Bevi Chagnon

From: Patrick H. Lauke
Date: Thu, Nov 19 2015 12:51PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 19/11/2015 18:17, Paul Adam wrote:
> So WCAG is fine if let's say I make all my buttons operable with the
> Escape key only. No enter or space bar must press escape to activate
> the buttons. That would not fail keyboard operable? If not, WCAG
> indeed has many loopholes.

Bingo.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Patrick H. Lauke
Date: Thu, Nov 19 2015 1:00PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 19/11/2015 19:51, Patrick H. Lauke wrote:
> On 19/11/2015 18:17, Paul Adam wrote:
>> So WCAG is fine if let's say I make all my buttons operable with the
>> Escape key only. No enter or space bar must press escape to activate
>> the buttons. That would not fail keyboard operable? If not, WCAG
>> indeed has many loopholes.
>
> Bingo.

And to expand that: this is why there's a difference between
"conformance" and "accessibility" in many cases.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Sean Curtis
Date: Thu, Nov 19 2015 1:36PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

If the custom button receives focus wouldn't most screen readers tell them how to activate it? Wouldn't this be enter or space? There are conventions around this stuff surely? If WCAG can be passed by some inaccessible UI then we need to rectify something...

Cheers,

Sean

> On 20 Nov 2015, at 6:51 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 19/11/2015 18:17, Paul Adam wrote:
>> So WCAG is fine if let's say I make all my buttons operable with the
>> Escape key only. No enter or space bar must press escape to activate
>> the buttons. That would not fail keyboard operable? If not, WCAG
>> indeed has many loopholes.
>
> Bingo.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Sean Curtis
Date: Thu, Nov 19 2015 1:37PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

These differences should be raised as bugs and fixed right?

Cheers,

Sean

> On 20 Nov 2015, at 7:00 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>
>> On 19/11/2015 19:51, Patrick H. Lauke wrote:
>>> On 19/11/2015 18:17, Paul Adam wrote:
>>> So WCAG is fine if let's say I make all my buttons operable with the
>>> Escape key only. No enter or space bar must press escape to activate
>>> the buttons. That would not fail keyboard operable? If not, WCAG
>>> indeed has many loopholes.
>>
>> Bingo.
>
> And to expand that: this is why there's a difference between "conformance" and "accessibility" in many cases.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > >

From: Jonathan Avila
Date: Thu, Nov 19 2015 1:39PM
Subject: Re: Does WCAG require that when you click a label itchecks the checkbox or radio button?
← Previous message | Next message →

> If it does not operate with the keyboard like a real <button> then how is it keyboard operable?

Technically the button wouldn't even need to be in the focus order and could be operable through a documented keystroke such as control+shift+f1. Obviously this would strongly be discouraged in most situations but it's still operable with a keyboard. I think what you are asking is what is the definition of operable -- simply put "it can be used" and it can with a keyboard. Now there could certainly be other accessibility support concerns raised and functional accessibility issues that pose a risk to organizations here and any good accessibility consultant should strongly steer folks toward to right way of doing things for the sake of users and the organization.

Best Regards,

Jonathan

--
Jonathan Avila
Chief Accessibility Officer
SSB BART Group
= EMAIL ADDRESS REMOVED =

703-637-8957 (o)
Follow us: Facebook | Twitter | LinkedIn | Blog | Newsletter

From: Julie Romanowski
Date: Thu, Nov 19 2015 2:14PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

We need to remember that assistive technologies include hardware as well as software. We're not just talking about screen readers.

There are employees with mobility challenges at our company who use special types of ergonomic mice to access their computers. For example, one person uses a foot mouse (also called a slipper mouse) and another person uses a head mouse. Both of them have poor fine motor control and it's very difficult to impossible for them to click on small items such as radio buttons or check boxes. Coding the controls and their respective labels correctly using the id and for attributes provides a much larger area for these two people to click on, making selecting the controls much easier.

In the "Understanding Techniques for WCAG Success Criteria" documentation under "Sufficient Techniques" (http://www.w3.org/TR/2015/NOTE-UNDERSTANDING-WCAG20-20150226/understanding-techniques.html#ut-understanding-techniques-sufficient-head) it states that "If web content implements the sufficient techniques for a given criterion correctly and it is accessibility-supported for the content's users, it conforms to that success criterion". Maybe I'm misunderstanding the WCAG 2.0 definition of accessibility support (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-supported-definition-head), but I take this to mean that using aria-labelledby to label radio buttons will fail SC 4.1.2 Name, Role, Value, as it isn't " accessibility-supported for the content's users" (the people using ergonomic mice as AT).

Thoughts?

From: Patrick H. Lauke
Date: Thu, Nov 19 2015 2:35PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 19/11/2015 21:14, Julie Romanowski wrote:
> We need to remember that assistive technologies include hardware as
> well as software. We're not just talking about screen readers.
>
> There are employees with mobility challenges at our company who use
> special types of ergonomic mice to access their computers. For
> example, one person uses a foot mouse (also called a slipper mouse)
> and another person uses a head mouse. Both of them have poor fine
> motor control and it's very difficult to impossible for them to click
> on small items such as radio buttons or check boxes. Coding the
> controls and their respective labels correctly using the id and for
> attributes provides a much larger area for these two people to click
> on, making selecting the controls much easier.

That is only one possible technique. Another would be to make the actual
radio button or checkbox very big. So it's not a cut-and-dry "if the
label isn't a proper <label>, and not assigned explicitly using
for="..." attribute, it's a fail.
But in both cases, I don't believe any WCAG 2.0 SC specifically deals
with target/touch sizes (something that has since been brought up in the
specific context of touchscreens in the mobile a11y TF, but I would have
liked to see tackled more generally even on "desktop" for mouse users -
see
https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/0037.html)

> In the "Understanding Techniques for WCAG Success Criteria"
> documentation under "Sufficient Techniques"
> (http://www.w3.org/TR/2015/NOTE-UNDERSTANDING-WCAG20-20150226/understanding-techniques.html#ut-understanding-techniques-sufficient-head)
> it states that "If web content implements the sufficient techniques
> for a given criterion correctly and it is accessibility-supported for
> the content's users, it conforms to that success criterion". Maybe
> I'm misunderstanding the WCAG 2.0 definition of accessibility support
> (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-supported-definition-head),
> but I take this to mean that using aria-labelledby to label radio
> buttons will fail SC 4.1.2 Name, Role, Value, as it isn't "
> accessibility-supported for the content's users" (the people using
> ergonomic mice as AT).

Why 4.1.2? "For all user interface components (including but not limited
to: form elements, links and components generated by scripts), the name
and role can be programmatically determined; states, properties, and
values that can be set by the user can be programmatically set; and
notification of changes to these items is available to user agents,
including assistive technologies. (Level A)" ... nowhere here is there
talk of "users must be able to operate controls with their specific
input technology" or similar. This is about exposing name, role, state,
value programmatically. Unless you're thinking of "allow themselves to
be controlled by assistive technologies" in the intent for the SC
http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html ...
which, I'd say, is a bit of a stretch, IMO.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Birkir R. Gunnarsson
Date: Thu, Nov 19 2015 3:08PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

I believe the closest W3C specs come to dictating functionality of
simulated controls is via the ARIA authoring Best Practices.
It is important to understand that these are not normative, but they
do suggest the expected keyboard operation pattern of custom interface
components, including buttons, radiobuttons and checkboxes.
I can suggest to the taskforce, which meets next Monday, whether
content can be added to simulated form controls explaining the
importance of enabling the click-the-label-to-focus functionality, and
we could implement this in our best practice widget examples (which a
lot of smart people are working hard on on Github).
It doesn't change WCAG or the different viewpoints expressed here, but
it could provide encouragement and demonstration on how things should
be done right, and that can at least help point people's brains in the
right direction.
-B



On 11/19/15, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
> On 19/11/2015 21:14, Julie Romanowski wrote:
>> We need to remember that assistive technologies include hardware as
>> well as software. We're not just talking about screen readers.
>>
>> There are employees with mobility challenges at our company who use
>> special types of ergonomic mice to access their computers. For
>> example, one person uses a foot mouse (also called a slipper mouse)
>> and another person uses a head mouse. Both of them have poor fine
>> motor control and it's very difficult to impossible for them to click
>> on small items such as radio buttons or check boxes. Coding the
>> controls and their respective labels correctly using the id and for
>> attributes provides a much larger area for these two people to click
>> on, making selecting the controls much easier.
>
> That is only one possible technique. Another would be to make the actual
> radio button or checkbox very big. So it's not a cut-and-dry "if the
> label isn't a proper <label>, and not assigned explicitly using
> for="..." attribute, it's a fail.
> But in both cases, I don't believe any WCAG 2.0 SC specifically deals
> with target/touch sizes (something that has since been brought up in the
> specific context of touchscreens in the mobile a11y TF, but I would have
> liked to see tackled more generally even on "desktop" for mouse users -
> see
> https://lists.w3.org/Archives/Public/public-mobile-a11y-tf/2015Jul/0037.html)
>
>> In the "Understanding Techniques for WCAG Success Criteria"
>> documentation under "Sufficient Techniques"
>> (http://www.w3.org/TR/2015/NOTE-UNDERSTANDING-WCAG20-20150226/understanding-techniques.html#ut-understanding-techniques-sufficient-head)
>> it states that "If web content implements the sufficient techniques
>> for a given criterion correctly and it is accessibility-supported for
>> the content's users, it conforms to that success criterion". Maybe
>> I'm misunderstanding the WCAG 2.0 definition of accessibility support
>> (http://www.w3.org/TR/UNDERSTANDING-WCAG20/conformance.html#uc-accessibility-supported-definition-head),
>> but I take this to mean that using aria-labelledby to label radio
>> buttons will fail SC 4.1.2 Name, Role, Value, as it isn't "
>> accessibility-supported for the content's users" (the people using
>> ergonomic mice as AT).
>
> Why 4.1.2? "For all user interface components (including but not limited
> to: form elements, links and components generated by scripts), the name
> and role can be programmatically determined; states, properties, and
> values that can be set by the user can be programmatically set; and
> notification of changes to these items is available to user agents,
> including assistive technologies. (Level A)" ... nowhere here is there
> talk of "users must be able to operate controls with their specific
> input technology" or similar. This is about exposing name, role, state,
> value programmatically. Unless you're thinking of "allow themselves to
> be controlled by assistive technologies" in the intent for the SC
> http://www.w3.org/TR/UNDERSTANDING-WCAG20/ensure-compat-rsv.html ...
> which, I'd say, is a bit of a stretch, IMO.
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >


--
Work hard. Have fun. Make history.

From: Julie Romanowski
Date: Thu, Nov 19 2015 3:43PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Thank you, Birkir. :)

From: Julie Romanowski
Date: Thu, Nov 19 2015 4:11PM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Thanks for the mobile a11y TF link, Patrick. I hadn't seen that discussion.

From: Alastair Campbell
Date: Fri, Nov 20 2015 5:55AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Paul Adam wrote:

> "So WCAG is fine if let's say I make all my buttons operable with the
> Escape key only. No enter or space bar must press escape to activate the
> buttons. That would not fail keyboard operable? If not, WCAG indeed has
> many loopholes."
>

And Bevi wrote:
"As it is now, WCAG is the antithesis of plain language."

I think this thread has highlighted some contradictory requirements for
WCAG guidelines:
- Closing loopholes in the detailed implementation, presumably by being
more prescriptive about solutions. (Would you agree with that Paul?)
- Easy to understand.
- Technology agnostic (a goal of WCAG version 2).

I'm sure there are improvements, but one of three requirements cannot be
met in the normative text. If it is more prescriptive, it will be less
tech-agnostic and probably harder to understand. If it is easier to
understand, there will be more loopholes (I think).

I think the balance comes from what helps in practice. Patrick emphasises
"we however strongly advise that...", and we do something similar where we
present the best practice as the default way something should be done.
Usually we find more basic errors and present the best practice, so the
'technical pass' never comes up. Usually if someone knows enough to add a
label and title they'd know enough to use for/id, the technical-pass
scenario is quite rare.

Perhaps you come across more scenarios where developers are using automated
testing or have a very technical view of accessibility and then implement
to 'conformance' instead of 'accessible'?

If so, I would suggest using persuasion tactics that are less about the
guidelines, and more about how people use things.

From Matt May's framework: "This is the problem and this is how it affects
people and you can solve it and if you don't, these are the consequences."
[1]

The consequences might be non-conformance, but in practice I find the human
scenario more persuasive, e.g. Someone using a slipper mouse (thanks Julie)
will struggle to use this, and all you have to do is add a couple of
attributes.

I'd also like to +1 Mike Moore's suggestion to move it upstream, and get
the best practices into their specs/pattern libraries, so the argument
doesn't come up again.

I guess this doesn't answer the question as such, but my response comes
from an appreciation that closing all the possible loopholes in WCAG,
making it easier to understand, and make it work across technologies could
not happen unless all technological advancement is paused for a few years
whilst we wrangle the guidelines!

-Alastair

1]
https://modelviewculture.com/pieces/articulating-and-advocating-for-accessibility

From: Paul Adam
Date: Fri, Nov 20 2015 9:52AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

The problem is that "Best Practices" are considered "nice to haves" or "usability" recommendations that aren't really required to do so they won't get the extra time or money spent on them when people are under tight deadlines and they may not even get pushed to future releases once the "required" issues are fixed.

Even if you say the "Best Practice" has a "Critical" impact to the user with a disability, if it's not required by WCAG then it may not get done unless people are interested in going "above and beyond" the minimum.

So anytime you make something a best practice only then the Accessibility expert has to fight harder to get the issue fixed when it would be easier to move on to the next hundred a11y problems on the site.

I'd rather not have to make experts expend more time on persuasion tactics asking to please implement these best practices when they really should be requirements.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 20, 2015, at 6:55 AM, Alastair Campbell < = EMAIL ADDRESS REMOVED = > wrote:
>
> Paul Adam wrote:
>
>> "So WCAG is fine if let's say I make all my buttons operable with the
>> Escape key only. No enter or space bar must press escape to activate the
>> buttons. That would not fail keyboard operable? If not, WCAG indeed has
>> many loopholes."
>>
>
> And Bevi wrote:
> "As it is now, WCAG is the antithesis of plain language."
>
> I think this thread has highlighted some contradictory requirements for
> WCAG guidelines:
> - Closing loopholes in the detailed implementation, presumably by being
> more prescriptive about solutions. (Would you agree with that Paul?)
> - Easy to understand.
> - Technology agnostic (a goal of WCAG version 2).
>
> I'm sure there are improvements, but one of three requirements cannot be
> met in the normative text. If it is more prescriptive, it will be less
> tech-agnostic and probably harder to understand. If it is easier to
> understand, there will be more loopholes (I think).
>
> I think the balance comes from what helps in practice. Patrick emphasises
> "we however strongly advise that...", and we do something similar where we
> present the best practice as the default way something should be done.
> Usually we find more basic errors and present the best practice, so the
> 'technical pass' never comes up. Usually if someone knows enough to add a
> label and title they'd know enough to use for/id, the technical-pass
> scenario is quite rare.
>
> Perhaps you come across more scenarios where developers are using automated
> testing or have a very technical view of accessibility and then implement
> to 'conformance' instead of 'accessible'?
>
> If so, I would suggest using persuasion tactics that are less about the
> guidelines, and more about how people use things.
>
> From Matt May's framework: "This is the problem and this is how it affects
> people and you can solve it and if you don't, these are the consequences."
> [1]
>
> The consequences might be non-conformance, but in practice I find the human
> scenario more persuasive, e.g. Someone using a slipper mouse (thanks Julie)
> will struggle to use this, and all you have to do is add a couple of
> attributes.
>
> I'd also like to +1 Mike Moore's suggestion to move it upstream, and get
> the best practices into their specs/pattern libraries, so the argument
> doesn't come up again.
>
> I guess this doesn't answer the question as such, but my response comes
> from an appreciation that closing all the possible loopholes in WCAG,
> making it easier to understand, and make it work across technologies could
> not happen unless all technological advancement is paused for a few years
> whilst we wrangle the guidelines!
>
> -Alastair
>
> 1]
> https://modelviewculture.com/pieces/articulating-and-advocating-for-accessibility
> > > >

From: Paul Adam
Date: Fri, Nov 20 2015 9:57AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

That's pretty much what I'm trying to do here and on Twitter and the W3C WAI GitHub Issue Tracker & Email List.

My understanding is that these simple things like matching the behavior of native controls keyboard operability and programmatic relationships of controls to labels are requirements of WCAG.

If they're not requirements then let's please make them requirements.

Do we need a WCAG "Common Sense" Extension?

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 2:37 PM, Sean Curtis < = EMAIL ADDRESS REMOVED = > wrote:
>
> These differences should be raised as bugs and fixed right?
>
> Cheers,
>
> Sean
>
>> On 20 Nov 2015, at 7:00 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> On 19/11/2015 19:51, Patrick H. Lauke wrote:
>>>> On 19/11/2015 18:17, Paul Adam wrote:
>>>> So WCAG is fine if let's say I make all my buttons operable with the
>>>> Escape key only. No enter or space bar must press escape to activate
>>>> the buttons. That would not fail keyboard operable? If not, WCAG
>>>> indeed has many loopholes.
>>>
>>> Bingo.
>>
>> And to expand that: this is why there's a difference between "conformance" and "accessibility" in many cases.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> > > > >

From: Paul Adam
Date: Fri, Nov 20 2015 9:59AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Screen readers do tell the user how to operate the control based on the role. So if you use a certain role the user expects the behavior the screen reader conveys. Seems like a fail if you don't implement the standard convention keyboard operation they'd expect.

Yes I would love to fix this issue with WCAG if it's really not required.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 2:36 PM, Sean Curtis < = EMAIL ADDRESS REMOVED = > wrote:
>
> If the custom button receives focus wouldn't most screen readers tell them how to activate it? Wouldn't this be enter or space? There are conventions around this stuff surely? If WCAG can be passed by some inaccessible UI then we need to rectify something...
>
> Cheers,
>
> Sean
>
>> On 20 Nov 2015, at 6:51 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> On 19/11/2015 18:17, Paul Adam wrote:
>>> So WCAG is fine if let's say I make all my buttons operable with the
>>> Escape key only. No enter or space bar must press escape to activate
>>> the buttons. That would not fail keyboard operable? If not, WCAG
>>> indeed has many loopholes.
>>
>> Bingo.
>>
>> P
>> --
>> Patrick H. Lauke
>>
>> www.splintered.co.uk | https://github.com/patrickhlauke
>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>> >> >> >> > > > >

From: Paul Adam
Date: Fri, Nov 20 2015 10:05AM
Subject: Re: Does WCAG require that when you click a label itchecks the checkbox or radio button?
← Previous message | Next message →

Totally agree! WCAG is open to many different interpretations. I've studied it for many years and I'm always reading the definitions at the bottom of the understanding document to try to decipher its meaning!

I think it's WAY better than Section 508 which is not very specific at all and open to vastly more interpretation.

I don't see the Plain Language in WCAG or 508. You do have to be an expert to understand what's really required.

Paul J. Adam
Accessibility Evangelist
www.deque.com

> On Nov 19, 2015, at 1:12 PM, Chagnon | PubCom.com < = EMAIL ADDRESS REMOVED = > wrote:
>
> Paul Adam wrote:
> "WCAG indeed has many loopholes."
>
> In a way, yes, you're right about that.
> To me, WCAG is one of the most poorly written, organized, and presented set of regulations/standards/guidelines I've ever had to deal with. That's my opinion based on 30+ years of professional editing and publishing of US Federal regulations, legislation, and standards.
>
> To any of us in the professional communications and publishing industries, it's very clear to us that W3C/WAI needs to hire some professional writers and editors to put this information in a better state -- less redundancy, less confusion, clearer language and better understanding.
>
> Part of accessibility is the use of plain language, a movement started decades ago by governments worldwide to make our content more understandable to a diverse population.
>
> As it is now, WCAG is the antithesis of plain language.
>
> No matter how well-intentioned all the creators of WCAG are, when it comes time for accessibility lawsuits and formal complaints, this type of poorly-written gibberish will undermine our cases and only serve to line the pockets of lawyers who could easily argue to dismiss the accessibility case.
>
> This confusion also spawns so much of our email posts on this list.
>
> WAI, please use plain language.
>
> And hire professional writers and editors to overhaul the language and presentation of WCAG -- not necessarily the standards themselves, but their presentation.
>
> --Bevi Chagnon
>
> > > >

From: Chaals McCathie Nevile
Date: Fri, Nov 20 2015 11:22PM
Subject: Re: Fixing WAI's writing style Does WCAG require ...
← Previous message | Next message →

TL;DR: You need to make concrete proposals for changes to text, because
WAI cannot just hire a writer to fix stuff for you. So file bugs against
WCAG.

On Thu, 19 Nov 2015 20:12:07 +0100, Chagnon | PubCom.com
< = EMAIL ADDRESS REMOVED = > wrote:

> Paul Adam wrote:
> "WCAG indeed has many loopholes."
>
> In a way, yes, you're right about that.
[WCAG is badly written, which causes problems, and WAI should hire
professional writers who understand clear communication, regulation, and
standards]

I agree that plain language is important, and a standard should be as
clear as possible.

But asking WAI to hire professional writers is like asking WebAIM to fix
the web's accessibility. There isn't a clear way for it to happen.

WAI is part of W3C, which brings a certain amount of funding. A lot of the
7 WAI staff are employed on, and paid for by, research contracts with the
European Union or US government in some form or other.

W3C specifications are made by practitioners, who volunteer their time to
W3C. Many of them are organisations - TPG, Deque, Yandex, Microsoft,
Pearson, SSB, RNIB, and others you may know which also join W3C, meaning
they pay membership fees which provide the funding I mentioned earlier.

The process to make W3C specifications is roughly as follows:
- Identify something people agrees needs to be clearly specified as a
standard for the Web
- Organise a Working Group to develop a W3C Recommendation.
- That group proposes a series of drafts, which are public and meant to
get very broad public feedback. Most groups, including all WAI groups, now
do all their work in public.
- The group (remember, basically volunteers) respond to feedback, to
improve the documents.
- Convince Tim Berners-Lee that they have done the best job they could
with the resources they had.

If you want better documents, it is important to file comments explaining
the problem, as well as outlining solutions.

Every "W3C Recommendation" has a section called "Status of This Document"
right near the front, that says how to file comments on it. Please do so.

Note that for some time WAI has resisted making substantive changes to
WCAG 2.0

One way to change that would be to start filing bugs if WCAG 2.0 is
ambiguous, or its requirements do not achieve the goals, or the writing is
unclear.

cheers

Chaals

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Chaals McCathie Nevile
Date: Sat, Nov 21 2015 12:02AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On Fri, 20 Nov 2015 17:59:28 +0100, Paul Adam < = EMAIL ADDRESS REMOVED = > wrote:

> Screen readers do tell the user how to operate the control based on the
> role. So if you use a certain role the user expects the behavior the
> screen reader conveys. Seems like a fail if you don't implement the
> standard convention keyboard operation they'd expect.
>
> Yes I would love to fix this issue with WCAG if it's really not required.

Yes, "operable" and "understandable" should combine to mean "I can predict
how it works". And there is a problem with WCAG if that doesn't happen, so
filing bugs against it is the right thing to do.

But there is another problem, related to Alistair's "choose any two"
dilemma. How it works may not be the same on all systems. We have sold the
world on the idea that space and enter make buttons work, because on many
systems they do. But we are on a bad path there.

Complex controls can be implemented in different ways on different
systems, and web authors don't know enough about the user to match their
system.

One example is fundamental to keyboard navigation. Most early browsers
settled on letting the user hit tab and cycle through everything - which
is "predicatble", but hopelessly inefficient. Opera instead had a set of
user-configurable controls - tab moved through forms, q/a through links,
w/s through headings, etc. Last century, before JAWS provided header
navigation, any Opera user had it built in.

But "we" - the experts on web accessibility - told everyone that tabbing
was the way to navigate. So when people discovered that on Opera tab
wouldn't get to a link, they believed our story, and rejected the more
efficient methods to the point where Opera had to change - losing valuable
functionality.

In any event, given that browsers have fast, efficient, well-tested native
code for making buttons work, why should we tell millions of authors to
replicate that code in javascript? That is an inefficient, error-prone way
to work. If browsers recognised controls from their role, why can't they
just apply the same code they use when they recognise them from the
element name? In the button case, I can't think of a reason. Nor in the
case of a range control, or a date-picker. The only issue will arise if
the button is coded to do something the user *doesn't* expect, like
operate on pressing q or f.

This is going to get more interesting when we try to work out how to make
web components accessible.

It's one of the problems I am hoping to get people thinking about and
working on in the Web Incubator group, to see if we can improve HTML,
instead of just WCAG. Because a win for the people who don't use
screenreaders, that also works for the people who do, and that removes
work from authors, seems like a much bigger win...

cheers

> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
>> On Nov 19, 2015, at 2:36 PM, Sean Curtis < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> If the custom button receives focus wouldn't most screen readers tell
>> them how to activate it? Wouldn't this be enter or space? There are
>> conventions around this stuff surely? If WCAG can be passed by some
>> inaccessible UI then we need to rectify something...
>>
>> Cheers,
>>
>> Sean
>>
>>> On 20 Nov 2015, at 6:51 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
>>> wrote:
>>>
>>>> On 19/11/2015 18:17, Paul Adam wrote:
>>>> So WCAG is fine if let's say I make all my buttons operable with the
>>>> Escape key only. No enter or space bar must press escape to activate
>>>> the buttons. That would not fail keyboard operable? If not, WCAG
>>>> indeed has many loopholes.
>>>
>>> Bingo.
>>>
>>> P
>>> --
>>> Patrick H. Lauke
>>>
>>> www.splintered.co.uk | https://github.com/patrickhlauke
>>> http://flickr.com/photos/redux/ | http://redux.deviantart.com
>>> twitter: @patrick_h_lauke | skype: patrick_h_lauke
>>> >>> >>> >>> >> >> >> >> >
> > > > --
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Karl Groves
Date: Sat, Nov 21 2015 11:16AM
Subject: Re: Does WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On Sat, Nov 21, 2015 at 2:02 AM, Chaals McCathie Nevile
< = EMAIL ADDRESS REMOVED = > wrote:

> In any event, given that browsers have fast, efficient, well-tested native
> code for making buttons work, why should we tell millions of authors to
> replicate that code in javascript? That is an inefficient, error-prone way
> to work. If browsers recognised controls from their role, why can't they
> just apply the same code they use when they recognise them from the element
> name? In the button case, I can't think of a reason. Nor in the case of a
> range control, or a date-picker.

If I understand what you're implying, I think you're proposing
something quite compelling, but likely difficult to make happen. Right
now, browser vendors have a well-defined DOM specification to work
from and gobs of legacy code implementing that. Keeping in mind that
a large portion of native form controls had their DOM interfaces
defined back in DOM Level 2.

Browsers already do some of this type of trickery using the Shadown
DOM for new HTML5 input types, so it isn't impossible. It just
seems... hairy. It seems difficult to now say "ok all objects with a
specified 'role' property should now apply the same DOM methods and
properties as those items they're pretending to be".

Imagine:
<input type="checkbox" role="heading" aria-labelledby="foo">
<label id="foo">I'm really a heading, trust me!</label>

Absurd? Yes. But there's no limit to developer silliness!


> The only issue will arise if the button is
> coded to do something the user *doesn't* expect, like operate on pressing q
> or f.

Well that, like anything, comes down to the designers & developers
disavowing themselves of any misguided belief that doing so would be a
good idea. ;-)


--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

Modern Web Toolsets and Accessibility
https://www.youtube.com/watch?v=_uq6Db47-Ks

www.tenon.io

From: Chaals McCathie Nevile
Date: Sat, Nov 21 2015 11:49PM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On Sat, 21 Nov 2015 20:16:05 +0200, Karl Groves < = EMAIL ADDRESS REMOVED = >
wrote:

> On Sat, Nov 21, 2015 at 2:02 AM, Chaals McCathie Nevile
> < = EMAIL ADDRESS REMOVED = > wrote:
>
>> In any event, given that browsers have fast, efficient, well-tested
>> native code for making buttons work, why should we tell millions of
>> authors to replicate that code in javascript? That is an inefficient,
>> error-prone way to work. If browsers recognised controls from their
>> role, why can't they just apply the same code they use when they
>> recognise them from the element name? In the button case, I can't
>> think of a reason. Nor in the case of a range control, or a
>> date-picker.
>
> If I understand what you're implying, I think you're proposing
> something quite compelling, but likely difficult to make happen.

I suspect you do understand, and yes, I suspect that browser makers will
say it is impossible, very difficult, and possibly a very bad idea -
although more likely I expect "not clear what the benefit is".

> Right now, browser vendors have a well-defined DOM specification to work
> from and gobs of legacy code implementing that. Keeping in mind that
> a large portion of native form controls had their DOM interfaces
> defined back in DOM Level 2.

Yeah, but what's the hard bit in connecting to that code?

> Browsers already do some of this type of trickery using the Shadown
> DOM for new HTML5 input types, so it isn't impossible. It just
> seems... hairy. It seems difficult to now say "ok all objects with a
> specified 'role' property should now apply the same DOM methods and
> properties as those items they're pretending to be".
>
> Imagine:
> <input type="checkbox" role="heading" aria-labelledby="foo">
> <label id="foo">I'm really a heading, trust me!</label>
>
> Absurd? Yes. But there's no limit to developer silliness!

Well, yeah, but what is the expected outcome of this? And if browsers are
implementing that instead of just having something in the accessibility
API, doesn't that seriously help us reduce confusion and likely separate
paths?

>> The only issue will arise if the button is
>> coded to do something the user *doesn't* expect, like operate on
>> pressing q
>> or f.
>
> Well that, like anything, comes down to the designers & developers
> disavowing themselves of any misguided belief that doing so would be a
> good idea. ;-)

Sure.

On the other hand, of course, if someone makes a quirky browser that
really meets its users' needs, and for some reason the *expected*
behaviour of that browser is that the q key presses buttons, it would be
nice if that happened without developers somehow having to implement it in
Javascript…

Think of TV browsers (they aren't massively used for various reasons, but
there are a *lot* of them out there), or controlling with a gamepad, or
talking to your stereo (how else are they going to keep selling those
things?) about the news, weather, and how to book tickets to the latest
toddler-band concert and find some schoolkid to carry you there on his
bicycle-rickshaw (as part of the work experience he is paying some Silicon
Valley tax wheeze to be allowed to slave for)…

cheers


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Sailesh Panchang
Date: Sat, Nov 21 2015 4:52PM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

With reference to:
<input type="checkbox" role="heading" aria-labelledby="foo">
<label id="foo">I'm really a heading, trust me!</label>
Sailesh: Only users relying on AT/UA that are ARIA-aware, the
checkbox above may be expected to be exposed as a heading. Visually,
that element will still appear and behave like a checkbox, right?
Especially if someone chooses to use CSS properties that are not
author-supplied. The ARIA specs suggest that developers need to script
the elements to provide expected functionality, now if that
responsibility is shifted to UA makers, will it create chaos for
various stakeholders including different user groups?
Thanks,
Sailesh


On 11/22/15, Chaals McCathie Nevile < = EMAIL ADDRESS REMOVED = > wrote:
> On Sat, 21 Nov 2015 20:16:05 +0200, Karl Groves < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> On Sat, Nov 21, 2015 at 2:02 AM, Chaals McCathie Nevile
>> < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> In any event, given that browsers have fast, efficient, well-tested
>>> native code for making buttons work, why should we tell millions of
>>> authors to replicate that code in javascript? That is an inefficient,
>>> error-prone way to work. If browsers recognised controls from their
>>> role, why can't they just apply the same code they use when they
>>> recognise them from the element name? In the button case, I can't
>>> think of a reason. Nor in the case of a range control, or a
>>> date-picker.
>>
>> If I understand what you're implying, I think you're proposing
>> something quite compelling, but likely difficult to make happen.
>
> I suspect you do understand, and yes, I suspect that browser makers will
> say it is impossible, very difficult, and possibly a very bad idea -
> although more likely I expect "not clear what the benefit is".
>
>> Right now, browser vendors have a well-defined DOM specification to work
>> from and gobs of legacy code implementing that. Keeping in mind that
>> a large portion of native form controls had their DOM interfaces
>> defined back in DOM Level 2.
>
> Yeah, but what's the hard bit in connecting to that code?
>
>> Browsers already do some of this type of trickery using the Shadown
>> DOM for new HTML5 input types, so it isn't impossible. It just
>> seems... hairy. It seems difficult to now say "ok all objects with a
>> specified 'role' property should now apply the same DOM methods and
>> properties as those items they're pretending to be".
>>
>> Imagine:
>> <input type="checkbox" role="heading" aria-labelledby="foo">
>> <label id="foo">I'm really a heading, trust me!</label>
>>
>> Absurd? Yes. But there's no limit to developer silliness!
>
> Well, yeah, but what is the expected outcome of this? And if browsers are
> implementing that instead of just having something in the accessibility
> API, doesn't that seriously help us reduce confusion and likely separate
> paths?
>
>>> The only issue will arise if the button is
>>> coded to do something the user *doesn't* expect, like operate on
>>> pressing q
>>> or f.
>>
>> Well that, like anything, comes down to the designers & developers
>> disavowing themselves of any misguided belief that doing so would be a
>> good idea. ;-)
>
> Sure.
>
> On the other hand, of course, if someone makes a quirky browser that
> really meets its users' needs, and for some reason the *expected*
> behaviour of that browser is that the q key presses buttons, it would be
> nice if that happened without developers somehow having to implement it in
> Javascript…
>
> Think of TV browsers (they aren't massively used for various reasons, but
> there are a *lot* of them out there), or controlling with a gamepad, or
> talking to your stereo (how else are they going to keep selling those
> things?) about the news, weather, and how to book tickets to the latest
> toddler-band concert and find some schoolkid to carry you there on his
> bicycle-rickshaw (as part of the work experience he is paying some Silicon
> Valley tax wheeze to be allowed to slave for)…
>
> cheers
>
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> = EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com
> > > > >

From: Birkir R. Gunnarsson
Date: Sat, Nov 21 2015 5:28PM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Correct Sailesh

This piece of code would be exposed as a heading to A.T. users.
I am not sure what the label tag would do, you can´t associated a
label with a heading, but it can easily be tested.
I still think the way out of this potential mess is a more powerful
and widely supported html5. We need better accessibility support in
browsers for html elements such as dialogs, summary/detail and other
tags meant to replace custom tags.
Also developers need to start using the appropriate html tags.
Why should the browser go through the trouble of implementing all the
native behavior of an anchor mapped as a button using role="button"
when the developer could simply have used the button tag to begin
with.
Developers need to understand that if they wish to develop a custom
component rather than using what's already there, it comes at a cost,
and that cost is making sure it behaves as the native element.

I totally understand the frustrations, both as an accessibility
consultant and an end user.
I have seen whole sections of a page mapped as a tab (instead of
tabpanel), thus preventing me from interacting with any of its
focusable components.
I have seen the aria-labelledby attribute used with a string rather
than an ID reference, thus making the name of a form field impossible
to determine.
Even when implemented correctly there are so many minor variations in
the operation of complex widgets such as date pickers, tabs,
accordions etc. that I never know what I am going to get until I
experiment with it. And let's not get started on dialogs, especially
modal ones.

I am still hoping that a more powerful and better supported future
version of good old html is the answer rather than a more powerful
ARIA, a technology only meant for users with disabilities, as opposed
to technology aimed at all users.







On 11/21/15, Sailesh Panchang < = EMAIL ADDRESS REMOVED = > wrote:
> With reference to:
> <input type="checkbox" role="heading" aria-labelledby="foo">
> <label id="foo">I'm really a heading, trust me!</label>
> Sailesh: Only users relying on AT/UA that are ARIA-aware, the
> checkbox above may be expected to be exposed as a heading. Visually,
> that element will still appear and behave like a checkbox, right?
> Especially if someone chooses to use CSS properties that are not
> author-supplied. The ARIA specs suggest that developers need to script
> the elements to provide expected functionality, now if that
> responsibility is shifted to UA makers, will it create chaos for
> various stakeholders including different user groups?
> Thanks,
> Sailesh
>
>
> On 11/22/15, Chaals McCathie Nevile < = EMAIL ADDRESS REMOVED = > wrote:
>> On Sat, 21 Nov 2015 20:16:05 +0200, Karl Groves < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> On Sat, Nov 21, 2015 at 2:02 AM, Chaals McCathie Nevile
>>> < = EMAIL ADDRESS REMOVED = > wrote:
>>>
>>>> In any event, given that browsers have fast, efficient, well-tested
>>>> native code for making buttons work, why should we tell millions of
>>>> authors to replicate that code in javascript? That is an inefficient,
>>>> error-prone way to work. If browsers recognised controls from their
>>>> role, why can't they just apply the same code they use when they
>>>> recognise them from the element name? In the button case, I can't
>>>> think of a reason. Nor in the case of a range control, or a
>>>> date-picker.
>>>
>>> If I understand what you're implying, I think you're proposing
>>> something quite compelling, but likely difficult to make happen.
>>
>> I suspect you do understand, and yes, I suspect that browser makers will
>> say it is impossible, very difficult, and possibly a very bad idea -
>> although more likely I expect "not clear what the benefit is".
>>
>>> Right now, browser vendors have a well-defined DOM specification to work
>>> from and gobs of legacy code implementing that. Keeping in mind that
>>> a large portion of native form controls had their DOM interfaces
>>> defined back in DOM Level 2.
>>
>> Yeah, but what's the hard bit in connecting to that code?
>>
>>> Browsers already do some of this type of trickery using the Shadown
>>> DOM for new HTML5 input types, so it isn't impossible. It just
>>> seems... hairy. It seems difficult to now say "ok all objects with a
>>> specified 'role' property should now apply the same DOM methods and
>>> properties as those items they're pretending to be".
>>>
>>> Imagine:
>>> <input type="checkbox" role="heading" aria-labelledby="foo">
>>> <label id="foo">I'm really a heading, trust me!</label>
>>>
>>> Absurd? Yes. But there's no limit to developer silliness!
>>
>> Well, yeah, but what is the expected outcome of this? And if browsers are
>> implementing that instead of just having something in the accessibility
>> API, doesn't that seriously help us reduce confusion and likely separate
>> paths?
>>
>>>> The only issue will arise if the button is
>>>> coded to do something the user *doesn't* expect, like operate on
>>>> pressing q
>>>> or f.
>>>
>>> Well that, like anything, comes down to the designers & developers
>>> disavowing themselves of any misguided belief that doing so would be a
>>> good idea. ;-)
>>
>> Sure.
>>
>> On the other hand, of course, if someone makes a quirky browser that
>> really meets its users' needs, and for some reason the *expected*
>> behaviour of that browser is that the q key presses buttons, it would be
>> nice if that happened without developers somehow having to implement it in
>> Javascript…
>>
>> Think of TV browsers (they aren't massively used for various reasons, but
>> there are a *lot* of them out there), or controlling with a gamepad, or
>> talking to your stereo (how else are they going to keep selling those
>> things?) about the news, weather, and how to book tickets to the latest
>> toddler-band concert and find some schoolkid to carry you there on his
>> bicycle-rickshaw (as part of the work experience he is paying some Silicon
>> Valley tax wheeze to be allowed to slave for)…
>>
>> cheers
>>
>>
>> --
>> Charles McCathie Nevile - web standards - CTO Office, Yandex
>> = EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Steve Faulkner
Date: Sun, Nov 22 2015 2:23AM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On 21 November 2015 at 23:52, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
wrote:

> <input type="checkbox" role="heading">
>

FYI
This markup pattern is forbidden in HTML
http://w3c.github.io/html-aria/#input-checkbox
--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

From: Sailesh Panchang
Date: Mon, Nov 23 2015 7:44AM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Steve,
FYI: Maybe you did not read through the thread.
That piece of markup was not mine to begin with ... it was in the
email I responded to. That email also suggested shifting some
responsibility to the browser from the developer and my email used
that example markup from the previous exchange to highlight the
pitfall of shifting that responsibility.
Best regards,
Sailesh Panchang

On 11/22/15, Steve Faulkner < = EMAIL ADDRESS REMOVED = > wrote:
> On 21 November 2015 at 23:52, Sailesh Panchang < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> <input type="checkbox" role="heading">
>>
>
> FYI
> This markup pattern is forbidden in HTML
> http://w3c.github.io/html-aria/#input-checkbox
> --
>
> Regards
>
> SteveF
> Current Standards Work @W3C
> <http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;
> > > > >

From: Maraikayar Prem Nawaz
Date: Tue, Nov 24 2015 6:44PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

+1.
WCAG docs are hard to understand and interpret. Especially for many of us
for whom English is not the primary language.

On Sat, Nov 21, 2015 at 11:52 AM, Chaals McCathie Nevile <
= EMAIL ADDRESS REMOVED = > wrote:

> TL;DR: You need to make concrete proposals for changes to text, because
> WAI cannot just hire a writer to fix stuff for you. So file bugs against
> WCAG.
>
> On Thu, 19 Nov 2015 20:12:07 +0100, Chagnon | PubCom.com <
> = EMAIL ADDRESS REMOVED = > wrote:
>
> Paul Adam wrote:
>> "WCAG indeed has many loopholes."
>>
>> In a way, yes, you're right about that.
>>
> [WCAG is badly written, which causes problems, and WAI should hire
> professional writers who understand clear communication, regulation, and
> standards]
>
> I agree that plain language is important, and a standard should be as
> clear as possible.
>
> But asking WAI to hire professional writers is like asking WebAIM to fix
> the web's accessibility. There isn't a clear way for it to happen.
>
> WAI is part of W3C, which brings a certain amount of funding. A lot of the
> 7 WAI staff are employed on, and paid for by, research contracts with the
> European Union or US government in some form or other.
>
> W3C specifications are made by practitioners, who volunteer their time to
> W3C. Many of them are organisations - TPG, Deque, Yandex, Microsoft,
> Pearson, SSB, RNIB, and others you may know which also join W3C, meaning
> they pay membership fees which provide the funding I mentioned earlier.
>
> The process to make W3C specifications is roughly as follows:
> - Identify something people agrees needs to be clearly specified as a
> standard for the Web
> - Organise a Working Group to develop a W3C Recommendation.
> - That group proposes a series of drafts, which are public and meant to
> get very broad public feedback. Most groups, including all WAI groups, now
> do all their work in public.
> - The group (remember, basically volunteers) respond to feedback, to
> improve the documents.
> - Convince Tim Berners-Lee that they have done the best job they could
> with the resources they had.
>
> If you want better documents, it is important to file comments explaining
> the problem, as well as outlining solutions.
>
> Every "W3C Recommendation" has a section called "Status of This Document"
> right near the front, that says how to file comments on it. Please do so.
>
> Note that for some time WAI has resisted making substantive changes to
> WCAG 2.0
>
> One way to change that would be to start filing bugs if WCAG 2.0 is
> ambiguous, or its requirements do not achieve the goals, or the writing is
> unclear.
>
> cheers
>
> Chaals
>
> --
> Charles McCathie Nevile - web standards - CTO Office, Yandex
> = EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com
> > > > >

From: Bourne, Sarah (ITD)
Date: Wed, Nov 25 2015 7:03AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

On Sat, Nov 21, 2015 at 11:52 AM, Chaals McCathie Nevile < = EMAIL ADDRESS REMOVED = > wrote:

> TL;DR: You need to make concrete proposals for changes to text,
> because WAI cannot just hire a writer to fix stuff for you. So file
> bugs against WCAG.

Maybe it's because there are so many horrible things happening in the world right now, but that statement fills me with despair. I can't even imagine filing bug reports to change the writing style of such a large set of huge documents. You really want a (talented) editor to oversee the process and make stylistic decisions that would be applied uniformly across the body of text.

And I'm not sure such an approach would end up making an appreciable difference. There are some things that may not be able to change, too. For instance, "normative" and "nonnormative" have very specific meanings in spec-speak and cause non-fluent speakers of that dialect to run away screaming.

It might be easier and more feasible to consider a plain language user guide for authors and developers, which would be nonnormative (I presume) but more approachable. WebAIM does quite a bit of this for us, and there are other resources as well, but none have the imprimatur of the W3C.

> because WAI cannot just hire a writer to fix stuff for you.
Do we need a Kickstarter campaign? [cynical yet impish grin]

sb
Sarah E. Bourne
Director of IT Accessibility, MassIT
Commonwealth of Massachusetts
1 Ashburton Pl. rm 1601 Boston MA 02108
617-626-4502
= EMAIL ADDRESS REMOVED =
http://www.mass.gov/MassIT

From: Patrick H. Lauke
Date: Wed, Nov 25 2015 8:11AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

On 25/11/2015 14:03, Bourne, Sarah (ITD) wrote:

> It might be easier and more feasible to consider a plain language
> user guide for authors and developers, which would be nonnormative (I
> presume) but more approachable. WebAIM does quite a bit of this for
> us, and there are other resources as well, but none have the
> imprimatur of the W3C.

I think "Understanding WCAG 2.0" is supposed to be the (non-normative)
plain language guide? Maybe this is the more appropriate doc to tackle?

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Chagnon | PubCom.com
Date: Wed, Nov 25 2015 12:09PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

> But asking WAI to hire professional writers is like asking WebAIM to
> fix the web's accessibility. There isn't a clear way for it to happen.

No, not the same situation.
WebAIM doesn't write the standards.

Speaking as someone with several decades experience working with US Federal government agencies to edit and publish regulations and standards, the burden of clearly communicating the standards to the audience is on the entity that writes and controls the standards. For WCAG, that's W3C/WAI.

In the US, federal law requires all federal agencies to do this under the Plain Writing Act of 2010 (and previous iterations and policies over the past 30 years). http://www.plainlanguage.gov/plLaw/ A subsequent Executive Order specifically requires that all regulations be written in plain language and are easy to understand. Similar plain-language laws are in place in other countries.

When the US Access Board releases the 508 Refresh, WCAG and PDF/UA will become part of the US Federal regulations "by reference." And when that happens, the Sec. 508 Refresh will be violating the government's plain language law already in place.

This is a major problem that will affect everyone in the accessibility community; 3 separate pieces of federal legislation/regulations/orders that conflict with each other. When this has happened in the past, all legislation/regulations/orders were put "on hold" until the problems can be worked out or one or more of the pieces is knocked down, possibly determined by the Supreme Court.

W3C/WAI write and control WCAG. The PDF/UA organization works with the ISO on PDF/UA standards.

Therefore, they -- and only these organizations -- are responsible for providing their standards and guidelines (which act as pseudo-regulations) in clearly written language that anyone can understand.

W3C/WAI must hire the professional writers and editors to do this. It's their baby, not anyone else's...therefore it is their responsibility. They must act like a professional standards committee and do their job...don't ask volunteers to do this job. W3c has enough information to require 3-4 full-time editors.

Otherwise, we'll have 2 possible outcomes:
1) Lots of rebuttal lawsuits and complaints about WCAG and PDF/UA not being understandable. WCAG especially provides a very good loophole for "undue burden" because it's so poorly written and incomprehensible.
2) Eventual erosion of our US Sec. 508 law (and others worldwide) that could throw everything out the window. We could end up without any laws requiring accessibility anywhere...putting us back to 1995 again.

PDF/UA is fairly well-written and understandable.
WCAG is not. Pure computer-techno-babble gobblygook.

W3C/WAI, if you truly are dedicated to accessibility, fix the problem. It's your responsibility.
Hire full-time, real, professional writers, editors, and communicators.

Relying on volunteers, committees, and programmers to do this is not helping achieve our ultimate goal: worldwide accessibility of information.

--Bevi Chagnon

From: Duff Johnson
Date: Wed, Nov 25 2015 2:04PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

Hi Bevi,

Something I want to clarify….

> PDF/UA is fairly well-written and understandable.
> WCAG is not. Pure computer-techno-babble gobblygook.

I fear that anyone non-technical would also regard PDF/UA as "pure computer-techno babble gobblygook" - and not unjustly.

The difference, in this context, is that PDF/UA is not intended to be read by end-users, authors, etc. The document is exclusively aimed at software-developers. Users are expected to encounter PDF/UA by virtue of its requirements expressed in conforming application software. I do not expect (and would not reccomend) that authors and other end users buy the specification with the hopes of either (a) great writing or (b) useful insights into making accessible PDF documents.

Duff.

From: Alastair Campbell
Date: Thu, Nov 26 2015 2:42PM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

Chaals McCathie Nevile wrote:

> I suspect that browser makers will say it is impossible, very difficult,
> and possibly a very bad idea - although more likely I expect "not clear
> what the benefit is".
>

One point of benefit: People often assume that roles bring the behaviours
with them.

I came back to accessibility things after my focus being elsewhere for a
while, and almost immediately made that mistake!

Doing training with and trouble-shooting for developers, I think it's a
common error. It would be interesting to do a poll where we ask something
like:
Does pressing enter on the keyboard activate this?
<span role="button">Submit</span>

I think a lot of (normal) developers would answer yes.

-Alastair

From: Chaals McCathie Nevile
Date: Thu, Nov 26 2015 8:12PM
Subject: Re: Roles defining elements in generalDoes WCAG require that when you click a label it checks the checkbox or radio button?
← Previous message | Next message →

On Fri, 27 Nov 2015 08:42:59 +1100, Alastair Campbell < = EMAIL ADDRESS REMOVED = >
wrote:

> Chaals McCathie Nevile wrote:
>
>> I suspect that browser makers will say it is impossible, very difficult,
>> and possibly a very bad idea - although more likely I expect "not clear
>> what the benefit is".
>>
>
> One point of benefit: People often assume that roles bring the behaviours
> with them.
>
> I came back to accessibility things after my focus being elsewhere for a
> while, and almost immediately made that mistake!
>
> Doing training with and trouble-shooting for developers, I think it's a
> common error. It would be interesting to do a poll where we ask
> something
> like:
> Does pressing enter on the keyboard activate this?
> <span role="button">Submit</span>
>
> I think a lot of (normal) developers would answer yes.

Yeah, personally I think that is true, and that a lot of developers saying
that would be right. They would have a lot of time they currently spend
checking whether they copy-pasted code correctly in making new and more
interesting things…

Another benefit is that performance improves, since there are no
js-parsing blips.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Chagnon | PubCom.com
Date: Thu, Nov 26 2015 9:33PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

Peter wrote:
"I think "Understanding WCAG 2.0" is supposed to be the (non-normative) plain language guide? Maybe this is the more appropriate doc to tackle?"

Ha!
That's the exact document that my editor client was claiming she couldn't understand.
It needs help!

—Bevi Chagnon

From: Chaals McCathie Nevile
Date: Sun, Nov 29 2015 7:07PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

TL;DR: This isn't how things work. WAI is global, multi-stakeholder, and
intrinsically volunteer driven. That doesn't stop people improving things.

On Thu, 26 Nov 2015 05:09:52 +1000, Chagnon | PubCom.com
< = EMAIL ADDRESS REMOVED = > wrote:

>> But asking WAI to hire professional writers is like asking WebAIM to
>> fix the web's accessibility. There isn't a clear way for it to happen.
>
> No, not the same situation.
> WebAIM doesn't write the standards.

In practical terms, when someone comes here with a question like "does
this situation meet WCAG" and gets a broad consensus for an answer, webaim
is writing a part of the standard for the people who implement it and
follow webaim.

> Speaking as someone with several decades experience working with US
> Federal government agencies to edit and publish regulations and
> standards, the burden of clearly communicating the standards to the
> audience is on the entity that writes and controls the standards.

That isn't quite how things work. The burden of creating and communicating
standards *is* carried by the collective participants in the ecosystem
where the standard is used.

There is a sound argument that a major part of that burden should in
principle be carried by those who write the documents themselves, but that
doesn't make anything happen in the real world.

There is also a sound argument that *any* moderately complicated standard
needs to be reviewed by the people in the ecosystem to determine how it
relates to particular practical situations that were not envisaged, or are
unclear.

> For WCAG, that's W3C/WAI.
>
> In the US, federal law requires ... plain-language ...
>
> When the US Access Board releases the 508 Refresh, WCAG and PDF/UA will
> become part of the US Federal regulations "by reference." And when that
> happens, the Sec. 508 Refresh will be violating the government's plain
> language law already in place.
>
> This is a major problem that will affect everyone in the accessibility
> community; 3 separate pieces of federal legislation/regulations/orders
> that conflict with each other.

Actually, this scenario is only directly relevant to the US, so (very
roughly) about 1/20th of the world.

Which is not to say that it doesn't matter. There is a lot of value in
having a global community of practice, and common standards across the
world - not least so organisation based in one country can readily
transfer skills and do business in others.

> When this has happened in the past, all legislation/regulations/orders
> were put "on hold" until the problems can be worked out or one or more
> of the pieces is knocked down, possibly determined by the Supreme Court.
>
> W3C/WAI write and control WCAG. The PDF/UA organization works with the
> ISO on PDF/UA standards.
>
> Therefore, they -- and only these organizations -- are responsible for
> providing their standards and guidelines (which act as
> pseudo-regulations) in clearly written language that anyone can
> understand.

That is not the case.

If a customer wants something, finding someone who can provide it is their
problem. They may be able to enforce a contract if they had one, but there
is no general right to have things the way you want just because you say
they should be that way.

In this situation, the US government is one (of many) customers for WCAG.
The very sound basis for using it is the global, multi-stakeholder
approach to producing it as a technical standard. This has produced both a
particular level of technical quality, and the important feature that it
is in line with standards used around the world. It isn't perfect, just
better than the available alternatives.

As a counter-example, when WCAG 1 was fairly new the US government
produced the original section 508's specification of requirements for Web
accessibility. That was rejected as a basis for regulation by more or less
the entire rest of the english-speaking world.

Don't forget, most countries that use WCAG - such as 27 of the 29 European
Union countries - don't have regulations written in english in the first
place.

> W3C/WAI must hire the professional writers and editors to do this. It's
> their baby, not anyone else's...therefore it is their responsibility.

It is the responsibility of those who want to use WCAG to ensure it is as
good as it can be. If this were about buying cars for the family, the way
to achieve that would probably be to pay more - but that isn't how
standards work.

> They must act like a professional standards committee and do their
> job...don't ask volunteers to do this job.

But that is how most professional standards committees *do* work.

> W3C has enough information to require 3-4 full-time editors.

1. That's about an order of magnitude underestimated.
2. It still needs the couple of thousand technical experts who contribute
knowledge to its standards, and whom it doesn't, and can't, hire, instead
relying on them or their employers wanting to ensure the standards W3C
produces meet the needs of the ecosystems that use them.

> Otherwise, we'll have 2 possible outcomes:
> 1) Lots of rebuttal lawsuits and complaints about WCAG and PDF/UA not
> being understandable.

You will have that in any circumstance.

> WCAG especially provides a very good loophole for "undue burden" because
> it's so poorly written and incomprehensible.

If this were the case, lawyers really could have $150 every time someone
said "it's too hard to read, so I don't think I need to do it".

> 2) Eventual erosion of our US Sec. 508 law (and others worldwide) that
> could throw everything out the window. We could end up without any laws
> requiring accessibility anywhere...putting us back to 1995 again.

That would be a minor problem in the US, although in practice the ADA and
other US law doesn't need section 508. Many other countries get along fine
with well-written law. So I suggest there are more posible outcomes:

3) Organisations that have large budgets (by which I mean something like
$10 million per year, which dwarfs WAI's budget) will contribute more
resources specifically targeted to improving the writing quality of WCAG.

4) WAI will update WCAG, and many of the same volunteers responsible for
WCAG 1 and 2 will have learned from the experience and provide something
better

5) The US will follow other english-speaking common-law countries, whose
regulation depends on demonstrating a barrier to some person, rather than
solely requiring conformance to some specific statement. This will create
a demand for clear understanding of how to remove barriers - and therefore
a demand to improve the specifications like WCAG that provide that
information.

> PDF/UA is fairly well-written and understandable.
> WCAG is not. Pure computer-techno-babble gobblygook.
>
> W3C/WAI, if you truly are dedicated to accessibility, fix the problem.
> It's your responsibility.

W3C/WAI is primarily "us" - or at least those of us who put our time and
money into making it happen. So if we are dedicated to having W3C
standards for accessibility, it follows that we should continue to put in
time and money to improve WCAG, and the various other bits of useful work
WAI does, to the best of our ability.

> Hire full-time, real, professional writers, editors, and communicators.

This request would have to be carried out with imaginary money.
Unfortunately, that is unlikely to have any useful real outcome.

An alternative interpretation is that you think the small WAI staff should
all be replaced with people who can do the job better. Let's assume that
is true - since there is always *someone* better somewhere out there. How
do you propose, in practice, that might happen? Sacking someone, and
hiring someone, are both processes that have a real cost, and *also*
require work. And you can't require that some particular person accept a
job any more than you can require that someone makes products to the
specifications you want - you have to find and agree with a real person to
achieve this.

> Relying on volunteers, committees, and programmers to do this is not
> helping achieve our ultimate goal: worldwide accessibility of
> information.

I don't think that conclusion is supported by the evidence. Relying on
volunteers, committees and programmers has got us surprisingly far in the
18 years WAI has existed - and continues to produce progress.

I spend a lot of time working within W3C, pointing out things I think they
are doing badly, and helping to focus the resources available in more
productive and useful ways. That includes improving the clarity of
writing. But "the resources available" largely means me, and others that
my company pays for, and many many others paid by their employer who
volunteers their time, as well as many individuals who simply volunteer
their own time and expertise.

Perhaps a better approach would be to look at how to enable those
volunteers to contribute more easily, and how to find more of them to do
so.

cheers

--
Charles McCathie Nevile - web standards - CTO Office, Yandex
= EMAIL ADDRESS REMOVED = - - - Find more at http://yandex.com

From: Chagnon | PubCom.com
Date: Mon, Nov 30 2015 3:31PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

Dear Chaals (or Charles),

I can't find much to agree on in your last post.
Your view of accessibility from the Moscow corporate world must be different from mine in the Federal government in Washington DC.

My firm consults with lawyers about accessibility issues...such as what's enforceable, where the standards can be enforced, etc. It's worrisome whether WCAG is able to protect the rights of disabled people here in the United States, namely because of the reasons I've already stated: lack of clarity in the standards, too many loopholes, and too much confusion about what needs to be done to meet compliance for different types of media.

Therefore, some lawyers conclude that WCAG is not enforceable in the US in its present state. That means there is a lesser chance of disabled people winning court cases or complaints against the US Federal government (and other state governments).

However, a court case against a corporate entity is different; public opinion about what's accessible comes into play there.

Plus, given your statement that WCAG is written by hundreds of worldwide volunteers, that further weakens WAI/WCAG's clout.

Although the work and expertise that the volunteers contribute is central, they are ONLY volunteers and not legal members (or "owners") of the organization itself. At some point a "real" organization must take ownership of the standards, cull through the contributions from volunteers, decide what's going to be in the standards, and publish the standards to the public.

In other words, it's the W3C/WAI that owns and is responsible for the standards...NOT the volunteers themselves.

No United States court of law will decide a case based on the opinion of volunteers from various parts of the world, no matter how well intentioned the volunteers are.

But a court can decide a case based on standards from a professional, bonafide standards organization...if the standards are presented accurately and fully (and of course, formally adopted by the government which hopefully will happen soon in the US).

That's where W3C/WAI is failing; it's not acting like a standards organization because it's not doing the entire job that's needed.

And if W3C/WAI don't have the money to hire professional editors, then they should consider holding a bake sale and getting Adobe, Apple, IBM, Microsoft, et. al to pony up a couple hundred thousand dollars for the cause...and some excellent brownies. These companies have billions stashed overseas to avoid taxes and this is one thing they could do for the public good...and probably take a tax deduction, to boot. They all donate millions to other nonprofit causes, why not to an accessibility nonprofit earmarked for editors?

I'm done on this thread and won't reply to any further posts on it. We seem to be running in circles at this point. Rather than being a discussion forum for ideas and opinions, it has turned into something much less productive and informative.

--Bevi Chagnon

From: Steve Faulkner
Date: Mon, Nov 30 2015 11:59PM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

Some data points:
>
> DOJ uses WCAG 2.0 in its settlements. See http://1.usa.gov/1j49Y0E
> <https://t.co/t2gENncnVt> start Section 41. DOT uses WCAG http://
> 1.usa.gov/1lqMQuI <https://t.co/3HLzSO8J3c>

https://twitter.com/LFLegal/status/671468373771972608

private parties use WCAG 2.0 AA to settle ADA cases. See Scribd http://
> bit.ly/1I1DK1Z <https://t.co/47CHb487Mh> My cases: http://bit.ly/1bKXa3U
> <https://t.co/Gan0lSdfmb>

https://twitter.com/LFLegal/status/671469010488320001

DOJ lawsuit for EdX - it has WCAG right in it
see section 18:
http://www.justice.gov/sites/default/files/opa/press-releases/attachments/2015/04/02/edx_settlement_agreement.pdf

W3C Web Content Accessibility Guidelines 2.0 Approved as ISO/IEC
International Standard
http://www.w3.org/2012/07/wcag2pas-pr.html


--

Regards

SteveF
Current Standards Work @W3C
<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>;

On 30 November 2015 at 22:31, Chagnon | PubCom.com < = EMAIL ADDRESS REMOVED = >
wrote:

> Dear Chaals (or Charles),
>
> I can't find much to agree on in your last post.
> Your view of accessibility from the Moscow corporate world must be
> different from mine in the Federal government in Washington DC.
>
> My firm consults with lawyers about accessibility issues...such as what's
> enforceable, where the standards can be enforced, etc. It's worrisome
> whether WCAG is able to protect the rights of disabled people here in the
> United States, namely because of the reasons I've already stated: lack of
> clarity in the standards, too many loopholes, and too much confusion about
> what needs to be done to meet compliance for different types of media.
>
> Therefore, some lawyers conclude that WCAG is not enforceable in the US in
> its present state. That means there is a lesser chance of disabled people
> winning court cases or complaints against the US Federal government (and
> other state governments).
>
> However, a court case against a corporate entity is different; public
> opinion about what's accessible comes into play there.
>
> Plus, given your statement that WCAG is written by hundreds of worldwide
> volunteers, that further weakens WAI/WCAG's clout.
>
> Although the work and expertise that the volunteers contribute is central,
> they are ONLY volunteers and not legal members (or "owners") of the
> organization itself. At some point a "real" organization must take
> ownership of the standards, cull through the contributions from volunteers,
> decide what's going to be in the standards, and publish the standards to
> the public.
>
> In other words, it's the W3C/WAI that owns and is responsible for the
> standards...NOT the volunteers themselves.
>
> No United States court of law will decide a case based on the opinion of
> volunteers from various parts of the world, no matter how well intentioned
> the volunteers are.
>
> But a court can decide a case based on standards from a professional,
> bonafide standards organization...if the standards are presented accurately
> and fully (and of course, formally adopted by the government which
> hopefully will happen soon in the US).
>
> That's where W3C/WAI is failing; it's not acting like a standards
> organization because it's not doing the entire job that's needed.
>
> And if W3C/WAI don't have the money to hire professional editors, then
> they should consider holding a bake sale and getting Adobe, Apple, IBM,
> Microsoft, et. al to pony up a couple hundred thousand dollars for the
> cause...and some excellent brownies. These companies have billions stashed
> overseas to avoid taxes and this is one thing they could do for the public
> good...and probably take a tax deduction, to boot. They all donate millions
> to other nonprofit causes, why not to an accessibility nonprofit earmarked
> for editors?
>
> I'm done on this thread and won't reply to any further posts on it. We
> seem to be running in circles at this point. Rather than being a discussion
> forum for ideas and opinions, it has turned into something much less
> productive and informative.
>
> --Bevi Chagnon
>
>
> > > > >

From: Léonie Watson
Date: Tue, Dec 01 2015 2:07AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

> From: WebAIM-Forum On Behalf Of Chagnon | PubCom.com
> Sent: 30 November 2015 22:32
> I can't find much to agree on in your last post.
> Your view of accessibility from the Moscow corporate world must be
> different from mine in the Federal government in Washington DC.
>
> My firm consults with lawyers about accessibility issues...such as what's
> enforceable, where the standards can be enforced, etc. It's worrisome
> whether WCAG is able to protect the rights of disabled people here in the
> United States, namely because of the reasons I've already stated: lack of
> clarity in the standards, too many loopholes, and too much confusion about
> what needs to be done to meet compliance for different types of media.

What is really worrisome is that lawyers are dictating accessibility in the first place. In the UK our disability legislation does not mention WCAG (or any other specific set of guidelines). We use WCAG as the guidelines they are intended to be, and our benchmark is whether someone can actually use a service or not.

The lawyers that gave the go-ahead for WCAG to be adopted into law in different countries presumably felt they were fit for purpose. If that isn't the case, then perhaps a better question is why they did?

Léonie.

--
Senior accessibility engineer @LeonieWatson @PacielloGroup

From: Karl Groves
Date: Tue, Dec 01 2015 5:33AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

On Mon, Nov 30, 2015 at 5:31 PM, Chagnon | PubCom.com
< = EMAIL ADDRESS REMOVED = > wrote:
> Dear Chaals (or Charles),
>
> I can't find much to agree on in your last post.
> Your view of accessibility from the Moscow corporate world must be different from mine in the Federal government in Washington DC.
>

I don't know what value statements like that add to the conversation.
It seems like an ad hominem attack and if anything it betrays a high
degree of ignorance. The subject of this conversation is WCAG,
authored by a working group within the Web Accessibility Initiative of
the Worldwide Web Consortium. "Worldwide" !== DC or Moscow or
anywhere else. WCAG's goal is accessibility for all people regardless
of geographical location (BTW, Chaals is in Madrid anyway)

WCAG was found to be sufficiently clear to be adopted as an ISO standard

> My firm consults with lawyers about accessibility issues...such as what's enforceable, where the standards can be enforced, etc.

Apologies for what's undoubtedly going to sound quite harsh, but given
your self-proclaimed difficulty in reading WCAG, I hope you consult
for defendants and not plaintiffs.

> It's worrisome whether WCAG is able to protect the rights of disabled people here in the United States, namely because of the reasons I've already stated: lack of clarity in the standards, too many loopholes, and too much confusion about what needs to be done to meet compliance for different types of media.

As Chaals stated, you should file bugs against the materials. While
the spec itself is not going to be changed anytime soon (sad, IMO) you
can still contribute to the numerous additional materials.

WCAG does (most of) its work out in the open. You merely need to take
the time to identify specific shortcomings and log them as issues in
their Github repository at https://github.com/w3c/wcag/issues


>
> Therefore, some lawyers conclude that WCAG is not enforceable in the US in its present state. That means there is a lesser chance of disabled people winning court cases or complaints against the US Federal government (and other state governments).
>

Well WCAG isn't a law, so...

Steve Faulkner already mentioned some, but here's a long (and
incomplete) list of lawsuits and settlements, the overwhelming
majority of which call for compliance with WCAG 2.0 Level AA as the
settlement criteria:
http://www.karlgroves.com/2011/11/15/list-of-web-accessibility-related-litigation-and-settlements/


> However, a court case against a corporate entity is different; public opinion about what's accessible comes into play there.
>
> Plus, given your statement that WCAG is written by hundreds of worldwide volunteers, that further weakens WAI/WCAG's clout.


I'm sorry but this also betrays a very high degree of ignorance of how
*any* standards are written and how the W3C works and who's been
involved in WCAG. The WCAG Working Group isn't exactly the PTA.
Here's the list of Acknowledgements for WCAG 2.0:
http://www.w3.org/TR/WCAG20/#acknowledgments

While there may be some people in that list that I have more respect
for than others, this is a pretty impressive list of experts.


> In other words, it's the W3C/WAI that owns and is responsible for the standards...NOT the volunteers themselves.

I haven't seen anyone suggest otherwise and I'm confused about where
that would even come from.

>
> No United States court of law will decide a case based on the opinion of volunteers from various parts of the world, no matter how well intentioned the volunteers are.

You're obviously confused about *who* these volunteers are. Your
continued use of the word "volunteers" is either the result of
ignorance or is meant as an underhanded dig at the people who created
the standard.

I don't know everyone who has come & gone in the WCAG Working Group
but of the names I do recognize, most have had very long careers in
accessibility.

>
> But a court can decide a case based on standards from a professional, bonafide standards organization...if the standards are presented accurately and fully (and of course, formally adopted by the government which hopefully will happen soon in the US).

Wait, the W3C isn't a bonafide standards organization?


>
> That's where W3C/WAI is failing; it's not acting like a standards organization because it's not doing the entire job that's needed.
>

Clearly they need your help. I'm connected with Jeff Jaffe on
LinkedIn. Do you want an intro?


> And if W3C/WAI don't have the money to hire professional editors, then they should consider holding a bake sale

Again with the PTA stuff. Seriously unproductive.


I've stayed out of the thread mostly because I agree that even the
informative documentation associated with WCAG can be unclear,
contradictory, and difficult for laypersons to understand.
But some of the things said in the email to which I'm replying are
just too inappropriate and incorrect to let slide.

As Chaals said: "Every "W3C Recommendation" has a section called
"Status of This Document" right near the front, that says how to file
comments on it. Please do so."




--

Karl Groves
www.karlgroves.com
@karlgroves
http://www.linkedin.com/in/karlgroves
Phone: +1 410.541.6829

Modern Web Toolsets and Accessibility
https://www.youtube.com/watch?v=_uq6Db47-Ks

www.tenon.io

From: Ryan E. Benson
Date: Tue, Dec 01 2015 7:12AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

> I've stayed out of the thread mostly because I agree that even the
informative documentation associated with WCAG can be unclear,
contradictory, and difficult for laypersons to understand.

I think this is the crux of the argument, or the part I can agree with, at
least. While we have identified that WebAIM is not the standard-setter, but
we cannot deny the fact it is one of the popular ways to get assistance
with WCAG.

If we jump into the WebAIM archives we'd find a thread asking which SC is
best suited. A good portion of the time it is cut and dry, but there are a
few that are like "well you can think of it this way, that way, or this
other way." I remember a few were the thread got to two dozen replies, and
the person who originally asked was like "....so guys what SC should they
be dinged with?"

Where I work, luckily (maybe not so lucky) I am one of the people who can
authoritatively use this SC. The thing that keeps me awake at night is when
people will want to push it, or won't accept less than a 3 page reply why x
was chosen over y.

--
Ryan E. Benson

On Tue, Dec 1, 2015 at 7:33 AM, Karl Groves < = EMAIL ADDRESS REMOVED = > wrote:

> On Mon, Nov 30, 2015 at 5:31 PM, Chagnon | PubCom.com
> < = EMAIL ADDRESS REMOVED = > wrote:
> > Dear Chaals (or Charles),
> >
> > I can't find much to agree on in your last post.
> > Your view of accessibility from the Moscow corporate world must be
> different from mine in the Federal government in Washington DC.
> >
>
> I don't know what value statements like that add to the conversation.
> It seems like an ad hominem attack and if anything it betrays a high
> degree of ignorance. The subject of this conversation is WCAG,
> authored by a working group within the Web Accessibility Initiative of
> the Worldwide Web Consortium. "Worldwide" !== DC or Moscow or
> anywhere else. WCAG's goal is accessibility for all people regardless
> of geographical location (BTW, Chaals is in Madrid anyway)
>
> WCAG was found to be sufficiently clear to be adopted as an ISO standard
>
> > My firm consults with lawyers about accessibility issues...such as
> what's enforceable, where the standards can be enforced, etc.
>
> Apologies for what's undoubtedly going to sound quite harsh, but given
> your self-proclaimed difficulty in reading WCAG, I hope you consult
> for defendants and not plaintiffs.
>
> > It's worrisome whether WCAG is able to protect the rights of disabled
> people here in the United States, namely because of the reasons I've
> already stated: lack of clarity in the standards, too many loopholes, and
> too much confusion about what needs to be done to meet compliance for
> different types of media.
>
> As Chaals stated, you should file bugs against the materials. While
> the spec itself is not going to be changed anytime soon (sad, IMO) you
> can still contribute to the numerous additional materials.
>
> WCAG does (most of) its work out in the open. You merely need to take
> the time to identify specific shortcomings and log them as issues in
> their Github repository at https://github.com/w3c/wcag/issues
>
>
> >
> > Therefore, some lawyers conclude that WCAG is not enforceable in the US
> in its present state. That means there is a lesser chance of disabled
> people winning court cases or complaints against the US Federal government
> (and other state governments).
> >
>
> Well WCAG isn't a law, so...
>
> Steve Faulkner already mentioned some, but here's a long (and
> incomplete) list of lawsuits and settlements, the overwhelming
> majority of which call for compliance with WCAG 2.0 Level AA as the
> settlement criteria:
>
> http://www.karlgroves.com/2011/11/15/list-of-web-accessibility-related-litigation-and-settlements/
>
>
> > However, a court case against a corporate entity is different; public
> opinion about what's accessible comes into play there.
> >
> > Plus, given your statement that WCAG is written by hundreds of worldwide
> volunteers, that further weakens WAI/WCAG's clout.
>
>
> I'm sorry but this also betrays a very high degree of ignorance of how
> *any* standards are written and how the W3C works and who's been
> involved in WCAG. The WCAG Working Group isn't exactly the PTA.
> Here's the list of Acknowledgements for WCAG 2.0:
> http://www.w3.org/TR/WCAG20/#acknowledgments
>
> While there may be some people in that list that I have more respect
> for than others, this is a pretty impressive list of experts.
>
>
> > In other words, it's the W3C/WAI that owns and is responsible for the
> standards...NOT the volunteers themselves.
>
> I haven't seen anyone suggest otherwise and I'm confused about where
> that would even come from.
>
> >
> > No United States court of law will decide a case based on the opinion of
> volunteers from various parts of the world, no matter how well intentioned
> the volunteers are.
>
> You're obviously confused about *who* these volunteers are. Your
> continued use of the word "volunteers" is either the result of
> ignorance or is meant as an underhanded dig at the people who created
> the standard.
>
> I don't know everyone who has come & gone in the WCAG Working Group
> but of the names I do recognize, most have had very long careers in
> accessibility.
>
> >
> > But a court can decide a case based on standards from a professional,
> bonafide standards organization...if the standards are presented accurately
> and fully (and of course, formally adopted by the government which
> hopefully will happen soon in the US).
>
> Wait, the W3C isn't a bonafide standards organization?
>
>
> >
> > That's where W3C/WAI is failing; it's not acting like a standards
> organization because it's not doing the entire job that's needed.
> >
>
> Clearly they need your help. I'm connected with Jeff Jaffe on
> LinkedIn. Do you want an intro?
>
>
> > And if W3C/WAI don't have the money to hire professional editors, then
> they should consider holding a bake sale
>
> Again with the PTA stuff. Seriously unproductive.
>
>
> I've stayed out of the thread mostly because I agree that even the
> informative documentation associated with WCAG can be unclear,
> contradictory, and difficult for laypersons to understand.
> But some of the things said in the email to which I'm replying are
> just too inappropriate and incorrect to let slide.
>
> As Chaals said: "Every "W3C Recommendation" has a section called
> "Status of This Document" right near the front, that says how to file
> comments on it. Please do so."
>
>
>
>
> --
>
> Karl Groves
> www.karlgroves.com
> @karlgroves
> http://www.linkedin.com/in/karlgroves
> Phone: +1 410.541.6829
>
> Modern Web Toolsets and Accessibility
> https://www.youtube.com/watch?v=_uq6Db47-Ks
>
> www.tenon.io
> > > > >

From: Patrick H. Lauke
Date: Tue, Dec 01 2015 7:44AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

On 01/12/2015 14:12, Ryan E. Benson wrote:

> If we jump into the WebAIM archives we'd find a thread asking which SC is
> best suited. A good portion of the time it is cut and dry, but there are a
> few that are like "well you can think of it this way, that way, or this
> other way." I remember a few were the thread got to two dozen replies, and
> the person who originally asked was like "....so guys what SC should they
> be dinged with?"

And that, to me, shows the fundamental tension between "making something
accessible" vs "making it pass all of WCAG 2.0's SCs". There's overlap,
but these two goals are not the same. And there's a danger if
legislation purely leans on the latter, rather than the former (as
Leonie mentioned earlier in the thread, many countries use WCAG 2.0 as a
guide/reference, but NOT as a technical standard that simply needs to be
followed/whose checkboxes need to be ticked).

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Andrew Kirkpatrick
Date: Tue, Dec 01 2015 8:22AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

>As Chaals stated, you should file bugs against the materials. While
>the spec itself is not going to be changed anytime soon (sad, IMO) you
>can still contribute to the numerous additional materials.
>
>WCAG does (most of) its work out in the open. You merely need to take
>the time to identify specific shortcomings and log them as issues in
>their Github repository at https://github.com/w3c/wcag/issues
>...
>As Chaals said: "Every "W3C Recommendation" has a section called
>"Status of This Document" right near the front, that says how to file
>comments on it. Please do so."

I'm writing in response to this thread as one of the co-chairs of WCAG, and I do agree that there is plenty of room for improvement in the WCAG techniques and understanding documents and in the WCAG 2.0 standard. As Karl and others have indicated, please do submit comments.

If anyone submits a comment via the = EMAIL ADDRESS REMOVED = email address or submits an issue via github, we will log any email comment as a github issue and then we will work to resolve the issue. Sometimes the resolution is easy (bad links, typos), sometimes not (requests for interpretation for a new situation, ideas for new techniques, blanket condemnation of the original writing style). In the latter case, suggestions may be added to a backlog list or to the "post WCAG 2.0" list (for suggestions that exceed the scope of the existing standard but that we want to capture for future extensions or revisions).

There are many opinions and we are happy to listen to and work with anyone who is interested enough to weigh in. Please do send in comments and questions via email or GitHub.

Thanks,
AWK


Andrew Kirkpatrick
Group Product Manager, Adobe Accessibility
Co-Chair, Web Content Accessibility Guidelines Working Group

From: Ryan E. Benson
Date: Tue, Dec 01 2015 8:42AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | Next message →

On Tue, Dec 1, 2015 at 9:44 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote
> And that, to me, shows the fundamental tension between "making something
accessible" vs "making it pass all of WCAG 2.0's SCs".

Then you can always throw the nothing can then be made fully accessible
because there will always be an unique case. The common rebuttal is well we
will ensure that major cases will be covered and have a plan in place for
edge cases. Ok then this directly contradicts the "no checkboxes!" mantra.
The checkboxes here are types of disabilities, not technical standards.

This is the same argument in security, the most secure system is the system
that isn't built.

--
Ryan E. Benson

On Tue, Dec 1, 2015 at 9:44 AM, Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 01/12/2015 14:12, Ryan E. Benson wrote:
>
> If we jump into the WebAIM archives we'd find a thread asking which SC is
>> best suited. A good portion of the time it is cut and dry, but there are a
>> few that are like "well you can think of it this way, that way, or this
>> other way." I remember a few were the thread got to two dozen replies, and
>> the person who originally asked was like "....so guys what SC should they
>> be dinged with?"
>>
>
> And that, to me, shows the fundamental tension between "making something
> accessible" vs "making it pass all of WCAG 2.0's SCs". There's overlap, but
> these two goals are not the same. And there's a danger if legislation
> purely leans on the latter, rather than the former (as Leonie mentioned
> earlier in the thread, many countries use WCAG 2.0 as a guide/reference,
> but NOT as a technical standard that simply needs to be followed/whose
> checkboxes need to be ticked).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Patrick H. Lauke
Date: Tue, Dec 01 2015 8:51AM
Subject: Re: Fixing WAI's writing styleDoes WCAG require ...
← Previous message | No next message

On 01/12/2015 15:42, Ryan E. Benson wrote:

> Then you can always throw the nothing can then be made fully accessible
> because there will always be an unique case. The common rebuttal is well we
> will ensure that major cases will be covered and have a plan in place for
> edge cases. Ok then this directly contradicts the "no checkboxes!" mantra.
> The checkboxes here are types of disabilities, not technical standards.

But even considering a single user group with one particular type of
disability, there will be a myriad different ways in which a particular
problem can technically be addressed. Therefore, a standard like WCAG
necessarily needs to be "fluffy" and open-ended (and tech-agnostic),
requiring interpretation from the general wording to each specific use case.

> This is the same argument in security, the most secure system is the system
> that isn't built.

Sure, I wasn't advocating that WCAG is useless because it will never be
all-encompassing. Just pointing out the tension here regarding those who
will spend more time arguing over the minutiae/interpretation of "which
SC can I ding them with" and the need to make the SCs more
specific/restrictive, versus the acceptance that some more
open-ended/open to interpretation language is necessary.

P
--
Patrick H. Lauke

www.splintered.co.uk | https://github.com/patrickhlauke
http://flickr.com/photos/redux/ | http://redux.deviantart.com
twitter: @patrick_h_lauke | skype: patrick_h_lauke