Re: aside and figure elements

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