Re: aside and figure elements

Hi John,

(Re-adding HTMLWG as they may have ideas on the overlapping definition issue.)

> Are you asking the group this question, or is it being directed at me?

I value everyone's input but yours in particular. As you co-authored
the counter proposal, I am sure you have analyzed the spec on these
elements more than most in the group.

Thank you for your comments on the aside element. To sum it up you are
saying <aside> is okay as it is specified. Other specs will handle
accessibility details. Correct?

As soon as you able, I would really appreciate your answers to my
questions and assessment regarding the figure element, which seems
more problematic in itself than the aside element.

Another question, John, do you find the definitions of aside and
figure too close in meaning? Should the definitions be changed? If so
how? The definitions of the aside and figure sound almost identical,
except that figure has a caption. Do you consider the overlapping
definitions problematic? Developers will tend to confuse the two
elements and use them incorrectly. It will present a challenge for
educators to teach the difference. Many times it is not any given
feature that causes problems; it's having too many choices or
overlapping meanings, which adds complexity and leads to confusion.

> 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

Okay. I know far too well what you mean about time.

> I'm going to leave my thoughts as is for now.

Looking forward to your further analysis.

Thanks again.

Best Regards,
Laura

-- 
Laura L. Carlson

On 6/5/10, John Foliot <jfoliot@stanford.edu> wrote:
> [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

-- 
Laura L. Carlson

Received on Sunday, 6 June 2010 09:37:22 UTC