- From: Alan Chuter <achuter@technosite.es>
- Date: Fri, 22 May 2009 09:21:17 +0200
- 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 UTC