Re: Removal of other semantic elements

On Sun, Apr 4, 2010 at 3: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.
>
> 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.


Steve's response is a better way to frame this discussion. I thank him
for adding clarity to the discussion, and helping to refocus the
discussion (and also remind me what are my primary concerns).

My change proposals primarily responded from an accessibility
perspective because that's how the HTML5 editor styled his rationales
for rejection--based purely on accessibility. I demonstrated that the
elements in question aren't _necessary_ for accessibility, because
ARIA provides an alternative. My demonstration basically refuted his
rationale that these elements were _essential_ to accessibility in
HTML5.

The discussion unfortunately went off on a tangent related to native
element versus ARIA. I will admit to playing some part in this,
because I was surprised that the accessibility community considers
ARIA to be a stop gap, because I find it to be a wonderfully elegant
solution.

However, as Steve has pointed out, ARIA compared to native element
isn't really the issue. The issue is custom UI libraries versus native
features. I did discuss this also in the change proposals, but it
didn't form the basis of the arguments. Perhaps I should have focused
on this more, but again, I was responding to the HTML5 editor.

Would it help if I edited the change proposal to put more of the
emphasis on custom UI libraries as compared to native elements?

I would have to incorporate some of the issues related to
accessibility into the discussion, as Steve has just pointed out, but
I could hopefully do so in such a way that the change proposals are no
longer being framed as "ARIA against native element". This really
wasn't may _main_ concern, as long as ARIA continues to be supported.

It would help if I had arguments specific to custom UI libraries
versus native elements other than the ones that Ian provided, because
I'm having to guess what these are. Would it be better to wait until
counter-proposals and then edit my proposals accordingly?

I don't want to waste the group's time, but I'm not sure that all of
the arguments I've given in my proposals have been given due
consideration, because of the "ARIA versus native element" tangent.
Which I apologize for aiding and abetting.

> with regards
> Stevef
>

Shelley

>

>
> 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 Sunday, 4 April 2010 21:27:42 UTC