Re: Removal of other semantic elements

On Sun, Apr 4, 2010 at 8:26 PM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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?:

Took this to www-archives, since it's not really relevant to the discussion...

Steve will answer or not, but I'm curious: are you going to ask the
other 419 members of this group their opinion, too?

Steve will do what he wants to do, but I also brought up a list of
other issues specific to the change proposals, as did Laura Carlson.
Will you be answering any of these, or responding to either of us?

I'd rather the discussion be focused on the change proposals, and that
it reflect the new direction established today, with custom UI versus
built-in elements, and Laura's note about separation of presentation,
behavior, and structure.

And I'd hate for people to have to be put on the spot unnecessarily.

Shelley

>
> 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 02:24:42 UTC