- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Sat, 5 Jun 2010 03:23:04 -0500
- To: John Foliot <jfoliot@stanford.edu>
- Cc: Shelley Powers <shelleyp@burningbird.net>, HTML WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi John, Shelley wrote: >> I appreciate her effort, but I believe that Sam has shut down the >> discussion, which is a co-chair prerogative. I'm waiting resolution on >> several change proposals before I determine my next steps. John wrote: > I don't think the chairs (Sam) has shut down any discussion at all - he has > clearly given all a 'next-steps' roadmap that actually has two options - > file bug reports with specific actionable items, as well as leaving the door > open to a Formal Objection (with an apparent preference for bug reports > first). Thanks. I hope people have the time and the wisdom to do what is best. Creating elements that are inherently accessible, that provide accessibility from the get-go, with no additional work by the author is could be a win for accessibility. A mechanism to provide a native aside element ala the WAI-ARIA "complimentary" landmark role is a good idea. It could be applied to an area containing associated content. In the counter change proposal it says that the aside element "expresses this semantic directly in the markup, allowing other types of UAs to give their users similar ability to skip over irrelevant content and return to it at their leisure". Do you think HTML5 specifies how devices are to interact with aside and skip the content clearly enough? Do you see any flaws in the specification of the aside element? Do you (or anyone else) see any ways in which the aside element should be improved in HTML5? Or do you consider it okay as is? In regards to the figure/figcaption elements, there is no doubt that a mechanism to explicitly provide a caption for an image is a good idea. Do you think that the figure/figcaption elements are specified correctly? The majority of style guides disallow tables as content for a figure. But HTML5 does not. It allows any flow content in the figure element not just images. Do you think this present any problems? Do you anticipate nesting a table into figure causing any problems? Do you see any issues existing with a figcaption + table caption scenario? A table caption is read by JAWS. Do you foresee a figcaption to be read in the same way? When a table element is the only content in a figure element other than the figcaption, the spec says that the caption element should be omitted in favor of the figcaption do you think this is speced correctly? Do you think that multiple tables in a figure element would be read correctly? It seems that they should linearize, do you think would that they would? The spec does not define how the figure is associated with the original content. The counter proposal states, "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." The spec does not say devices should have the ability to skip over the figures, and return later, do you think that would be useful? The figure element could be located outside of an article; it could be located in another part of the web page, even another web page. It is not specified how a connection between this physically separated element is relate back to the original article element. Do you think that the spec should specify how this is to be accomplished or anything in this regards? Do you (or anyone else) see any ways in which the figure element should be improved in HTML5? Or do you consider the element okay as is? Thanks. Kindest regards, Laura -- Laura L. Carlson
Received on Saturday, 5 June 2010 08:50:38 UTC