How to Save Web Accessibility from Itself

As is now quite widely known among indie developers and virtually
unknown everywhere else, websites are properly created in accordance
with published accessibility standards. The chief source for those
standards is the set of “recommendations” by the World Wide Web
Consortium’s Web Accessibility Initiative (the W3C WAI). These Web Content Accessibility Guidelines (WCAG 1.0)
were last officially updated in 1999.

A new revision of the guidelines, WCAG 2.0, is being written. The
development process is going slowly and is in danger of
recapitulating many of the errors of WCAG 1.0 — unrealistic
guidelines divorced from real-world web development that are at once
too vague and too specific.

But you, the indie developer, can help prevent this tragedy by
investing a small period of time in one of a few limited areas that
may interest you. Instead of working on the entire WCAG, we need you
to focus on topics in which you may have expertise or experience. By
participating in this limited way, you can help save web
accessibility from itself.

Enlightened self-interest#section2

If you choose to make standards-compliant websites, inevitably you
will have to follow the guidelines. It’s foreseeable that you
could be legally required to follow WCAG 2.0. You could opt into
following the guidelines or they could be foisted upon you.

You thus have an enlightened self-interest in ensuring the new
guidelines actually make sense. Moreover, we simply need more
contributors.

The participation problem#section3

I’ve been posting to the W3C’s accessibility-related
mailing lists since 1999 and I still
haven’t figured out how the WAI works. You don’t need to,
either.

You just need to know that the two main mailing lists for WAI discussions are:

WAI-IG

WAI Interest Group. General discussion of web
accessibility.

WAI-GL

WAI Guidelines, home of the Web
Content Accessibility Guidelines Working Group. Discussion of
current and future guidelines.

Not surprisingly, more people are interested in WAI-IG’s
general chitchat than WAI-GL’s topic-specific discussions. From
June 2002 to June 2003, 290 different people posted to WAI-IG, but
fewer than half as many (114) posted to WAI-GL.

That sounds like a lot,  but it isn’t. Web development now
ranges widely, with many overlapping fields of expertise. WCAG 2.0
will impinge on many of those fields, including page structure (XHTML
and similar markup languages), CSS, multimedia, usability,
information architecture, writing, and myriad disability-specific
issues. I know for a fact that leading experts in several web topics
unrelated to disability, whose names would be immediately recognized
by au courant indie developers, simply do not
post to either mailing list. We have no evidence that actual experts
in many pertinent fields are part of the development process for WCAG
2.0.

And it shows. The current drafts of WCAG 2.0 are a marked and
indisputable improvement over the antediluvian WCAG 1.0, but they
still have far too little bearing on the real world of the web.

This is where you come in.

Bite-size pieces#section4

At press time, the current draft of WCAG 2.0 was 14,000 words long
without markup. I don’t see how anybody could tackle something
that big in one sitting. It’s like an anaconda trying to
swallow a Range Rover.

What I’ve done, then, is to break up the WCAG draft into
“action items,” as the business types say. The themes I
have chosen are:

1. Rewrite: The guideline
   needs rewriting and clarification
2. Examples: The guideline
   requires many more examples, preferably drawn from actual websites
   (anonymized if necessary)
3. Unclear on the
   concept: There’s something wrong with the basic
   idea of the guideline
4. Impossible: The guideline, as written, is
   impossible to meet or virtually so
5. Not our
   problem: The issue cannot reasonably be solved
   through guidelines governing web content

Deficiency report#section5

Before everyone starts accusing me of being “too
critical,” which is like accusing the sky of being too blue,
understand that this article is a deficiency report on WCAG
2.0. We can’t afford to pretend to be more positive, upbeat,
and complimentary than is justified by the actual guidelines. We have
only a short window of opportunity to fix what’s wrong, and we
can’t do that without identifying what’s wrong. This
is no time to accentuate the positive.

