WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Headings

for

From: John Foliot
Date: Dec 23, 2009 9:24PM

Wayne Dick wrote:
>
> It is not easy reading, but developers read all
> kinds of other technical references without
> blinking. It is no harder or easier to learn WCAG
> 2.0 than it is to learn Flash, Ajax or XML. If
> your are going to develop accessible content, you
> need to understand accessibility at that technical
> level. It's an important technical part of being a
> competent modern developer.

While I cannot disagree with Wayne, understanding the technical
requirements and techniques is but one part of accessible web design:
understanding the needs and ramifications of the developer choices (and
user expectations and user-experience) are equally if not more important.
The one thing that WCAG2 grappled with and I believe has addressed is the
need to avoid a menu of tick-boxes that result in technical 'conformance'
while at the same time creating a poor user experience for the audience
that the tick-boxes seeks to address - the single largest shortcoming with
the now dated Section 508 spec. Many of us have encountered the
proto-typical page that meets all the ticks but is still inaccessible.

For example, if a web sites pages have a 'skip nav' link, immediately
followed by a persistent unordered list of links, and that list also has
the ARIA landmark role="navigation" then one really needs to ask whether
adding an <h2>Navigation</h2> is truly needed. Some might suggest yes,
but other would argue no - it is not a clear-cut 'tick-box' decision or
discussion. The real question that needs to be asked is: is this
navigation block easily discoverable, and does the user-experience
facilitate (or at least accommodate) non-visual users? Other factors, such
as design considerations must also be addressed and accounted for; boxing
ourselves into a series of "must does" can harm the larger goal, as less
informed developers will simply abandon all accessibility techniques if
they are seen as too restrictive.

So yes, understand the technical but also 'human' requirements, and inform
yourselves of the different existing success techniques; but at the same
time do not fear to try new implementations and techniques (backed with
appropriate user-testing) and if you come up with something new, by all
means share it back to the WAI Success Criteria Techniques documents. The
W3C has provided a means of doing just that via the form found at:
http://www.w3.org/WAI/GL/WCAG20/TECHS-SUBMIT/

From that page:

When submitting a technique, please be sure that you check it against the
following list:

1. The write-up follows the instructions and guidelines [provided] for
each section.
2. The write-up does not include the words "required," "must," or
"shall."
3. The technique is written to be descriptive, not imperative. That is,
the sentences say "with this technique you xyz" not "do xyz". The only
exception to this is the tests section, where the steps in the procedure
should be imperative.
4. No comment about sufficiency or advisory, etc. should be in the
technique document. Again, the information should be at the Understanding
WCAG 2.0 level instead. There are several reasons for this. First, it is
confusing to say that the technique is sufficient for a success criteria
for one technique but the same technique is not sufficient for another
(because it might only be sufficient to use a combination of techniques).
Also, some techniques may be sufficient in one place and advisory in
another. Finally, you can end up with something where the techniques
document differs from the understanding document which makes it difficult
for people to review and to make sure they have things correct when the
information is in multiple places and is not exactly the same.

Cheers and Seasons Best,

JF