Change Proposal: ISSUE-122 / ISSUE-31 Text Alternative Examples
- HTML5 ISSUE-122 shalott-example and HTML5 ISSUE-31 alt
- Editor: Laura Carlson
- Date: November 7, 2010. Last updated December 7, 2010.
- Please address feedback to the HTML Working Group mailing list (email@example.com)
Remove text alternative examples from HTML drafts. Give the examples to the Web Content Accessibility Guidelines Working Group (WCAG WG) to incorporate into their specs and technique documents. Let the accessibility requirements on the possible values of the text alternatives be defined by WCAG 2.0 and not HTML5. Add a prominent reference to WCAG 2.0 and its techniques for authors to obtain this information.
At times the value for text alternatives is subjective. This is especially true for mood-setting images such as Issue 122's Bug 9077 and Bug 9081. It is difficult to come up with a general "best rule" for images that "enhance the themes or subject matter of the page content" since in many cases like this, it is a matter of style. If we made a test and asked 10 different accessibility professionals to provide text alternatives, we will likely get 10 different answers. Throw in 400 HTML working group members and we can up that number to 410 different answers. In fact, we can get different answers from different blind folks as well (i.e. people blind from birth versus people who become blind later in life). If we are looking for consistency in these text alternative values, we will fail, since we won't be able to please all of the people all of the time.
The best HTML5 can do is to point authors to the W3C's domain that is chartered to deal with these issues. That domain is the Web Accessibility Initiative (WAI). WAI's WCAG, WG Authoring Tool Accessibility Guidelines Working Group (AUWG), User Agent Working Group (UAWG) etc are chartered to set accessibility guidelines and HTML WG is not. Providing the mechanism(s) for a text alternative is an inalienable HTML WG concern. Whereas providing guidance on values for alternative text is an inalienable WAI concern.
- Refers authors to the WAI's Web Content Accessibility Guidelines 2.0 (WCAG). Accessibility is WAI's domain and specialty. If any group has a chance to find an answer, WAI is that group. WAI develops guidelines which are widely regarded as the international standard for Web accessibility. WAI's WCAG defines how to make Web content more accessible to people with disabilities.
- Eliminates repetition and conflicting information within the HTML Working Group.
- Is consistent with both HTML5 and HTML 4 precedent for deferring accessibility concerns to the WAI domain.
- The HTML5 ISSUE-66 decision said that UAAG is the proper place to provide Image Analysis Heuristics assistance. Image Analysis Heuristics language was removed from HTML5 and given to UAAG.
- HTML4 states, "Implementors should consult the section on accessibility for information about how to handle cases of omitted alternate text." The notes on accessibility section, refers people to the Web Content Accessibility Guidelines, the User Agent Accessibility Guidelines, and the Authoring Tool Accessibility Guidelines.
- Alleviates duplication of effort and double maintenance.
- Eliminates repetition and conflicting information between the HTML WG and WAI Working Groups.
- If ever needed, WAI has built in cross group accessibility coordination. The WAI coordination group exists to harmonize common accessibility cross group topics. For instance besides WCAG, another group under the WAI CG umbrella, is the UA WG. WCAG provides content language. UAWG provides UA language. For example 3.1.1 of the User Agent Accessibility Guidelines deals with UAs identifying the presence of alternative content.
- Is in accord with WAI CG's Consensus Resolutions on Text alternatives in HTML 5 as they recommended:
- that HTML5 state that "For guidance on accessibility requirements for text alternatives authors should consult WCAG 2.0."
- and that HTML should not provide any guidance that conflicts with WCAG.
- Benefits other use cases besides the disabled (i.e. people who turn off images, users who have expensive data roaming connections, users with text-only browsers, users with voice browsers in vehicles). WAI has addressed these types of auxiliary benefits and business use cases for years.
- As one study indicates, users prefer embedded reference links into the body of a document instead of lumping them all into one section. They believed that embedding the links within a document made it easier to navigate, easier to recognize key information, easier to follow the main idea of the passages, and promoted comprehension.
- Parts of WAI are member only. However, non-members can contribute to groups such as WCAG.
- Remove all text alternative examples from HTML5 drafts. This includes:
- Sections 184.108.40.206 to 220.127.116.11.11 under Requirements for providing text to act as an alternative for images in HTML5.
- The two HTML5 examples in 4.8.1 that begin "A single image can have different appropriate alternative text depending on the context..." and "Here are some more examples showing the same picture used in different contexts, with different appropriate alternate texts each time..." Both are marked with
- All of the specification HTML5: Techniques for providing useful text alternatives.
- Submit all of the work above to WCAG 2.0.
- In the img section of HTML5 add a prominent reference to WCAG 2.0 and its techniques for further details.
Suggested text to add:
Special Thanks To:
- Karl Dubost for his post, A very simple proposal.
- Jason White for his post, Discussion Action 54.
- Ben Boyle for his post, Basing conformance for accessibility questions on subjective determinations.
- Benjamin Hawkes-Lewis for his post Re: Change Proposal: ISSUE-122 Text Alternatives