The approach here is similar to engineering documentation, where
succeeding drafts produce deficiency reports, each of whose items is
either corrected, ruled not to be a deficiency, or simply lived with
until the next draft. The process recurs until collaborators have
corrected or decided to live with every error.

(I have separately written two briefing documents for a previous
face-to-face WCAG meeting that list deficiencies and recommendations, if anyone is interested.)

Where to find the originals#section6

WCAG 2.0 is a moving target.

• I’m using the draft of June 24.
• The latest version has a stable URL that you can
  bookmark.

The documents don’t use enough fragment identifiers. You
can’t link directly to enough sections and paragraphs. Where
there’s a link, I’ll give it, but a lot of the time
you’re going to be stuck using the Find command in your
browser. Moreover, in subsequent drafts, wording is guaranteed to
change.

Action items#section7

Rewrite#section8

These guidelines need rewriting and clarification. But the problem is
much worse than that: The entirety of WCAG 2.0 is a
poorly-written morass. The document violates its own draft guidelines
on clear and simple writing. It is an outright mess, and urgent
plain-English rewrites are required. The Web Accessibility
Initiative, which has a budget, should hire professional
plain-English consultants for this task. It’s time to end the
W3C’s tradition of incomprehensible documents.

Still, for the purposes of this section, we’ll focus on
sections that make next to no sense as written.

1. Overview of Design Principles: Here, the four themes or
   “goals” of WCAG 2.0 are somewhat clumsily named as
   adjectives.

   cite=”http://www.w3.org/TR/2003/WD-WCAG20-20030624/#overview-design-principles”>

   • Perceivable
   • Operable
   • Understandable
   • Robust

2. Make content perceivable by any user. The checkpoint needs fixing. Could you implement it
   as written?

   All non-text content that can be expressed in words has a text
   equivalent of the function or information that the non-text content
   was intended to convey.

   1. Non-text content that can be expressed in
      words has a text equivalent explicitly associated with it.

   2. Non-text content that cannot be expressed
      in words has a descriptive label provided as its text equivalent.

   3. The text equivalent should fulfill the
      same function as the author intended for the non-text content (i.e.,
      it presents all of the intended information and/or achieves the same
      function of the non-text content).

3. What is “non-text content”?

   Non-text content includes but is not
   limited to images, text in raster images, image map regions,
   animations (e.g., animated GIFs), ASCII art, images used as list
   bullets, spacers, graphical buttons, sounds (played with or without
   user interaction), stand-alone audio files, audio tracks of video,
   and video….

4. WAI’s warning against the use of illustrations: If this
   guideline even deserves to be included, it requires rewording.

   Designers need to be cautious in deciding when to use
   illustrations. Reading a picture is probably a learned activity that
   is easier for some than others. Some users skip the pictures; others
   read only the pictures. Designers must also recognize that visual
   conventions are not universal and that individuals develop their own
   mental schema and expectations in interpreting visual information.

5. Retransmitted captioning and audio description: Can you understand
   this guideline?

   If content is rebroadcast from another medium or
   resource that complies to broadcast requirements for accessibility
   (independent of these guidelines), the rebroadcast satisfies the
   checkpoint if it complies with the other guidelines.

6. Definitions should be definitive. These
   aren’t.

   content

   Content is the information or
   meaning and function.

   presentation

   Presentation is the rendering of
   the content and structure in a form that can be sensed by the user.

   structure

   Structure includes both
   hierarchical structure of the content and non-hierarchical
   relationships such as cross-references, or the correspondence between
   header and data cells in a table.

Examples#section9

In this section, these guidelines require more examples. Here is
where my readers can do the most good with the least effort: All we
need, in most of these sections, are a few people’s
contributions of one or two examples each of real-world sites. The
sites you suggest could fully meet, partially meet, or entirely fail
the proposed guideline.

You can also recount your own lived experiences as a web user.

