- From: John Foliot <jfoliot@stanford.edu>
- Date: Sat, 5 Jun 2010 20:39:09 -0700 (PDT)
- To: "'Laura Carlson'" <laura.lee.carlson@gmail.com>
- Cc: "'Shelley Powers'" <shelleyp@burningbird.net>, "'HTML Accessibility Task Force'" <public-html-a11y@w3.org>
[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