- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 31 Aug 2009 10:22:38 +0100
- To: Ian Hickson <ian@hixie.ch>
- Cc: Maciej Stachowiak <mjs@apple.com>, Henri Sivonen <hsivonen@iki.fi>, HTMLWG WG <public-html@w3.org>, W3C WAI-XTECH <wai-xtech@w3.org>
- Message-ID: <55687cf80908310222v6a817c1dj982b5f4224a4fc53@mail.gmail.com>
hi ian,
>WCAG2 gives very little advice regarding alternative text, at least an
>order of magnitude less than HTML5 itself does.
this statement is demonstrably false:
this is a list of the current advisory techniques provided in the WCAG 2.0
advisory documents.
Situation A: If a short description can serve the same purpose and present
the same information as the non-text content:
1.
G94: Providing short text alternative for non-text content that serves
the same purpose and presents the same information as the non-text
content<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G94>using
a
*short* text alternative technique listed below
Situation B: If a short description can *not* serve the same purpose and
present the same information as the non-text content (e.g. a chart or
diagram):
1.
G95: Providing short text alternatives that provide a brief description
of the non-text
content<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G95>using
a
*short* text alternative technique listed below *AND* one of the
following techniques for *long* description:
-
G92: Providing long description for non-text content that serves the
same purpose and presents the same
information<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G92>using
a
*long* text alternative technique listed below
-
G74: Providing a long description in text near the non-text content,
with a reference to the location of the long description in the short
description <http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G74>
-
G73: Providing a long description in another location with a link to
it that is immediately adjacent to the non-text
content<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G73>
Situation C: If non-text content is a control or accepts user input:
1.
G82: Providing a text alternative that identifies the purpose of the
non-text content<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G82>using
a
*short* text alternative technique listed below
Situation E: If non-text content is a CAPTCHA:
1.
G143: Providing a text alternative that describes the purpose of the
CAPTCHA <http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G143>
*AND* G144:
Ensuring that the Web Page contains another CAPTCHA serving the same purpose
using a different
modality<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G144>
Situation F: If the non-text content should be ignored by assistive
technology:
1.
Implementing or marking the non-text content so that it will be ignored
by assistive technology using one of the technology-specific techniques
listed below
-
H67: Using null alt text and no title attribute on img elements for
images that AT should
ignore<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H67>(HTML)
-
C9: Using CSS to include decorative
images<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/C9>(CSS)
*Short* text alternative techniques for use in sufficient techniques above
1.
H36: Using alt attributes on images used as submit
buttons<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H36>(HTML)
2.
H2: Combining adjacent image and text links for the same
resource<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H2>(HTML)
3.
H37: Using alt attributes on img
elements<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H37>(HTML)
4.
H35: Providing text alternatives on applet elements
<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H35> (HTML)
5.
H53: Using the body of the object
element<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H53>(HTML)
6.
H24: Providing text alternatives for the area elements of image maps
<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H24> (HTML)
7.
H86: Providing text alternatives for ASCII art, emoticons, and
leetspeak<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H86>(HTML)
8.
H30: Providing link text that describes the purpose of a link for anchor
elements <http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/H30>(HTML)
*Note: *See * Understanding Success Criterion 2.4.4 Link Purpose (In
Context)<http://www.w3.org/WAI/WCAG20/quickref/#navigation-mechanisms-refs>
*.
9.
G196: Using a text alternative on one item within a group of images that
describes all items in the
group<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/G196>
-
F30: Failure of Success Criterion 1.1.1 and 1.2.1 due to using text
alternatives that are not alternatives (e.g. filenames or
placeholder text)<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F30>
-
F20: Failure of Success Criterion 1.1.1 and 4.1.2 due to not updating
text alternatives when changes to non-text content
occur<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F20>
-
F3: Failure of Success Criterion 1.1.1 due to using CSS to include images
that convey important
information<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F3>
-
F39: Failure of Success Criterion 1.1.1 due to providing a text
alternative that is not null. (e.g. alt="spacer" or alt="image") for images
that should be ignored by assistive
technology<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F39>
-
F38: Failure of Success Criterion 1.1.1 due to omitting the alt-attribute
for non-text content used for decorative purposes only in
HTML<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F38>
-
F71: Failure of Success Criterion 1.1.1 due to using text look-alikes to
represent text without providing a text
alternative<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F71>
-
F72: Failure of Success Criterion 1.1.1 due to using ASCII art without
providing a text
alternative<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F72>
-
F65: Failure of Success Criterion 1.1.1 due to omitting the alt attribute
on img elements, area elements, and input elements of type
"image"<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F65>
-
F67: Failure of Success Criterion 1.1.1 and 1.2.1 due to providing long
description for non-text content that does not serve the same purpose or
does not present the same
information<http://www.w3.org/TR/2008/NOTE-WCAG20-TECHS-20081211/F67>
2009/8/31 Ian Hickson <ian@hixie.ch>
> On Tue, 25 Aug 2009, Maciej Stachowiak wrote:
> > On Aug 24, 2009, at 10:24 PM, Ian Hickson wrote:
> > >
> > > I would be open to including references to documents that could help
> > > authors and implementors -- UAAG, ATAG, WCAG, UTR #36, CHARMOD, etc.
> > > Indeed, we already have a reference to CHARMOD and UNIVCHARDET.
> >
> > Can't speak for Steven, but that sounds like a really good set of
> > references to me. I think the references should be somewhat more
> > prominent than in HTML4 or SVG, maybe in the introduction instead of
> > relegated to an appendix.
>
> I've added references to these in the intro.
>
>
> On Tue, 25 Aug 2009, Steven Faulkner wrote:
> >
> > In the WAI-CG consenus document there are 2 recommendations that I am
> > addressing in this email:
> > "We recommend
> >
> > - that HTML5 state that "For guidance on accessibility requirements
> for
> > text alternatives authors should consult WCAG
> > 2.0<http://www.w3.org/TR/WCAG20/>
> > ."
> > - and that HTML should not provide any guidance that conflicts with
> WCAG.
> > "
> >
> > The first request is unambiguous to me, can you tell me what needs to be
> > made clearer?
>
> The reasoning behind the request -- that is, the answer to the question
> "why?".
>
> WCAG2 gives very little advice regarding alternative text, at least an
> order of magnitude less than HTML5 itself does. Why would we suggest that
> readers look at WCAG for advice on alternative text specifically?
>
> Should we also reference WCAG at every other relevant point? It doesn't
> seem like that would be useful. We don't reference, say, CHARMOD
> everywhere that it might be useful, or the AWWW document, or any number of
> other informative resources or additional references that might help the
> reader -- so why WCAG, and why specifically in this section?
>
>
> > The second request is ambiguous as the areas where the WAI-CG considers
> > that the content of the spec conflicts with WCAG has not been detailed.
> > The WAI groups are in the process of a full review of the HTML 5
> > specification and I understand that details of conflicts, if any, are
> > forthcoming.
>
> As far as I can tell, WCAG2 refers only to HTML4 and XHTML1.x, so it's not
> possible for HTML5 to contradict it. However, if there is any advice in
> HTML5 that is demonstrably bad for accessibility, I would be very happy to
> change it.
>
>
> > I would obviously be pleased if the accessibility references that point
> > authors and software develoeprs to the relevant specifications were
> > prominent within the spec.
>
> I've added an intro section that references the WAI documents (amongst
> others).
>
>
> On Tue, 25 Aug 2009, Henri Sivonen wrote:
> > On Aug 25, 2009, at 08:24, Ian Hickson wrote:
> > >
> > > I don't really understand what problem we're trying to solve here. Why
> > > would we give authors using WYSIWYG tools a license to not care about
> > > making their pages accessible? That seems backwards.
> >
> > It's not about giving authors using WYSIWYG tools a license not to care
> > about making their pages accessible. It is about acknowledging that when
> > there's an abstraction layer that hides HTML syntax from the author, the
> > syntax error-based feedback loop to the author doesn't work and instead
> > the feedback is deflected by the tool developer.
>
> I don't follow. If the author isn't checking the syntax of the document,
> and if the author is actively ignoring the tool's requests to make the
> document valid, why would the author then complain about the document
> being invalid? Or are you saying other people complain? I don't fully
> understand the situation you are describing.
>
>
> > The problem being solved is removing the incentive not to conform to
> > ATAG 2 in order to perform the deflection. (The tool vendor can't
> > enforce WCAG 2 compliance of the tool users.)
>
> (I don't think WCAG 2 need be invoked here -- as far as I can tell, HTML5
> itself has the relevant requirements too.)
>
>
> > The right place to for software to complain at users of WYSIWYG tools
> > about lack of accessibility is the WYSIWYG tool complaining at the user.
> > A validator is the right place to complain at authors who don't use
> > WYSIWYG editor-like abstraction layers between them and HTML syntax.
>
> Agreed. So why does it matter what the validator says to WYSIWYG tool
> users?
>
> --
> 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, 31 August 2009 09:23:25 UTC