- From: Shelley Powers <shelley.just@gmail.com>
- Date: Thu, 22 Apr 2010 10:32:40 -0500
- To: HTMLWG WG <public-html@w3.org>
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