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

Hi Alan, Andi,

Thanks so much for your comments. To address the raised points below  
and also Anna's comment, I have updated and attached a new version of  
this document. My changes are as follows:

1. Added a new sentence "For a comprehensive comparison, see  
Relationship between Mobile Web Best Practices (MWBP) and Web Content  
Accessibility Guidelines (WCAG)" to the second parag. in the  
introduction to address Anna's comment (<http://lists.w3.org/Archives/ 
Public/w3c-wai-eo/2009AprJun/0082.html>);
2. Combined "Embedded non-text objects (images, sound, video) with no  
text alternative" & "Important information in non-text content  
(images,  multimedia, CSS effects)" into a single item called "Non- 
text objects (images, sound, video)
         with no text alternative".
3. "Free-text entry (for example, alphabetical characters allowed in   
numeric fields)" changed the title to "Text entry" and also updated  
the references so now it doesn't refer to WCAG 1.0 CP 10.4 and MWBP  
AVOID_FREE_TEXT and it refers to WCAG 2.0 SC 3.3, I have also updated  
the text to make it more clear;
4. Split "Scripting required to operate or generate content" into two:
	i) "Scripting required to operate content" and kept it under  
"operable", also updated the WCAG 2.0 references to "# Conformance  
Requirement 4: Only Accessibility-Supported Ways of Using  
Technologies and
#  Conformance Requirement 5: Non-Interference" based on the table  
here: <http://www.w3.org/WAI/WCAG20/from10/comparison/>
	ii) "Scripting required to generate content" and moved to "Robust"  
and also added a reference to "Understanding Guideline 4.1".

Please let me know if you are happy with these changes and I will  
also update the tabular version to reflect these changes.

Regards,
Yeliz.
On 22 May 2009, at 10:21, Alan Chuter wrote:

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