The important thing here is to get WAI out of its habit of
half-arsed hypothesizing. We want their guidelines applied against
existing sites of all descriptions. WAI is not interested in finding
those sites on its own, so we have to hand the facts to them on a
platter.

1. Yet
   more text equivalents. WAI just can’t get enough of those.
   But we need a wider range of actual examples of text equivalents in
   real use today, whether well-done or not.

   1. Non-text content that can be expressed in
      words has a text equivalent explicitly associated with it.

   2. Non-text content that cannot be expressed
      in words has a descriptive label provided as its text equivalent.

      • The text equivalent should fulfill the
        same function as the author intended for the non-text content (i.e.,
        it presents all of the intended information and/or achieves the same
        function of the non-text content).

2. WAI dabbles dangerously in the issue of writing, a topic about which
   it has a demonstrable lack of expertise. Its concern
   with “concrete concepts” and similar classifications of
   the written word is meant to assist people with learning
   disabilities, but little good will come of it unless we know exactly
   what they’re talking about. Do you?

   • Example 1: A description of a
     process.

     A page describes how to learn to play soccer. Each
     step in learning the fundamentals of the game is illustrated with a
     photograph of a player doing what is described in the text.

   • Example 2: A concrete
     concept.

     The primary concept on a page is concrete. It is
     discussing Mt. Pinatubo. It includes both a description of the 1991
     eruption as well as photos of the eruption and the aftermath. It
     links to another site that contains video and another site that
     contains a 3D simulation of what happened underneath the crust and
     within the volcano during the eruption.

   • Example 3: Child’s report of school trip.

     A child went with her school on a trip to a
     bicycle manufacturing plant. She wrote a report for her family and
     friends to post to the web. In the report, she includes the company
     logo as well as a picture of a bicycle on the assembly line. She
     links to the company website for more information. She includes
     photos she took of the plant.

   • Example 4: Stock-trading
     data.

     A news site is comparing the performance of the
     economy from third quarter of this year with third quarter from the
     last three years. They compare prices of the most popular stocks.
     They present the data in a bar graph with a link to the raw data they
     used to create the bar graph.

   • Example 5: History of music.

     A grandfather’s hobby is listening to and
     playing music. He creates a website that includes examples of many
     different types of music and musical instruments. When describing
     specific types of music, he links to a short sound clip.

3. Benefits
   of accessible alternatives need a few case studies (which, oddly, WAI
   could crib from its own page).

   • Individuals who are blind, have low vision, have
     cognitive disabilities or have trouble reading text for any reason
     can have the text read aloud to them.

   • Individuals who are deaf, are hard of hearing or
     who are having trouble understanding the audio information for any
     reason can read the text presentation or have it translated and
     presented as sign language by their assistive technology.

   • Individuals who are blind or deaf-blind can have
     the information presented in Braille.

4. Examples
   of multimedia accessibility: I know I’m not the only one
   who actually watches captioning and audio description. I know that
   few involved in WAI do. Real-life experiences and examples are called
   for here.

   • Example 1: A movie clip with audio
     description and captions.

     A clip from a movie is published on a website. In
     the clip, a child is trying to lure a puppy to the child’s
     bedroom by laying a trail of crumbs. The child mumbles inaudibly to
     himself as he lays the trail. When not watching the video, it is not
     obvious that he is laying a trail of crumbs since all you hear is the
     mumbling. The audio description that is interspersed with the
     child’s mumbling says “Charlie lays a crumb on each stair
     leading to his room.” The caption that appears as he mumbles is
     [inaudible mumbling].

   • Example 2: A video clip of a news
     story.

     A video clip accompanies a news story about the
     recent flooding in a major city. The reporter describes what is seen,
     for everyone. No audio description is necessary. The captions display
     what the reporter is saying.

   • Example 3: A silent
     animation.

     An animation shows a pantomime climbing a ladder.
     There is no audio track for this animation. No captions or audio
     description are required. Instead, a text equivalent is
     provided….

