General Response to the Accessibility Task force on Issues 90, 91, 93, 96, 97

The Accessibility TF held a vote and did a blanket rejection of
several separate change proposals--all without discussion in the TF
group, and without splitting the items up so that each may be
considered by their own merit. The Rationale given was:

RATIONALE: The F2F believes these elements are actually useful for
accessibility. We note that features similar to the elements in question
are today created using elements with different semantics actuated by
style and script, whereas we prefer native elements.

Further rationale, seemingly to support this decision is given in the
recent blanket counter-proposal for these issues[2]. I quote what
seems to be the most pertinent part:

"Through the use of declarative markup and tight integration of
accessibility into the application framework, we can produce more
consistent cross-platform solutions which support accessibility and
reduce the enablement efforts of the author."

It's a fine goal. When it comes to existing elements, such as buttons,
text fields, and so on, developers and web authors should be
encouraged to use built-in controls over creating their own with
JavaScript and CSS. However, such a stated direction should not be
used to route around the necessary debate and discussion about the
relative merits of items added into the HTML5 specification. Each
individual item should be weighed and judged on its own merits. If the
item has merit, if its use is, at a minimum, equivalent to what web
authors and developers have access today, it is more likely to be
accepted by the web community, to the benefit of all parties.

However, if the item has little merit, if it is inferior to the state
of the art as it exists today, if web developers and authors can see
no benefit from its use, then no one wins. In fact, people lose,
because each new item in the HTML5 specification has a considerable
cost associated with it. Templates have to be updated, WYSIWYG tools
modified, HTML development applications changed, people have to buy
new books, new tools, learn new items, and so on.

I once asked this group to consider each item on a scale of perceived
costs and benefits. I thought this was a worthy exercise when it comes
to making these decisions. Rather than respond to this discussion
opener, the Accessibility TF fell back on the earlier Direction, this
previously stated Guideline. The items were not discussed
individually, the merits of each were not considered, no cost/benefit
analysis given. There wasn't even a consideration given to the
likelihood of the eventual success of each element within the web
community at large.

Directions, to be effective, should encourage open discussion, not
route around it. Guidelines should be used to enhance decisions, not
be used as an absolute. When guidelines are treated as absolute, they
are no longer guidelines, they are dogma.

As an example of a more in-depth and individual examination of each of
the proposals, let's focus for a moment on one: Issue 90, which
recommends removing the figure element.

In the counter-proposal, we're told:

"Users interacting visually with the article can easily skip past this
content temporarily and avoid interrupting their reading of the main
article, and then return to the content to understand it when they
feel comfortable. Expressing this semantic directly in markup allows
alternative UAs to present their users with the same ability, thus
improving Accessibility. "

Consider, though, that there is absolutely nothing in the HTML5
specification that provides any interpretation of how this element is
to be accessible or how AT devices are to render it--other than a
vague indication that they should give those using AT devices the same
ability to skip over the item, and return later.

Yet at the same time, the counter-proposal and the HTML5 spec state
that this item could be located outside of the article; it can be
located in another part of the web page, even another web page. But
there's nothing in the specification for this element that describes
how a connection between this physically separated element is supposed
to be related back to the original article. Are they linked? Are we
supposed to use ARIA to map a connection? But aren't the built-in
elements a replacement for ARIA?

>From the counter-proposal description of figure:

"The element can thus be used to annotate illustrations, diagrams,
photos, code listings, etc, that are referred to from the main content
of the document, but that could, without affecting the flow of the
document, be moved away from that primary content, e.g. to the side of
the page, to dedicated pages, or to an appendix."

Again, there's nothing in this to tell us how we associate the figure
with the original content. If we use a hypertext link, we can use the
same link today, and we don't need a new element. Figure offers
nothing new from any perspective, much less an accessibility
perspective. It is "something with a caption", and could easily and
effectively have been represented by a caption attribute. We already
have caption attribute capability in ARIA, with the aria-labelledby
attribute. The accessibility community has been presented an excellent
opportunity to demonstrate that not only is ARIA for the community of
AT users, it provides rendering semantics applicable to all web
communities. Rather than ARIA being a "burden" on web developers and
authors, it can be an asset.

Instead, we have the figure element, which is now, "something with a
caption that may or may not be semantically linked with the content it
illustrates".

Let's return, for a moment, to the content of figure being "skipped
over". The concept of a figure, and supposedly the semantics of
figure, comes from the print world. Yet, figures in books and
magazines are not meant to be "skipped over". In fact, they are an
integral part of the discussion. However, because of print
limitations, figure placement can't always occur where it is most
relevant to the discussion, so there's an association between a figure
reference (See Figure 1.1 for more on ...) and the caption associated
with the figure. This association prevents confusion about which
illustration is associated with which aspect of the written
discussion.

This works in the print world, because print books are linear and have
no hypertext links. It's essential in the print world because of
physical constraints associated with the medium. The element's use,
though, in a web context is not as clear -- there are no physical
limitations to how material can be related to other material in web
pages. There is no guarantee that the material will be read linearly.
Tangential associations are an underlying principle in the web world,
where they are an obstacle to overcome in the print world.

Look at the over-broad definition of what can be allowed as a figure:
data tables, code listings, illustrations, poems, paragraphs...there's
no limit, other than "flow content", to what a figure element can
contain.

Now, visually, we can glance quickly at the item and tell if it's
something we can easily skip over without impacting on the content of
the article. Non-visually, though, the individual will have no idea
what this element contains, and whether they want to skip over it or
not. If the element contains a data table, with data that supports an
assertion in the text, do we really want to encourage AT devices to
give people an option to "skip" over the content?

If the element contains a poem, and the discussion is about a poet, is
it truly meaningful to "skip" over the poem? If the content is code
that is the focus of the article, do we want to skip the code? In
point of fact, illustrations are rarely meant to be skipped
over--that's why they're called "illustrations". They illustrate a
point, they help clarify, add meaning, provide an alternative
viewpoint.

We can say all we want that people shouldn't use figure in these
circumstances. But people are going to want "something with a
caption". Since we've not provided anything else, they will use
figure. The potential for misuse is enormous -- and no amount of
finger wagging in the spec will prevent such misuse. Especially when
the spec is so vague in the definition of the element.

In addition, in many cases when figures are used in books, articles,
and other publications, references back to the figure are typically
included in the discussion following the first figure reference, which
means then that the AT device user will have to "back up" in order to
peek into the element to determine if it's important to the discussion
or not.

So, now we have content that not only is "something with a caption
that may or may not be semantically linked with the content it
illustrates", but it's "something with a caption that may, or may not,
be semantically linked with the content it illustrates, and may, or
may not, be important to the discussion".

The original request for figure was for some way to associate a
caption with an img element. It has now morphed into a less than
useful semantic mud puddle. The only reason I can see that the figure
element is defined the way it is in the HTML5 spec is lack of
familiarity with the concept of figure in the print world. The current
spec definition for figure is nothing more than misunderstanding,
given structure. And if the editor of the HTML5 spec misunderstands
the concept of "figure", now much more so will it be misunderstood in
the broader web community?

Rather than aid accessibility, figure has the real potential to be
directly harmful to accessibility. It is nothing more than "something
with a caption, which may or may not be semantically linked with the
content it illustrates, which may or may not be important to this
discussion". Now, how do you render that successfully in AT devices?

Shelley

[1] http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0183.html
[2] http://www.w3.org/html/wg/wiki/ChangeProposals/KeepNewElements

Received on Thursday, 22 April 2010 15:33:14 UTC