W3C home > Mailing lists > Public > w3c-wai-eo@w3.org > April to June 2009

Re: EOWG: For 22 May discussion: WCAG and MWBP comments

From: Alan Chuter <achuter@technosite.es>
Date: Fri, 22 May 2009 09:21:17 +0200
Message-ID: <4A16526D.4040407@technosite.es>
To: "EOWG (E-mail)" <w3c-wai-eo@w3.org>
CC: Yeliz Yesilada <yesilady@cs.man.ac.uk>
Shawn Henry wrote:
> Yeliz implemented them into the Shared Experience document, which is 
> attached (the same information in linear and tabular format). Below are 
> some points for discussion on these documents.
> 
>> * "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).
> 
> I prefer to keep these two separate as I think even though they  overlap 
> they focus on different barriers.

The text "CSS effects" is mising in the linearised version.

Perhaps "run up connection charges" and "be billed for" could be written 
in a way that would be easier to understand for non-native speakers. for 
example "Prefers to minimize connection charges" and "may have to pay 
for". Avoid gender-specific "he".

Regarding Andi's comment, it's not clear to me what the difference is 
between the two items. I suspect that the first is about content for 
which it is not technically feasible to provide an adequate text 
alternative, such as a video (in the mobile context) or an interactive 
applet. In the second case we are saying that people must provide an 
alternative, otherwise these barriers will result. In the first case, a 
text alternative is provided but it probably won't be equivalent due to 
the nature of the content. So perhaps the heading should be "Embedded 
non-text objects (images, sound, video) for which text alternative may 
not be equivalent." I think that some further explanation is needed here.

>> * 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.
> 
> I think this an interesting use case and it is a nice one that shows  
> overlaps. In fact, the listed MWBP explicitly references to WCAG 10.4  
> <http://www.w3.org/TR/mobile-bp/#MINIMIZE_KEYSTROKES>. I agree that  
> WCAG 2.0 1.1.1 may be is not very relevant, but may be we can refer  to 
> Guideline 2.1 here or Guideline 3.3.

I agree with Andi that WCAG 1.0 checkpoint 10.4 is irrelevant here, and 
its inclusion in the BP is a mistake that should be corrected by the 
MWBP WG. The characters WCAG implies are not default values. they are 
more likely to be "Type your name here" or "dd/mm/yyyy".

I also agree that the WCAG 2.0 SC is not relevant. It would have been a 
good idea to include this BP in WCAG 2.0 under Guideline 3.3 "Input 
Assistance: Help users avoid and correct mistakes", although it is 
covered by HTML 5 and XForms I think. So there are no equivalent WCAG 
provisions.

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

"Scripting required to operate or generate content" needs to be split 
into two.

One is "Scripting required to generate content" and perhaps it should be 
moved to the "robust" section. Although WCAG 2.0 allows content to rely 
on scripting, in the mobile context it is perhaps not an 
accessibility-supported technology (simply not supported at all), but in 
the wider context it is about being robust. I don't think there is a 
WCAG 2.0 SC for this, but under WCAG 1.0 it is CP 6.3. The experience is 
"User loses some information."

The other item would be "mouse required to operate content" under 
operable. The WCAG 2.0 SCs are 2.1.1 Keyboard, 2.1.3 "Keyboard (No 
Exception)". for WCAG 1.0 they are 6.4 and 8.1. The experience is "User 
cannot operate the content."

CP 6.5 is a mistake here and should be dropped.

I can't be on the call today, but hope this helps move this document 
towards completion.

best regards,

Alan


-- 
Alan Chuter
Departamento de Usabilidad y Accesibilidad
Consultor
Technosite - Grupo Fundosa
FundaciĆ³n ONCE
Tfno.: 91 121 03 30
Fax: 91 375 70 51
achuter@technosite.es
http://www.technosite.es
Received on Friday, 22 May 2009 07:24:37 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Friday, 27 April 2012 10:33:55 GMT