5. Surely we can come up with better real-world examples of a second
   language embedded in a paragraph. I also cleaned up WAI’s copy
   errors below.

   Facilitating unambiguous decoding of characters and words
   in content is also helpful for individuals who are learning to read
   or learning a second language….

   In the following sentence, “And with
   a certain je ne sais quoi, she entered both
   the room, and his life, forever,” the French phrase je ne sais quoi is marked as French. Depending on
   the markup language, English may either be marked as the language for
   the entire document except where specified, or marked at the
   paragraph level.

6. The WAI is unaware that correct table markup makes table structure
   crystal-clear. Also, exactly what “semantic markup” could
   make, for example, homonyms, homographs, and figures of speech
   understandable?

   Provide a summary for relationships that may not be obvious from
   analyzing the structure of a table but that may be apparent in a
   visual rendering of the table.

   If
   contracted forms of words are used such that they are ambiguous,
   provide semantic markup to make words unique and interpretable.

7. Here
   is where standardistas shine. We’re obsessed with the
   proper use of lists, headings, and other XHTML elements. Time to give
   WAI a taste of our glorious compliant medicine. We may have a problem
   finding examples of “chapters” and
   “sections,” because, although they are defined as
   “relationships” of the link
   element, there are no HTML elements for chapters or sections.

   (This passage of the WCAG is particularly pathetic, resorting to
   citing the structure of a bicycle to explain web structure.)

   1. The content has been reviewed, taking into account the
      following strategies for facilitating orientation and movement,
      applying them as appropriate.

      1. Breaking up text into logical
         paragraphs

      2. Providing hierarchical sections and
         titles, particularly for longer documents

      3. Revealing important non-hierarchical
         relationships, such as cross-references, or the correspondence
         between header and data cells in a table, so that they are
         represented unambiguously in the markup or data model

      4. Dividing very large works into sections
         and or chapters with logical labels

      5. Others?

8. How many “expanding outlines” and “dynamic fisheye
   views” have you run through the W3C validator lately?

   site navigation
   mechanism

   A site
   navigation mechanism is a mechanism for easily orienting and
   moving about within the site. Site navigation mechanisms include but
   are not limited to:

   • A
     home page with hyperlinks on it and subsequent pages that link to the
     other pages at the site

   • Site map(s)

   • Search engine(s)

   • Expanding outline(s)

   • Dynamic fisheye views showing all linked pages or topics
     related to any page.

   • 3D
     virtual representations of site content

9. Better examples of consistent
   site layout, anyone?

   • The content has been reviewed, taking into account the
     additional ideas listed below:

     1. Place navigation bars in a consistent
        location whenever possible

     2. Similar layout for user interface
        components should be used for sections or whole site

     3. Similar user interface components should
        be labeled with similar terminology

     4. Use headers consistently

     5. Use templates for consistent presentation
        of sections or whole site

     6. Pages with similar function should have
        similar appearance and layout

     7. Controls that look or sound the same
        should be designed to act the same

     8. Conventions likely to be familiar to the
        user should be followed

     9. Unusual user interface features or
        behaviors that are likely to confuse the first-time user should be
        described to the user before they are encountered

10. Popup
    windows and frames  are among the recurring W3C bugbears that are
    hardly ever used. Still, surely we can find better case histories
    than these.

    • Example 1: A form to deactivate
      pop-up windows.

      A checkbox is provided on a page of links to let
      the user select whether they want the resultant pages to appear in
      new windows or not.

    • Example 2: A warning given before a
      pop-up window.

      At the end of a news story, several links are
      provided for more information. At the beginning of each link is an
      icon of an arrow with the text equivalent, “Link will open in
      new window.”

    • Example 3: Frames that do not track
      history making the back button behave unexpectedly.

    • Example 4: Forms.

    Editorial Note: Some of these
    examples are very brief. Should they be expanded and clarified with
    further details?

Unclear on the concept#section10

