eramp, a strategic approach to accessibility, fingerspelling 'eramp quality'

 

HTML 5 Review

Possible confusion/conflict with WCAG 2.0

In my review of sections 4.4 to 4.8 there was a variety of grammar, spelling, code typos, and editorial comments (further below). There was only one issue which I believe largly impacts and possible conflicts with WCAG 2.0.

4.8.2.1.6 Text that has been rendered to a graphic for typographical effect

The current wording of the WCAG 2 says:

pure decoration
serving only an aesthetic purpose, providing no information, and having no functionality (emphasis added)

HTML 5 says:

Examples where the image is purely decorative despite being relevant would include things like a photo of the Black Rock City landscape in a blog post about an event at Burning Man, or an image of a painting inspired by a poem, on a page reciting that poem. The following snippet shows an example of the latter case (only the first verse is included in this snippet):

<h1>The Lady of Shalott</h1>
<p><img src="shalott.jpeg" alt=""></p> 
<p>On either side the river lie<br>

We have no provision currently in the WCAG 2.0 wording for “relevant” information that is purely decorative. We had WCAG discussions about this and our consensus was to leave the WCAG language as is. We decided to require a text alternative, because ARIA would fix the problem, by allowing the Success Criteria to be satisfied without redundency in the in the ALT text.

 

If HTML 5.0 goes to TR like this it will override that requirement. I don't think HTML 5.0 document should go into this type of detail on the characteristics of ALT text because of the implications and confusion with the current and unchangeable WCAG 2.0 language for text alternatives.

 

An common example in this category would be a biography with a picture of the person. ARIA would relate the biography to the picture. However this HTML 5.0 paragraph on alternative text is short circuiting that by forcing people into a judgment call about whether a picture that is “relevant” is pure decoration or not. I don’t think there would be a broad consensus among experts on this type of call, and therefore is untestable.

 

The general consensus of the blind community is that they want to know if there is a picture that supplements text. They said they would want to know there is an image of Shalott there.  I’ve surveyed the blind community when WCAG was discussing this and this was the consensus of those I spoke with.

 


Consider numbering the examples… Example 1, Example 2 etc… inside each section. It would make them easier to refer to.


 

4.4.2 The section element.
1st example has HTML in small case, 2nd example has HTML in capitals… is that intentional? Code of 2nd example, although correct is a messy layout with line breaks in weird places.


4.4.3 In the first example for 4.4.3 we find.4.8.2.1.6 Text that has been rendered to a graphic for typographical effect

<body>
 <header>
  <h1>Wake up sheeple!</h1>
  <p><a href="news.html">News</a> -
     <a href="blog.html">Blog</a> -
     <a href="forums.html">Forums</a></p>
  <p>Last Modified: <time>2009-04-01</time></p>
<nav>
   <h1>Navigation</h1>
   <ul>
    <li><a href="articles.html">Index of all articles</a></li>
    <li><a href="today.html">Things sheeple need to wake up for today</a></li>
    <li><a href="successes.html">Sheeple we have managed to wake</a></li>
   </ul>
  </nav>

Do we really need the h1 that says “Navigation” in the example if it’s already in a Nav element? Do we want that?

Also there is a group of links at the top that has no <nav> element around it. It is 3 links. The section with the <nav> element wrapped around it is also 3 links. I think this leads to some confusion. Consider adding say 3 more links to the section inside the <nav> elements to distinguish it more clearly from the non-nav link sections. Also there could be a better distinction made about when and when not a <nav> element should be used.


 

4.4.6
The example for 4.4.6 could be a bit of a mind twist for average web masters, and may need more explanation. What does “equivalent” mean? Perhaps say: “The headings in the two snippets below are at equivalent logical levels.”

These two snippets are equivalent:

<body>
<h1>Let's call it a draw(ing surface)</h1>
<h2>Diving in</h2>
<h2>Simple shapes</h2>
<h2>Canvas coordinates</h2>
<h3>Canvas coordinates diagram</h3>
<h2>Paths</h2>
</body>



<body>
 <h1>Let's call it a draw(ing surface)</h1>
 <section>
  <h1>Diving in</h1>
 </section>
 <section>
  <h1>Simple shapes</h1>
 </section>
 <section>
  <h1>Canvas coordinates</h1>
  <section>
   <h1>Canvas coordinates diagram</h1>
  </section>
 </section>
 <section>
  <h1>Paths</h1>
 </section>
</body>

Why are some of the example code snips throughout the document in all CAPS, and other in small case?


 

The <nav> element section 4.4.3 has the following text:

 

Not all groups of links on a page need to be in a nav element — only sections that consist of major navigation blocks are appropriate for the nav element. In particular, it is common for footers to have a short list of links to various pages of a site, such as the terms of service, the home page, and a copyright page. The footer element alone is sufficient for such cases, without a nav element.

 

Yet the <footer> section 4.4.9 example has a <nav> element in the footer… I think that is inconsistent.

