Re: ISSUE-96 Change Proposal

On Thu, Apr 1, 2010 at 4:12 AM, Jonas Sicking <jonas@sicking.cc> wrote:
> 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.
>


My argument was focused on accessibility because the editor's
rationale for the element was based entirely on accessibility. Steve
Faulkner did provide a presentation on some of the new HTML5
declarative entities, such as date picker, color picker, and so on,
but I couldn't find it again. Otherwise, I would link it, because it
was an excellent presentation.

The point he made in it was to compare what we have today with what
these new elements bring, in Opera I believe it was, and that we're
creating something that can never hope to reach the potential of the
state of the art we have today.

And progress does require JavaScript, and chances are, whoever would
need a progress bar, and know how to use it correctly, is more likely
going to using whatever is built into the library they're using, such
as jQuery, Dojo, Mootools, and so on.

In my opinion, this is a bad direction to take across the board.  Do
we really want to disregard the strides we've made with JavaScript and
CSS and start creating declarative elements? Especially in an
environment that is not set up for declarative elements or animations?

The progress bar is also one I don't think the web developer community
has asked for. We're "giving" it to them, whether they want it or not.
That's not a "frugal" attitude to have, and this group should be
frugal when it comes to adding new elements.

I believe I found the original request [1], and the person asking for
it, misses an important point he made in his email being able to "turn
things off". Another point he made was that somehow it's good to have
one that looks the same for all sites on the same operating system.
That we shouldn't just allow everyone to come up with their own.

If we're 'allowing' people to come up with their own web designs, why
not a progress bar that matches the web site, rather than the
operating system? I personally don't want the browser companies and OS
to dictate what my page looks like.

More importantly, that's where this element derived from -- a casual
discussion, not based on anyone with any need, just a case of "why not
have this?" How many of the new elements arose because of such casual
discussions like this?

Creating new elements is a significant burden on web
developer/designer tools, especially something like an HTML editor,
which has to make room in its tool bars for yet more HTML elements, as
well as providing testing functionality. Then there's the libraries
that have to support it (oh, right, there isn't any), or that won't,
or that now have to provide their existing UI progress bar, and this
new element.

We designed an architecture, and it's a darn good architecture, for
the web years ago. Not just the W3C, either. Different technologies
for different domains means we don't have to create single purposed
elements, or wait for new versions of specifications in order to
innovate. We have CSS for styling, JavaScript for behavior, RDFa and
Microformats (and now Microdata) for semantics, HTML for structure,
now joined by ARIA for accessibility. Throw in canvas and SVG, and the
new 3D APIs, as well as video and audio, and there's really nothing we
can't create. Nothing.

Why, then, create an element that welds behavior, style, and
structure? Why? It makes no sense at all. As for it being accessible,
only when folks convince the screen reader companies that they now
have to support this progress element IN ADDITION TO ARIA. That will
go over well.

Anyway, I based my change proposal on the editor's rationale, and all
he gave was progress was important for accessibility, and I
demonstrated that it wasn't necessary for accessibility. If he wants
to expand his rationale, or others provide additional rationales, I'll
update my change proposal accordingly.

> / Jonas
>

Shelley

[1] http://lists.whatwg.org/htdig.cgi/whatwg-whatwg.org/2004-September/002211.html

Received on Thursday, 1 April 2010 13:04:41 UTC