- From: Laura Carlson <laura.lee.carlson@gmail.com>
- Date: Sun, 6 Jun 2010 14:21:10 -0500
- To: Shelley Powers <shelleyp@burningbird.net>, Steve Faulkner <sfaulkner@paciellogroup.com>
- Cc: HTML WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
Hi Shelley, > I'm not sure how the accessibility API mapping would work, though I've > seen the spec that provides User Agent instructions. However, from a > ARIA to element mapping perspective, I'm not sure how figure and aside > would map. There is an ARIA mapping subgroup in the accessibility task force. I think Steve heading that group. Steve, has the ARIA mapping group discussed the aside or figure elements? Thanks. Best Regards, Laura On 6/6/10, Shelley Powers <shelleyp@burningbird.net> wrote: > > Laura Carlson wrote: >> 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? >> >> > > Not part of the group, but I wanted to respond to this question, and > also explain why I said neither is accessible. Thanks for cc'ing me on > the email, Laura. > > Some time back when we were discussing all of the new elements, I made a > statement that so many new elements are going to be a burden on AT > devices, too. At that time, one of the group members stated that rather > than AT devices having to learn the new elements, such as "figure" and > "aside", each would be mapped to the existing accessibility API by the > browser companies, so they would be accessible "out of the box". > > This made a lot of sense to me, and is the reason I didn't include the > elements being an additional burden on AT devices as an objection to > figure and aside. > > However, seems to me for this to work, this accessibility mapping needs > to be stated. Otherwise, each browser vendor could map the elements > differently. Now, perhaps another spec is the place, but I would think > that the HTML5 spec would be the better place, since it is the spec that > originated the elements. > > I'm not sure how the accessibility API mapping would work, though I've > seen the spec that provides User Agent instructions. However, from a > ARIA to element mapping perspective, I'm not sure how figure and aside > would map. For instance, if aside is treated as a typographical sidebar > or note, there is an ARIA role of note that fits this use. However, if > aside is treated as a web page sidebar, the more appropriate role is > complementary. The two are not the same in ARIA, so we have to assume > the two are not the same in the accessibility API, either. > > So, in my opinion, I don't believe aside, as currently defined in the > HTML5 spec, is accessible. I'm not an accessibility expert, though. > Perhaps the experts don't see this as a problem. > > Figure is another issue, as you have also noted. If figure really were > captioning for a graphic, I think there could be a clean accessibility > mapping, but because figure can include most anything, you start to have > some interesting issues. > > And figures really aren't meant to be 'skipped' typographically. They're > actually an important part of the content, but are managed differently > because larger images may not fit well where they are needed within > printed material. When people say, "See Figure ..." they really mean for > folks to look at that figure -- it's complementary to the text. It > clarifies and expands on the text. It's never meant to be skipped. > > I'm not sure how figure got redefined to something that can be skipped. > From an accessibility perspective, though, if it's managed as something > that can be easily skipped, those needing this functionality may end up > with a less than ideal experience. They may actually _lose_ important > information. > > In my read of the HTML5 spec, I don't see anything addressing these > issues. I imagine this could be covered in another spec, but there's > nothing detailing this, or providing a plan. > > Anyway, your questions are good. I failed to get the elements removed, > and am concerned that this failure then meant that these elements were > not going to be 'cleaned up'. I should have provided an alternative > change proposal--keep the elements and redefine and clean them up--but I > genuinely believe the ARIA approach to be the better one, and couldn't > support an alternative I felt to be inferior. > >> 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 >> >> > > Shelley > > -- Laura L. Carlson
Received on Sunday, 6 June 2010 19:21:41 UTC