- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 8 Feb 2010 12:29:17 +0000
- To: Ian Hickson <ian@hixie.ch>
- Cc: public-html@w3.org
- Message-ID: <55687cf81002080429g4e03baaag1e5e38c43450690e@mail.gmail.com>
Hi Ian, >First, on what basis do you think that referencing another spec results in more >accessible implementations than having inline text? problem is many instances the spec does not provide inline text: for example the title attribute is and has been problematic for a range of users with disabilities, but you have rejected suggestions ( http://www.w3.org/Bugs/Public/show_bug.cgi?id=5807) to put text inline or a reference to the relevant part of the UAAG spec. well actually you did put some text in there for a while: http://html5.org/tools/web-apps-tracker?from=3918&to=3919 "User agents are encouraged to make it possible to view tooltips, without the use of a pointing device, since not all users are able to use pointing devices." then it appears it was removed. The text you put in really gives no advice on how to provide an accessible tootltip, probably because its out of scope. referencing the UAAG advice on this issue would give browser developers comprehensive advice on what is required, having only the single generic link in the spec at the top, thus is clearly inferior to providing a link in context, (and is definitely out of sight out of mind) your text, which you later removed, provides nothing but a suggestion *Please* explain how would the following text NOT be an improvement on what is currently in the spec? (which is nothing) "Not all users are able to use pointing devices In order to make tooltips accessible without the use of a pointing device. User agents must also make it possible to display tooltips using the keyboard. Advice on how to provide conditional content (such as tooltips) accessibly is available in the <a>User Agent Accessibility Guidleines</a>" link points to - http://www.w3.org/TR/UAAG10/guidelines.html#tech-conditional-content: Full text of Checkpoint-- 2.3 Render conditional content (P1) Techniques for checkpoint 2.3 Allow configuration to provide access to each piece of unrendered conditional content "C". When a specification does not explain how to provide access to this content, do so as follows: If C is a summary, title, alternative, description, or expansion of another piece of content D, provide access through at least one of the following mechanisms: (1a) render C in place of D; (2a) render C in addition to D; (3a) provide access to C by allowing the user to query D. In this case, the user agent must also alert the user, on a per-element basis, to the existence of C (so that the user knows to query D); and (4a) allow the user to follow a link to C from the context of D. Otherwise, provide access to C through at least one of the following mechanisms: (1b) render a placeholder for C, and allow the user to view the original author-supplied content associated with each placeholder; (2b) provide access to C by query (e.g., allow the user to query an element for its attributes). In this case, the user agent must also alert the user, on a per-element basis, to the existence of C; and (3b) allow the user to follow a link in context to C. Sufficient techniques To satisfy provision one of this checkpoint, the configuration may be a switch that, for all content, turns on or off the access mechanisms described in provision two. To satisfy provision two of this checkpoint, the user agent may provide access on a per-element basis (e.g., by allowing the user to query individual elements) or for all elements (e.g., by offering a configuration to render conditional content all the time). To satisfy the requirement of provision two of this checkpoint to allow the user to view the content associated with each placeholder, the user agent may either render the associated content in a separate viewport or in place of the placeholder. Normative inclusions and exclusions For the placeholder requirement of provision two of this checkpoint, a request to view the original content associated with a placeholder is considered an explicit user request to render that content. The user agent is not required to include placeholders in the document object. A placeholder that is part of the document object should conform to the Web Content Accessibility Guidelines 1.0 [WCAG10]. If a placeholder is not part of the document object, it is part of the user interface only (and subject, for example, to checkpoint 1.3). Conformance detail: For all content Note: For instance, an HTML user agent might allow users to query each element for access to conditional content supplied for the alt, title, and longdesc attributes. Or, the user agent might allow configuration so that the value of the alt attribute is rendered in place of all IMG elements (while other conditional content might be made available through another mechanism). regards Stevef On 8 February 2010 11:50, Ian Hickson <ian@hixie.ch> wrote: > > On Mon, 8 Feb 2010, Steven Faulkner wrote: > > >> > > >> The subject of the UUAG specification is user agent accessibility, > > >> it's is not the subject of the HTML5 spec. > > > > > >How user agents are to make HTML content accessible is certainly within > > >the scope of the HTML spec. How to make the user agent's own user > > >interface accessible isn't, though, I agree. That's why UAAG is > > >referenced in the introduction to the spec. > > > > Only providing a reference in the intro does a dis-service to users with > > disabilities, the UAAG spec should be pointed to where ever the HTML5 > > spec touches on aspects of accessibility that are considered out of > > scope. > > I disagree with the premise of this statement in two places. First, on > what basis do you think that referencing another spec results in more > accessible implementations than having inline text? Second, on what > aspects of accessibility that are considered out of scope does the HTML > spec touch? I would argue there are none. All aspects of accessibility > that it touches on are in scope, IMHO. > > > > >> I do not consider you do justice to accessibility by selectively > > >> including bits of accessibility related advice you find important, > > >> while neglecting other aspects. > > > > >If there are aspects of how to make HTML accessible that are neglected, > > >please let me know what they are (by filing bugs). There should not be. > > > > which is what I have done and will continue to do so. > > Excellent, thanks. In that case, your aforementioned concern is presumably > allayed, so I don't see why you mentioned it. > > -- > Ian Hickson U+1047E )\._.,--....,'``. fL > http://ln.hixie.ch/ U+263A /, _.. \ _\ ;`._ ,. > Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.' -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 8 February 2010 12:30:11 UTC