W3C home > Mailing lists > Public > public-html@w3.org > February 2010

Re: "image analysis heuristics" (ISSUE-66)

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Mon, 8 Feb 2010 12:29:17 +0000
Message-ID: <55687cf81002080429g4e03baaag1e5e38c43450690e@mail.gmail.com>
To: Ian Hickson <ian@hixie.ch>
Cc: public-html@w3.org
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

This archive was generated by hypermail 2.3.1 : Monday, 29 September 2014 09:39:13 UTC