These guidelines show such a deep misunderstanding of the topic they
pretend to tackle that they should be deleted or massively rewritten.
Where you can help: See if you can figure out what they are intended
to mean and rewrite them. Or suggest reasons, preferably backed up
with references to real-world sites and development practices, why
they should be deleted.

1. Does anyone, at all, anywhere, use blinking text anymore, and if so,
   how many of those people are using “client-side
   scripting” to do it rather than simply using blink or <a
href="http://www.w3.org/WAI/UA/TS/html401/cp0303/0303-CSS-BLINK.html"
id="text-decoration-blink" title="text-decoration:blink in the style
element">text-decoration:blink? How many user stylesheets
   can override scripts?

   Client-side scripting is used to create blinking
   text. The user can deactivate the use of scripting in his or her
   browser or override the use of scripts with a user style sheet.

2. Unicode
   encoding is desirable, but it is not the only encoding available,
   nor does its absence impair accessibility.

   Text in the content is provided in Unicode or sufficient
   information is provided so that it can be automatically mapped back
   to Unicode.

3. This guideline concerns captioning of web multimedia. Its plain
   reading requires a transcript of all real-time audio broadcasts. That
   is, every single Internet radio station would require transcription.

   Meanwhile, if you have any kind of webcam at all, you need to
   scrounge up some other site you can link to that is somehow the
   “equivalent” of the webcam’s image.

   If the web content is real-time and audio-only and not
   time-sensitive and not interactive a transcript or other non-audio
   equivalent is sufficient. […]

   If the web content is real-time non-interactive video (e.g., a
   webcam of ambient conditions), either provide an equivalent… (e.g.,
   an ongoing update of weather conditions) or link to an equivalent…
   (e.g., a link to a weather website).

4. The Web Accessibility Initiative misunderstands the use of cascading
   stylesheets. Here
   it requires you to come up with a different appearance for dozens of
   HTML elements. (Should the elements em,
   cite, and i really look different?) It also
   requires you to code special black-and-white and monaural stylesheets.

   The structural elements present have a different visual
   appearance or auditory characteristic from each other and from body
   text. […]

   The structural emphases are chosen to be distinct on different
   major visual display types (e.g. black and white, small display, mono
   audio playback). […]

   1. For visual presentations, use font variations, styles,
      size and white space to emphasize structure.

   2. Use color and graphics to emphasize structure.

   3. For auditory presentations, use different voice
      characteristics and/sounds for major headings, sections and other
      structural elements.

   4. If content is targeted for a specific user group and the
      presentation of the structured content is not salient enough to meet
      the needs of your audience, use additional graphics, colors, sounds,
      and other aspects of presentation to emphasize the structure.

5. Foreground/background
   distinctions are, as they say, a personal thing. WAI has provided
   no evidence that authors can reasonably anticipate how a person with
   a visual impairment or learning disability will be confused by
   figure–ground combinations. Further, who runs in “256
   grayscale” anymore, let alone black and white (i.e., one-bit
   colour, like the original Macintosh)?

   1. When text content is presented over a background image or
      pattern, the text is easily readable when the page is viewed in 256
      grayscale.

   2. Text content is not presented over a background image or
      pattern or the text is easily readable when the page is
      viewed in black and white (no grayscale).

   3. Audio content does not contain background sounds
      or the background sounds are at least 20 db lower than the
      foreground audio content.

   4. Text content is not presented over a background image or
      color or the colors used for the text and background or
      background image pass the following test:

      • No tests/algorithms are available at this
        time

6. WAI has not recognized that many, or even most, web-based games are
   going to be inaccessible to someone. It doesn’t make a lot of
   sense to warn of an unpredictable response, thus making it
   predictable.

   Where inconsistent or unpredictable responses are essential to the
   function of the content (e.g. mystery games, adventure games, tests,
   etc.) the user is warned in advance of encountering them.

