- From: Steven Faulkner <faulkner.steve@gmail.com>
- Date: Mon, 7 Jun 2010 11:46:44 +0100
- To: Laura Carlson <laura.lee.carlson@gmail.com>
- Cc: Shelley Powers <shelleyp@burningbird.net>, HTML WG <public-html@w3.org>, HTML Accessibility Task Force <public-html-a11y@w3.org>
PS: the bit about it being passed as a 'string value' is not correct except in the case of UIA Control patterns and sometimes in MSAA/IA2 as implemented in firefox, have a look at the Table describing mapping of WAI-ARIA roles to accessibility APIs. http://www.w3.org/WAI/PF/aria-implementation/#mapping_role which provides useful info about the mappings of aria roles to various accessibility APIs regards stevef On 7 June 2010 11:41, Steven Faulkner <faulkner.steve@gmail.com> wrote: > missed the bit about <aside> > > this would map to ARIA role="complementary", though it should be noted > that that most accessibility APIs don't have a specific role that maps > onto "complementary" and it's role is passed to AT as a string value > or it is ignored (in the case of MSAA). It is then up to AT as to how > they expose this to the user. > > regards > stevef > > > > On 6 June 2010 20:21, Laura Carlson <laura.lee.carlson@gmail.com> wrote: >> 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 >> >> > > > > -- > with regards > > Steve Faulkner > Technical Director - TPG Europe > Director - Web Accessibility Tools Consortium > > www.paciellogroup.com | www.wat-c.org > Web Accessibility Toolbar - > http://www.paciellogroup.com/resources/wat-ie-about.html > -- with regards Steve Faulkner Technical Director - TPG Europe Director - Web Accessibility Tools Consortium www.paciellogroup.com | www.wat-c.org Web Accessibility Toolbar - http://www.paciellogroup.com/resources/wat-ie-about.html
Received on Monday, 7 June 2010 11:15:28 UTC