- From: Jonas Sicking <jonas@sicking.cc>
- Date: Thu, 1 Apr 2010 03:12:22 -0700
- To: Shelley Powers <shelley.just@gmail.com>
- Cc: HTMLWG WG <public-html@w3.org>
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