W3C home > Mailing lists > Public > public-html@w3.org > August 2009

Re: feedback requested on WAI CG Consensus Resolutions on Text alternatives in HTML 5 document

From: Steven Faulkner <faulkner.steve@gmail.com>
Date: Mon, 31 Aug 2009 10:22:38 +0100
Message-ID: <55687cf80908310222v6a817c1dj982b5f4224a4fc53@mail.gmail.com>
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>
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 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Wednesday, 9 May 2012 00:16:44 GMT