<FOOTER> <!-- site wide footer -->
 <NAV>
  <P><A HREF="/credits.html">Credits</A> —
     <A HREF="/tos.html">Terms of Service</A> —
     <A HREF="/index.html">Blog Index</A></P>
 </NAV>
 <P>Copyright © 2009 Gordon Freeman</P>
</FOOTER>


Typo in 4.4.10

The contact information for a node node is a collection


Also something seems off here in 4.4.10

If node is an article element
If node is a body element
The contact information consists of all the address elements that have node as an ancestor and do not have another body or article element ancestor that is a descendant of node.
If node has an ancestor element that is a [typo should be “an”] article element
If node has an ancestor element that is a body element
The contact information of node is the same as the contact information of the nearest article or body element ancestor, whichever is nearest.


4.6.18


Typo:

A number if [typo should be “is”] said to be followed by a denominator punctuation character if it is followed by zero or more White_Space characters and a valid denominator punctuation character.

Progress bar and meter are probably not yet supported by AT but I guess we are hoping AT will catch up.


4.6.20
In the Ruby section it is not clear how the <rt> element put the annotations on the side for the Chinese and on the top for Japanese… the code looks identical.



4.6.23 The bdo element
Consider a code example

 


 

 

4.6.21  Is this ruby code ok… there is no closing bracket on the <rt> element…


<ruby> OJ <rp>(<rt>Orange Juice<rp>)</ruby>


 

4.7.5
To indicate that an item is inserted or deleted, an ins or del element can be wrapped around the contents of the li element. To indicate that an item has been replaced by another, a single li element can have one or more del elements followed by one or more ins elements.

It’s unclear if each instance of <ins> has to have a corresponding <del> intem in lists.

 


 

4.8.1

<img src="bubbles-work.jpeg"

Consider  *.jpg   it’s more common.

 



4.8.2 says:

<p>I've got a cat named Fluffy and a dog named Miles.</p>
 <img src="fluffy.jpg" alt="Fluffy, my cat, tends to keep itself busy.">


Alt text should generally not have commentary but describe the image purpose.  Consider changing the example to

alt= “Fluffy my cat plays with a ball of yarn.”

 

I don’t think the following good/bad examples are the best. The bad example text is very subtle and I don’t think it teaches too much. I think it reads not bad.

<!-- This is the correct way to do things. -->

<p>You are standing in an open field west of a house.

<img src="house.jpeg" alt="The house is white, with a boarded front door.">

There is a small mailbox here.</p>

Second, here's the bad solution. In this incorrect way of doing things, the alternative text is simply a description of the image, instead of a textual replacement for the image. It's bad because when the image isn't shown, the text doesn't flow as well as in the first example. <!-- This is the wrong way to do things. --><p>
You are standing in an open field west of a house.

<img src="house.jpeg" alt="A white house, with a boarded front door.">There is a small mailbox here.</p>


 

4.8.2.1.6 Text that has been rendered to a graphic for typographical effect

The general consensus of the blind community is that they want to know if there is a picture that supplements text… the current wording of the WCAG 2 is in contrast with this;

WCAG 2 Says:

pure decoration
serving only an aesthetic purpose, providing no information, and having no functionality

HTML 5 says
Examples where the image is purely decorative despite being relevant would include things like a photo of the Black Rock City landscape in a blog post about an event at Burning Man, or an image of a painting inspired by a poem, on a page reciting that poem. The following snippet shows an example of the latter case (only the first verse is included in this snippet):

<h1>The Lady of Shalott</h1>
<p><img src="shalott.jpeg" alt=""></p> 
<p>On either side the river lie<br>

 

I suggest that we have no provision currently in WCAG for “relevant” information that is purely decorative. We had large WCAG discussions about this and our consensus was to leave the WCAG language as is, because ARIA would fix the problem, by allowing the SC to be satisfied if the text of a biography was related to the picture of the person, without the redundancy of alt text. (ARIA would relate the two) However this HTML 5.0 paragraph on alternative text is short circuiting that by forcing people into a judgment call about whether a picture that is “relevant” is pure decoration or not. I don’t think there would be a broad consensus among experts on this typ of call, and therefore is untestable.

I think many in the blind community would disagree that a picture like this is pure decoration. They would want to know there is an image of Shalott there.  I’ve surveyed the blind community and this appears to be the consensus of those I spoke with.

(Also, consider a different example than “Burning Man” which is basically a religious event that could be divisive to some audiences, and would best be left out of a worldwide standard that is targeted to people of all religions. Given the widespread drug use and sex at the event, it would be particularly divisive in countries of the Middle East.)



Do we want to recommend the Title attribute when support is so poor?

 

Sometimes the entire point of the image is that a textual description is not available, and the user is to provide the description. For instance, the point of a CAPTCHA image is to see if the user can literally read the graphic. Here is one way to mark up a CAPTCHA (note the title attribute):



<p><label>What does this image say?
<img src="captcha.cgi?id=8934" title="CAPTCHA">
<input type=text name=captcha></label>
(If you cannot see the image, you can use an <a
href="?audio">audio</a> test instead.)</p>



4.8.3

Grammar

.. , and with the iframe element's document's browsing context as the source browsing context.

(document, not document’s)