7. Here is the single biggest minefield in which the Web Accessibility
   Initiative finds itself: Writing guidelines for learning-disabled people,
   who, the WAI is unable to acknowledge, may never be significantly accommodated online.

   The current drafts are a huge improvement over earlier suggestions,
   but WAI still clings to the notion that “content” can be
   “reviewed” to demonstrate that it is as simply written as
   possible. But write too simply and you may alienate your target
   audience. Here accessibility turns from making sites accessible to
   rewriting your own work — and making you illustrate it.

   Content is written to be no more complex than is necessary
   and/or supplement[ed] with simpler forms of the content.

   • the content has been reviewed, taking into account the
     following strategies for evaluating the complexity of the content,
     applying them as appropriate.

     1. Familiarity of terms and language
        structure

     2. Reasonableness of length and complexity of
        sentences

     3. Coherence of paragraphs (and sensibility
        in length)

     4. Clarity of headings and linked text when
        read out of context

     5. Accuracy and uniqueness of page titles

     6. Care in the use of all-capital letters
        where normal sentence case might increase comprehension

     7. Inclusion of non-text content to
        supplement text for key pages or sections of the site where they felt
        it was appropriate.

8. Backward
   compatibility. There’s only so far back we can go in a
   world where nearly everyone uses a Version 5–or-later browser
   and authors are writing valid HTML and CSS, which are themselves
   supposed to be compatible across browsers and devices.

   As ever, there’s much discussion of people with outdated
   technology, which is an accessibility issue in a sense other than
   those within WAI’s purview. Everybody else has to upgrade; why
   are people with disabilities exempt? Should standards-compliant
   progress on the web be hindered because someone somewhere might be
   using an old screen reader?

   Nor is there any understanding of the new and more valuable concept
   of progressive enhancement — using
   baseline HTML and CSS to be compatible with any compliant device, but
   adding features that more-sophisticated devices can use.

   Benefits of determining and documenting baseline user agent
   requirements:

   • Individuals can identify (either through site
     documentation or automatically through metadata) whether or not they
     are likely to be able to use a site. In conjunction with a search
     engine or a proxy server, this could be used to automatically filter
     out sites a user cannot access or to automatically filter to the top
     sites that would be most usable.

   • Requiring sites to document their baseline will
     cause them to evaluate assumptions about user agents and will
     minimize the number of sites that are inadvertently inaccessible
     because they are unaware of backward compatibility issues.

   Benefits of designing for backward
   compatibility:

   • Individuals who must use alternative browsing
     technologies and devices will be able to access the content.

   • Individuals who cannot afford or otherwise do not
     have access to newer technologies also benefit from backward
     compatibility in that they will not need to purchase upgrades or
     equipment as often.

Next to impossible#section11

The Web Accessibility Initiative publishes the following draft
guidelines even though they are actually or nearly impossible to
implement. Here we need you to provide technical explanations, which
WAI members should have been able to come up with themselves but have
not. Or you could nominate examples from the real world and explore
how difficult it would be to apply the guidelines to them.

1. “Collating” a “script” of audio descriptions
   and captions has been done exactly once in recorded memory —
   for a demonstration project that is not documented online. It is
   impossible in practice due to the lack of interchange formats for
   captioning, audio description, and related fields. Nor are there that
   many examples of multimedia that are captioned and
   described. It’s even rare, when you consider the full range of
   TV programs and movies, to find both captioning and description in
   those well-established fields.

   Live captioning is extraordinarily difficult for online media (nearly
   impossible using standards-compliant code), while live description
   has been attempted a mere five times in the broadcast sphere.
   Meanwhile, of course captions require you to read and watch
   at the same time. This isn’t telepathy.

   1. a text document that merges all audio descriptions and
      captions into a collated script (that provides dialog, important
      sounds and important visual information in a single text document) is
      provided.

   2. captions and audio descriptions are provided for all live
      broadcasts which provide the same information.

   3. the presentation does not require the user to read
      captions and the visual presentation simultaneously in order to
      understand the content.

