[Bug 8552] Remove the Progress Element

http://www.w3.org/Bugs/Public/show_bug.cgi?id=8552





--- Comment #5 from Shelley Powers <shelleyp@burningbird.net>  2009-12-27 02:02:34 ---

> > 
> > In addition, there's nothing about accessibility associated with the
> > description of the progress bar. In fact, there's an implicit assumption of a
> > visual association between progress and task that actually makes it vaguely
> > inaccessible. 
> 
> 
> This section describes in detail how the progress element's built-in behavior
> maps automatically to ARIA:
> 
> http://dev.w3.org/html5/spec/Overview.html#annotations-for-assistive-technology-products-aria
>

And this example shows how the ARIA roles can be applied to existing elements,
they're not specific to having a new element.

http://www.mozilla.org/access/dhtml/progressbar

> > 
> > Currently now, if we use images of some form to indicate specific progress, we
> > can use alt text and other techniques (such as RDF or RDFa in SVG) to provide a
> > textual description of the progress. 
> > 
> > In addition, there's nothing about the element description that indicates it
> > provides a platform specific visual element.
> 
> http://dev.w3.org/html5/spec/Overview.html#the-progress-element-0 
> 
> "User agents are expected to use a presentation consistent with platform
> conventions for progress bars. In particular, user agents are expected to use
> different presentations for determinate and indeterminate progress bars. User
> agents are also expected to vary the presentation based on the dimensions of
> the element."
>

That's mighty vague. And again, I don't think it's necessarily a valid approach
for web applications. Do web designers want a platform specific visual display,
or one that's consistent across all platforms? The latter has traditionally
been the favored approach with web pages and web applications. 


> > And since we're talking the web, I'm not sure a progress meter visually needs to reflect the OS.
> > I would think that web page designers would prefer a platform agnostic visual effect.
> 
> As with other elements that are typically rendered as UI controls, I think the
> default rendering should match the platform, but styling should be able to
> override to give a custom appearance. That gives Web developers the choice.
> Some Web developers prefer a custom look for all controls, while others prefer
> a platform-native appearance. They have that choice with <input type=button>
> and we see things done both ways on the Web.
> 

Then it seems to me that we're not really not adding enough new functionality
that can't be implemented by existing technologies. 

Where are the use cases for the element?


-- 
Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

Received on Sunday, 27 December 2009 02:02:36 UTC