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

Hi Laura,

It was agreed during the teleconference this morning that the TF would come back to Shelley to explain to her these issues WERE discussed in the F2F meeting that took place a few days/weeks ago.

It is my understanding that it was agreed her mail would be handled accordingly: we do not want her to get the wrong impression, what she proposed WAS discussed it's just that it may not have been recorded as it usually is because of the context in which these discussions took place (face to face meeting).

I believe somebody was assigned to it. Didn't get the name though.

Regards,

/Denis


On 2010-04-22, at 12:21 PM, Laura Carlson wrote:

> Hello everyone,
> 
> Shelley has responded [1] on the HTML list and asked questions,
> regarding the Task Force blanket resolution [2] on her six change
> proposals. The resolution said that the TF would maintain a work item
> to check these elements and make them better. Who will be working on
> this? Answering Shelley's message might be a good place to start.
> 
> Thanks.
> 
> Best Regards,
> Laura
> 
> [1] http://lists.w3.org/Archives/Public/public-html/2010Apr/1111.html
> [2] http://lists.w3.org/Archives/Public/public-html-a11y/2010Apr/0183.html
> 
> -- Forwarded message --
> From: Shelley Powers <shelley.just@gmail.com>
> Date: Thu, 22 Apr 2010 10:32:40 -0500
> Subject: General Response to the Accessibility Task force on Issues
> 90, 91,  93, 96, 97
> 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
> 
> -- End forwarded message --
> 
> 
> -- 
> Laura L. Carlson
>

Received on Thursday, 22 April 2010 16:28:56 UTC