Re: ISSUE-96 Change Proposal

On Wed, Mar 31, 2010 at 6:40 AM, Shelley Powers <shelley.just@gmail.com> wrote:
> Addressing the individual types of progress element, beginning with
> the indeterminate: there are indeterminate progress graphics that spin
> and pulse, and twitch about, all with an alt text along the lines of
> "The task is in process", or the like. There is absolutely nothing
> that the indeterminate state of the progress element provides that we
> don't already have, and yes, which is accessible, too. More
> accessible, as there is nothing in the specification about the element
> that specifically addresses accessibility. If we want more, though, we
> can also annotate the progress indicator with WAI-ARIA values, as
> discussed next.

It seems like this change proposal is arguing that we don't need to
add <progress> as it can be marked up using ARIA already (please
correct me if I'm wrong Shelley).

I'd be interested to hear from people better at accessibility than me,
if this is sound reasoning. I.e. is it better to *only* have the
ability to mark up a certain feature using ARIA, or is it better to
build it "natively" in to the HTML language as well?

And, if it's better to leave it up to ARIA, should we then deprecate
elements such as <h1>-<h6> since ARIA has the ability to mark these up
already?

My gut reaction, and to some extent my experience, is that people are
much less likely to create accessible markup if they have to add extra
markup specifically to make it accessible. I.e. many stop once a page
looks correct to the average user, and don't go the extra mile to also
support things like screen readers. Additionally, the ones that do
make the effort to go the extra mile to, often get it wrong either out
of not knowing how to properly add accessibility specific markup, or
because they don't have a screen reader to test with.

So it's more likely that people will mark up a header correctly if we
have a <h1> tag which changes the styling of the marked up section. So
that people can write markup like:

<h1>header</h1>

rather than

<div role=heading aria-level=1>header</div>

My concern is that if people are forced to use the latter, many more
of them will leave out the role and/or aria-level attributes, stick a
class name on it and add some styling.

I'm not arguing here that we should remove anything from ARIA. I
understand that there will always be people that will use the latter
syntax and that there is a desire to support that. However my question
is if it makes sense to have native elements in the language in order
to simplify things for authors and increase the chance that they'll
use accessibility friendly markup, and do so correctly.

I'm curious to hear arguments here purely for the accessibility aspect
of this. I definitely agree that there are other important aspects
here, such as that having duplicate features is generally a bad thing.
No feature is for free.

/ Jonas

Received on Thursday, 1 April 2010 10:13:14 UTC