WCAG and MWBP comments

Hi Alan & Yeliz,

Please see the comments below. Note that Andi commented on both the TR/technical document that Alan is editing and the "Shared Experiences" document that Yeliz most recently edited.

Can you each take a look at these and make edits in your documents as appropriate. Note that some comments might trigger edits needed in another page.

Per Andi's e-mail, fee free to contact her if you need clarification.

Also, could you let me know when you will be able to get to these edits? We have no particular deadline, except that we're eager to finish up the technical document and get it published.

Thanks!
~Shawn



-------- Original Message --------
Subject:  WCAG and MWBP comments
Date:  Tue, 19 May 2009 17:08:53 -0500
From:  Andi Snow-Weaver <andisnow@us.ibm.com>

Shawn,

I reviewed the Editor's draft of the Relationship between MWBP and WCAG.

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20090428/

And I did it rather hurriedly so if something doesn't make sense, please 
feel free to follow up.

There's not much in this document so I assume you want feedback on the 
substantive pages linked to from this document. I focused on the WCAG 
2.0 mappings more than the WCAG 1.0 mappings.

There are two links to Shared experiences 
(http://www.w3.org/WAI/mobile/experiences.html) but then a link to a 
"table of barriers common ..." 
(http://www.w3.org/WAI/mobile/experiences-new-format). The latter page 
links to another page which looks like a replacement to the shared 
experiences page? I only reviewed the experiences-new-table.

[Note from Shawn: Alan, please change:
<li>Use the <a href="http://www.w3.org/WAI/mobile/experiences-new-format">table of barriers common to mobile device users and people with disabilities</a> for an overview of the barriers and solutions shared by WCAG 2.0 and MWBP.
TO:
<li>Use <a href="http://www.w3.org/WAI/mobile/experiences">Shared Web Experiences: Barriers Common to Mobile Device Users and People with Disabilities</a> (which is also available in a <a href="http://www.w3.org/WAI/mobile/experiences-table">table format</a>) for an overview of the barriers and solutions shared by WCAG 2.0 and MWBP.
]

Here are my comments:

[*** Yeliz's document ***]

Table of Shared Web Experiences: Barriers Common to Mobile Device Users 
and People with Disabilities [Draft, 14 October 
2008]http://www.w3.org/WAI/mobile/experiences-new-table

[Note from Shawn: It was our fault she reviewed the wrong version. I've now added a note to that page pointing to the published version. Anyway, I think the content is the same so her comments probably still apply.]

Perceivable

* Multimedia with no captions - references WCAG 2.0 SC 1.1.1. Should 
reference 1.2.2, 1.2.4, and 1.2.8.

* Audio-only prompts (beeps) for important information (warnings, 
errors) - references WCAG 2.0 SC 1.1.1. Should reference 1.2.1.

* Embedded non-text objects (images, sound, video) with no text 
alternative - typo - "losses information" should be "loses information"

* "Embedded non-text objects (images, sound, video) with no text 
alternative" & "Important information in non-text content (images, 
multimedia, CSS effects)" seem like the same use case. Recommend 
combining. Also, the Web context gets into the area of 
accessibility-supported Web technologies (Information not available to 
user whose browser, assistive technology, other user agent doesn't 
support object).

* Free-text entry (for example, alphabetical characters allowed in 
numeric fields) - references WCAG 1.0 checkpoint 10.4 (include 
place-holding characters in text areas) and WCAG 2.0 SC 1.1.1 (non-text 
content). The issue being described here is a user with a mobility 
impairment who has trouble entering information or a mobile device users 
who must use a small keypad. WCAG 1.0 10.4 (pri 3) is a work-around for 
user agents who don't support empty controls well. And WCAG 2.0 1.1.1 is 
not relevant at all because text areas are not "non-text content". WCAG 
2.0 does have some SC around errors in forms but I don't think they are 
related to the MWBPs for this use case (MINIMIZE KEYSTROKES, PROVIDE 
DEFAULTS, DEFAULT INPUT MODE). I recommend that this use case be deleted 
from the table.

* Content formatted using tables or CSS, and reading order not correct 
when linearized (for example when CSS or tables not rendered) - the 
experience for this use case is "User cannot access the correct ordering 
of the information on a page because the content is garbled." Recommend 
changing this to "User cannot understand the content correctly when it's 
presented in a linear order."

Operable

* Scripting required to operate or generate content - references WCAG 
2.0 keyboard SC 2.1.1 and 2.1.3. I don't think there is a mapping to a 
WCAG 2.0 SC for this. Rather it maps to the concept of relying on 
scripts as an accessibility supported Web technology.

* Special plug-in required - same issue as scripting required. Also, 
there is a typo in this line. It repeats the column header in the 
Disability context column.

* Non-descriptive link label - disability context sounds like blind 
users can only read links out of context in a list. Suggest changing to 
"User who is blind often accesses a list of links on a page without the 
context around them."

Understandable

* Blinking, moving, scrolling, or auto-updating content - references 
WCAG 2.0 SC 3.2.5. I think it should also reference 2.2.2. In the 
disabilities context, there is also the distraction issue.


[*** Alan's document ***]

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20090428/wcag20-mwbp.html 


Nothing list

* STYLE_SHEETS_SUPPORT bullet - I don't agree that this is covered by 
1.3.1. The MWBP requires that the page be usable with style sheets 
disabled. In WCAG 2.0, you can rely on style sheets if you consider it 
to be an accessibility supported Web technology. It is possible to have 
all of the information and structure be programmatically determined but 
the page would not be usable without the style sheets. ARIA is one 
technology that depends heavily on style sheets and ARIA sites will not 
be usable (by sighted users) with the style sheets disabled.

* STYLE_SHEETS_USE bullet - WCAG 2.0 allows, but does not encourage, 
layout tables as long as they meet all of the other criteria. If the 
MWBP requires the use of style sheets and not layout tables, then 1.3.1 
would not meet the MWBP criteria and more would be required.

Something

* COLOR_CONTRAST link doesn't work - I think this should go in the 
"Nothing" list. If you meet the WCAG 2.0 measurable criteria, that 
should be good enough to meet the subjective MWBP criteria too.

* CONTROL_LABELLING - I think that if you do the labeling portion of 
3.3.2 AND EITHER 1.3.1 OR 4.1.2, then you meet the MWBP and there would 
be nothing else to do.

* CONTROL_POSITIONING - I think this should say " 1.3.1 ... at level A 
if the label element is used. The advisory (optional) technique 
(“Positioning labels to maximize predictability of relationships”) is 
also required.

* NON_TEXT_ALTERNATIVES - confused as to why this is in both the Nothing 
and the Something list.

* OBJECTS_OR_SCRIPT - I don't think the Keyboard SC help with this. It 
may be a script that is managing the keyboard operation.

http://www.w3.org/2005/MWI/BPWG/Group/TaskForces/Accessibility/drafts/ED-mwbp-wcag-20090428/mwbp-wcag20.html

* I only briefly scanned this document but didn't see any glaring problems.

Andi

Received on Wednesday, 20 May 2009 20:03:51 UTC