2. It’s impossible to write a stylesheet that detects
   the size and colour capabilities of a display and serves
   different commands as a result. Almost nobody uses black-and-white
   displays; audio stylesheets are effectively unsupported, and stereo
   audio is the norm. The guideline also apparently requires
   stylesheet-switchers on each and every site. The concept of
   “vary[ing] the emphasis of the structure” is rather hard
   to understand, unless it means making certain elements invisible or
   yet other elements render in 96-point type.

   1. The structural emphases are chosen to be distinct on
      different major visual display types (e.g. black and white, small
      display, mono audio playback).

   2. Content is constructed such that users can control the
      presentation of the structural elements.

   3. Alternate presentation formats are available to vary the
      emphasis of the structure.

3. This guideline,
   intended to help dyslexics and others with related learning
   disabilities, presupposes a Windows-style combo box (drop-down list
   plus type-in field). It would also require you to spell-check every
   input ever made on your website. That would seem to be the
   visitor’s responsibility, and it’s already
   possible.

   1. Where possible, the user is allowed to select from a list
      of options as well as to generate input text directly.

   2. Errors are identified specifically and suggestions for
      correction are provided where possible.

   3. Checks for misspelled words are applied and correct
      spellings are suggested when text entry is required.

Not our problem#section12

The Web Accessibility Initiative’s Web Content
Accessibility Guidelines are intended “to make web content
accessible to people with disabilities.” Yet these proposed
guidelines for WCAG 2.0 extend well beyond web content into unrelated
technical fields and, indeed, the mind of the author.

Here your contribution can be an expert opinion on how the proposed
guideline would apply to your site. Would you fail, pass, or fall
somewhere in between? Would it even be possible for you to assess
whether or not you comply? How would a Web Content
Accessibility Guideline such as this affect your web development?

1. Do you want the Web Accessibility Initiative dictating to you how
   “complex” or “unfamiliar” your content might
   be, or even whether it might be complex at all? If using data tables,
   won’t you already be using correct table markup?

   Content is considered complex if the
   relationships between pieces of information are not easy to figure
   out. If the presentation of the information is intended to highlight
   trends or relationships between concepts, these should be explicitly
   stated in the summary.

   Examples of complex information:

   • Data tables,

   • Concepts that are esoteric or
     difficult to understand,

   • Content that involves several
     layers.

   unfamiliar content

   Content might be unfamiliar if
   you are using terms specific to a particular community.

2. Abbreviations
   and acronyms are a problem that may never be satisfactorily
   resolved, at least not until screen readers — the main sticking
   point here — are upgraded to handle them better. Meanwhile, the
   discussion of diacritic marks is an attempt to force authors to write
   Arabic and Hebrew with the vowel markings that are generally deleted
   in adult-level writing — again all because screen readers
   cannot handle the writing system as grownups use it.

   1. Abbreviations and acronyms are clearly identified each
      time they occur.

   2. Symbols such as diacritic marks that are found in standard
      usage of the natural language of the content, and that are necessary
      for unambiguous identification of words, are present or another
      standard mechanism for disambiguation is provided.

How to contribute#section13

• If you have anything to contribute to the WCAG 2.0
  development process, you can post a message to the WAI-GL mailing
  list (wai-gl at lists.w3.org).
• You’re also requested to post to
  another list, public-comments-wcag20 at w3.org.
• Both lists have archives on the web (WAI-GL, Public-Comments).
• There’s also a Bugzilla implementation for
  WCAG, though you’re not allowed to
  “discuss” issues there.
• WCAG holds a few “f2f” meetings each year; the next is in Tokyo.
• I certainly encourage you to publish comments on your own
  weblogs, with links sent along to the mailing lists. That will get
  the message out to more readers, and also put a bit more public
  pressure on the Web Accessibility Initiative to create better
  guidelines.