RE: aside and figure elements

[HTML WG mailing list trimmed from this response]

Laura Carlson wrote:
>
>
> 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?

Hi Laura,

Are you asking the group this question, or is it being directed at me?  I 
hope that others will weigh in here as well, but here goes:

First, I preface this as being personal thoughts/opinions at this time, and 
seek to encourage further discussion, not to suggest that they are 
definitive answers to your excellent questions.

I believe being overly prescriptive in the HTML5 Specification in terms of 
how 'devices' should behave is a recipe for problems, as we cannot 
anticipate how current (and more importantly) future user agents manifest, 
nor do I think it is up to us to tell anyone how to do things too 
specifically - we should describe intent and leave specifics to software and 
platforms to develop native solutions that work for their circumstances - we 
know what the 'need' is, deliver please. So the better question is: have we 
adequately defined what we are asking for?

I suspect for example that how <aside> is dealt with on a mobile device such 
as a phone could be different than on a large screen monitor - or maybe not. 
In some ways, it could/should also be a user-setting - allowing a user to 
define how to handle content such as this, but again this is not something 
that 'authors' of content should overly concern themselves with in any 
significant fashion - if the content meets the criteria of information that 
is suitable to be marked as <aside> do so: the physical on-screen rendering 
can then be handed off to CSS and perhaps even JavaScript - you know, the 
3-legged stool <grin>.

I am also a tad concerned that this is yet again becoming a "screen-reader" 
discussion, which does a disservice to other types of disabilities - I am 
thinking here for example that having an <aside> could be a benefit for 
those with cognitive issues. I am sure you are familiar with tools such as 
Read & Write Gold 
(http://www.enablemart.com/Catalog/Writing/Read-Write-GOLD), a system 
toolbar which provides a 'highlighting' of text that is being read aloud, a 
huge benefit for those with learning disabilities, English as a second 
language, etc. Tools such as this could be programmed to also provide a 
similar move-out-of-flow (or put focus on) functionality of <aside> content. 
It could also be something as simple as alternative user style sheets or 
services such as Arc 90's "Readability" tool 
(http://lab.arc90.com/experiments/readability/), so I think we need to keep 
these thoughts close at hand as well. These new elements can be beneficial 
to more than just screen-readers!

However, yes, screen-readers stand to benefit from <aside> significantly, 
and so helping define how screen-readers could handle this element is likely 
a prudent idea.  Screen-readers can already 'skip over' block level elements 
today, so I suspect if I were developing a screen-reader I would likely 
start with that as a default behavior with the addition of some form of 
notification that the tool was doing so at the time of the 'skipping' - 
perhaps a tonal alert or something similar - as well as a means to place 
focus/re-focus on that block level item on demand? (I haven't really thought 
about how to handle this with multiple <aside>s in one document - perhaps a 
menu selection mechanism if/when required...) However, I would also likely 
ensure that this behavior could be toggled on/off, or programmed/modified to 
behave differently - I am not a daily screen-reader user so to folks on this 
list who are, am I off the mark here?

I think as well that we are managing to shift the accessibility 
explanations/requirements out of the HTML5 spec and over to WCAG/UAWG/AUWG 
successfully these days: Steve Faulkner's FPWD on authoring alt text being 
an excellent example, as well as the current proposal regarding how to deal 
with missing @alt with the validators. So as a general thought, I would 
suggest that we continue to encourage this trend and leave overly specific 
'behavior' (especially when it comes to accessibility) out of the HTML5 
draft. It seems that in many ways what you are asking is a question for UAWG 
as much as anyone else (Jim, Kelly, Markku, Jean and Co. - you can thank me 
later...)

Laura, I don't want to seem like I'm ducking your questions, but tonight I 
have a Media sub-group survey that I need to get back to and lately the 
cycles I have available for HTML5 work needs to be focused in that area, so 
I'm going to leave my thoughts as is for now. Hopefully however others will 
chime in as well, and perhaps some others will take up the questions and 
articulate fuller/better answers than I.

Cheers!

JF

Received on Sunday, 6 June 2010 03:40:17 UTC