Re: Removal of other semantic elements

Hi Steven,

Thanks for your response, comments in detail below. However I note
that you didn't actually answer my question. The question is, what are
your feelings regarding the various issues and change proposals to
remove various specific semantic elements and attributes from HTML5?:

ISSUE-90 - Remove <figure> element
ISSUE-91 - Remove <aside> element
ISSUE-93 - Remove <details> element
ISSUE-95 - Remove hidden=  attribute
ISSUE-96 - Remove <progress> element
ISSUE-97 - Remove <meter> element


On Sun, Apr 4, 2010 at 1:17 PM, Steven Faulkner
<faulkner.steve@gmail.com> wrote:
> hi Jonas,
>
> If new interactive elements such as form controls are included in the
> spec, I would hope that they are implemented in browsers to be
> accessible to people with disabilities, as yet that has not occurred.
> I don't think that the spec currently provides detailed advice or
> requirements on how accessible implementations are to be achieved, I
> am unsure the HTML5 spec is necessarily the place for this
> information.

I 100% agree that implementations of the various new interactive
elements need to be made accessible. I would go further and say that
non-interactive elements, such as <nav> and <header>, should also be
exposed to AT.

And I wouldn't mind putting requirements about this into the HTML5
spec. However I have no idea how such requirements would be written.
(And obviously, I couldn't commit support until I've seen an actual
proposal).

However I don't think that it will matter much one way or another if
the spec mandates that these things should be exposed to AT tools. The
fact that some implementations don't yet do that I strongly suspect is
due to simply not having had time to implement that yet (i.e.
engineering resource limitations), rather than lack of caring or
understanding that that needs to be done.

> Even when all the elements in HTML5 are supported by browsers and AT,
> there will still be an important place for ARIA in HTML5, as there are
> many features of ARIA that plug gaps in HTML5 one example is "live
> regions" another is landmark roles and another is the many roles
> provided in ARIA that do not have a corresponding HTML5 element or
> attribute. (e.g.s alert, dialog, scrollbar, status, tab, tabpanel,
> tooltip, treeitem etc)
>
> Furthermore, until native controls of any type are styleable to suit
> developers desires, they will continue to just make things out of
> elements that suit their visual styling needs and so many natively
> available controls will still not be used in some situations, as
> developers will prefer custom controls. Again, in these cases ARIA
> makes the difference between a control being usable or not by people
> with disabilities.
>
> Even when ALL elements are stylable to suit developers needs, they
> will still create custom controls that are not part of HTML5's tool
> set, so again ARIA will be useful in helping to make these controls
> understandable for AT users.
>
> I don't see any friction between ARIA vs native features, the friction
> is between custom UI libraries vs native features.
> I don't have a strong opinion on the correctness of using one over the other.
> if the native feature suits the developers needs use it over an ARIA
> enabled custom control, if not use ARIA enabled custom controls. If
> the native controls are not accessible use ARIA enabled javascript UI
> controls that are. If native features are missing or not optimized to
> provide the most useful information use ARIA to augment the
> accessibility information provided.

Agreed 100%. I don't think anyone has argued that ARIA is not
important, or that HTML5 should stop supporting it. That is not the
issue at debate at all.

And I agree that sites are likely to not want to use many of the new
elements/controls in HTML5 until they can style them to satisfaction.

/ Jonas


> On 2 April 2010 20:24, Jonas Sicking <jonas@sicking.cc> wrote:
>> On Thu, Apr 1, 2010 at 12:40 PM, Maciej Stachowiak <mjs@apple.com> wrote:
>>>
>>> On Apr 1, 2010, at 12:01 PM, Shelley Powers wrote:
>>>
>>>> This discussion is become circular, evidently most people disagree
>>>> with me. That's fine. I don't agree, but will take my arguments
>>>> elsewhere.
>>>>
>>>> Most of my proposals were about removing these so-called "semantic
>>>> elements". If the co-chairs want to close these proposals, since no
>>>> one agrees with me, that's fine too.
>>>
>>> The Chairs are very much interested in seeing the level of support or
>>> opposition for this proposal, and the other similar proposals for removing
>>> elements. That would be useful feedback for determining the next action.
>>>
>>> So far, my read on this discussion is that a number of people disagree with
>>> the proposal, some have expressed concerns without taking a firm stance, and
>>> no one besides Shelley has voiced support. So far, I have not seen direct
>>> comments on the other proposals.
>>>
>>> We will be monitoring the ongoing discussion.
>>
>> To be clear, I feel the same way about the change proposals for
>> ISSUE-90, ISSUE-91, ISSUE-93, ISSUE-95 and ISSUE-97 as I do for
>> ISSUE-96. I.e. that removing semantic elements and attributes is bad
>> for accessibility, even when ARIA can be used to add similar or
>> equivalent semantic meaning.
>>
>> I'm definitely interested to hear what people with more accessibility
>> related experience than me think about this.
>>
>> I believe Steven Faulkner said that he didn't want any other
>> "controls" removed from the spec, which I would take to encompass at
>> least ISSUE-97. But I'm interested to hear his and others feelings
>> regarding the other change proposals too.
>>
>> / Jonas
>>
>>
>
>
>
> --
> 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, 5 April 2010 01:27:52 UTC