The <progress> element is the only way to get a progress bar that matches the native look and feel of the platform. It can also provide built-in accessibility support without having to rely on an author or script library doing it by hand. Basically the same thing as <input type=button>, but for progress indicators instead of buttons. Granted, progress bars are not as common in typical UI as buttons, but they seem common enough to support directly.

(It's unclear to me how you would use RDFa to make a progress bar, but I can't imagine it makes things any simpler.)

Typo fix, should be:

"Lastly, the description for progress is overly complicated--mixing HTML syntax
and user agent parsing directions, as well as proving an inordinate number of
somewhat confusing rules and regulations for the progress element's conforming
use. This is going to make it more likely, rather than less, that the progress
element will be used by web page authors and designers_incorrectly_."

Metadata techniques are a way of tying together task and task progress. There is no association between task and progress element in the description of progress. One is left to assume that the progress is associated with some action or another, but nothing to give a precise pairing in the markup. 

As the progress element is currently defined, it can be treated as a static element, as well as a dynamically altered element. In particular, the example given about space usage could be a static value, displayed when the page is first loaded. 

If a static element, then, it's only useful if you can pair the progress value with whatever task is associated. 

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. 

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. 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.

Sorry, my misread of the section: it looks like the disk usage example was a demonstration of when _not_ to use progress. 

"The progress element is the wrong element to use for something that is just a gauge, as opposed to task progress. For instance, indicating disk space usage using progress would be inappropriate. Instead, the meter element is available for such use cases."

I'll have more on meter in another bug, but for now, there's nothing in the section that specifically states that the progress element must be dynamically altered. Indicating task progress could be a static effect, as well as a dynamic one. 

(In reply to comment #2)
> 
> Metadata techniques are a way of tying together task and task progress. There
> is no association between task and progress element in the description of
> progress. One is left to assume that the progress is associated with some
> action or another, but nothing to give a precise pairing in the markup. 

Progress indicators in UI are often not associated with a specific task and may entirely lack a label. That being said, sometimes they do have a label, and it is a fair point that they should be labelable in a way that e.g. assistive technologies can recognized. Filed bug 8554. (Although aria-labeledby could potentially work as well).

> 
> As the progress element is currently defined, it can be treated as a static
> element, as well as a dynamically altered element. In particular, the example
> given about space usage could be a static value, displayed when the page is
> first loaded. 
> 
> If a static element, then, it's only useful if you can pair the progress value
> with whatever task is associated. 

Using a <progress> element for a static effect would be a stylistically poor use. That would be like putting a progress bar in an application that never moves (or putting a static progress bar looking thing in a document). At TPAC some people discussed the fact that the text-based fallback handling for <progress> adds a lot of complexity while serving a useless use case (markup-declared progress bar). We tentatively agreed that the text-based fallback should be removed. This is documented in bug 8152.

> 
> 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

> 
> 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."

> 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.


(In reply to comment #3)
> 
> I'll have more on meter in another bug, but for now, there's nothing in the
> section that specifically states that the progress element must be dynamically
> altered. Indicating task progress could be a static effect, as well as a
> dynamic one. 
> 

Indeed, I don't think it's the right element to display a static level of task progress - I am not sure that is a likely use case or that it needs specific presentation.

 
> > 
> > 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?

(In reply to comment #5)
> > > 
> > > 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

Indeed, you can use those to build a custom progress indicator from scratch. However, the <progress> element has built-in accessibility behavior without the need for explicit ARIA markup. You said "there's nothing about accessibility associated with the description of the progress bar" but that's incorrect, it is defined to have the same accessibility behavior built-in as would be provided by ARIA progressbar markup.

> 
> > > 
> > > 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.

You previously said: "In addition, there's nothing about the element description that indicates it provides a platform specific visual element." That's clearly incorrect. It's true that the requirement is stated in a vague way, because platform conventions for progress indicators vary widely.

> 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. 

Web applications always use a custom look for progress bars, because there hasn't been a way to get the platform native look. For text fields, scrollbars or checkboxes, it's most common to use the platform look, and it's easy to do. For pusbuttons, both approaches (platform-native and custom) are quite common.

Your own preference may be for all custom controls in Web apps - but clearly not all Web designers agree. I don't think it makes sense to call one approach or the other "invalid".

> 
> 
> > > 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. 

We're adding at least one piece of new functionality: the ability to get a progress that matches the platform look and feel. There is no way to do that with existing Web technologies. We're also providing a convenient way to build a common piece of functionality: a progress indicator.

You could similarly argue that <input type=button> or <input type=text> do not add any new functionality, since they can be replicated with custom drawing and script. Do you believe those should be removed?

I would instead take the view that reasonably common UI elements should have built-in support. You should not have to resort to custom drawing and  events and timers to implement basic UI. Further, having built-in elements makes it more likely authors will get accessibility right - since it's built in, there is no way to get it wrong and no need to add anything special to work with AT.

> Where are the use cases for the element?

I think the use cases for a progress indicator are pretty obvious, but here goes:

- Displaying progress of a slow computation happening on a background thread.
- Displaying an indefinite duration "busy" state.
- Indicating the progress of a network upload or download.
- Indicating the time it will take an application to launch via a splash screen.
- Showing the progress of a copy operation.

I'm sure you have seen many other examples of progress bars, spinners or throbbers.

(In reply to comment #6)
> (In reply to comment #5)
> > > > 
> > > > 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
> 
> Indeed, you can use those to build a custom progress indicator from scratch.
> However, the <progress> element has built-in accessibility behavior without the
> need for explicit ARIA markup. You said "there's nothing about accessibility
> associated with the description of the progress bar" but that's incorrect, it
> is defined to have the same accessibility behavior built-in as would be
> provided by ARIA progressbar markup.
> 

Six of one, half dozen of another -- I have a feeling the same amount of work is required with the custom work as it is with the progress element. However, existing techniques work now, while as far as we know, there is no user agent implementation of the browser element. 

Does WebKit support the element?
 
> > 
> > 
> > > > 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. 
> 
> We're adding at least one piece of new functionality: the ability to get a
> progress that matches the platform look and feel. There is no way to do that
> with existing Web technologies. We're also providing a convenient way to build
> a common piece of functionality: a progress indicator.
> 
> You could similarly argue that <input type=button> or <input type=text> do not
> add any new functionality, since they can be replicated with custom drawing and
> script. Do you believe those should be removed?
> 
> I would instead take the view that reasonably common UI elements should have
> built-in support. You should not have to resort to custom drawing and  events
> and timers to implement basic UI. Further, having built-in elements makes it
> more likely authors will get accessibility right - since it's built in, there
> is no way to get it wrong and no need to add anything special to work with AT.
> 
> > Where are the use cases for the element?
> 
> I think the use cases for a progress indicator are pretty obvious, but here
> goes:
> 
> - Displaying progress of a slow computation happening on a background thread.
> - Displaying an indefinite duration "busy" state.
> - Indicating the progress of a network upload or download.
> - Indicating the time it will take an application to launch via a splash
> screen.
> - Showing the progress of a copy operation.
> 

Part of these could be replaced by a generic throbber graphic, as is widely implemented today. 

However, I'm not sure we have all the pieces in place to actually use a progress element with things like network uploads and downloads, because we don't always have the access to the data in order to programatically update the progress bar to reflect the state. 

> I'm sure you have seen many other examples of progress bars, spinners or
> throbbers.
>

Sure, for the last 10-15 years or so. 

We disagree. Luckily there's a procedure in place to handle disagreement. 
 

(In reply to comment #7)

> 
> Six of one, half dozen of another -- I have a feeling the same amount of work
> is required with the custom work as it is with the progress element.

I don't think that's the case. With a fully custom control, you have to handle the appearance, behavior (responding to the API and possibly including animations), and the accessibility via ARIA. Then you poke at that API. With the <progress> element, the first three are taken care of for you, so you just go ahead and use the API. If you want custom appearance, then you must provide for that, but

> However, existing techniques work now, while as far as we know, there is no user agent
> implementation of the browser element. 

This is true for most of the new elements - until they get implemented.

>
> Does WebKit support the element?

Not yet, but it's definitely on our wishlist. For now we are holding off until bug 8152 gets addressed. See some of our earlier feedback here:

http://lists.w3.org/Archives/Public/public-html/2009Sep/0008.html


> > 
> > I think the use cases for a progress indicator are pretty obvious, but here
> > goes:
> > 
> > - Displaying progress of a slow computation happening on a background thread.
> > - Displaying an indefinite duration "busy" state.
> > - Indicating the progress of a network upload or download.
> > - Indicating the time it will take an application to launch via a splash
> > screen.
> > - Showing the progress of a copy operation.
> > 
> 
> Part of these could be replaced by a generic throbber graphic, as is widely
> implemented today. 
> 
> However, I'm not sure we have all the pieces in place to actually use a
> progress element with things like network uploads and downloads, because we
> don't always have the access to the data in order to programatically update the
> progress bar to reflect the state. 

XMLHttpRequest2 supports Progress Events for both upload and download, and the HTML5 media elements support it for download. These are some of the more likely APIs to be used for large transfers. Likely more APIs will have progress event support added.


> We disagree. Luckily there's a procedure in place to handle disagreement. 

Fair enough. It just seemed like your original suggestion was based on some incorrect assumptions about the spec. I just wanted to set the record straight on those, to make sure we have the correct information on the record. If none of this changes your mind, so be it.

> > We disagree. Luckily there's a procedure in place to handle disagreement. 
> 
> Fair enough. It just seemed like your original suggestion was based on some
> incorrect assumptions about the spec. I just wanted to set the record straight
> on those, to make sure we have the correct information on the record. If none
> of this changes your mind, so be it.
> 

We have to disagree that my suggestion is based on incorrect assumptions. In a way, that's what disagreement is: the belief that the person you disagree with is basing their opinion on incorrect assumptions. 

As for "record" that would be something that comes from the change proposal, if the bug is marked as WONTFIX. 

But people have reacted with irritation at multiple comments going back and forth in the bugs (and in the email lists, at least when I and some others in the HTML WG participate, or comment). I wouldn't want to cause anyone irritation. 

from #1:
> The <progress> element is the only way to get a progress bar that matches the
native look and feel of the platform.
I don't think this kind of reason warrants a new element type. It's a presentational need and should be solved by styling. Indeed, we're awaiting the appearance property in CSS which will do exactly that.
Or is there actually some semantic rationale for progress? Is it like WHATWG's idea of http://www.w3.org/TR/xforms/#ui-range (which, BTW, shows the quoted statement to be false)?

(In reply to comment #10)
> from #1:
> > The <progress> element is the only way to get a progress bar that matches the
> native look and feel of the platform.
> I don't think this kind of reason warrants a new element type. It's a
> presentational need and should be solved by styling. Indeed, we're awaiting the
> appearance property in CSS which will do exactly that.

Sure, you could try to make a styling-only solution. However, an appearance property would be hard to apply by itself, since a progress indicator has many visual states (the different possible progress levels, multiple indetermediate states, and different horizontal and vertical states. All told it would take hundreds of different appearance values unless the appearance property knew how to be reactive to some aspect of the element state.

Whether or not a styling-level solution could get the appearance right, controls commonly found in application user interface, it seems to me we should provide a single solution that provides the appearance, behavior, semantics and accessibility aspects of a progress indicator, rather than making authors implement each separately by hand.

> Or is there actually some semantic rationale for progress? Is it like WHATWG's
> idea of http://www.w3.org/TR/xforms/#ui-range

The HTML5 equivalent of this is <input type=range>, not <progress>.

> (which, BTW, shows the quoted statement to be false)?

No, a range input is completely different from a progress indicator. A range input is typically rendered as a slider control. A slider has a thumb that lets the user select a value. A progress bar looks completely different, in all GUI toolkits with which I am familiar. The XForms section you link even has a sample rendering which is very clearly not a progress bar but a slider.

While the best mapping of XForms' range to HTML5 would indeed most often be adorned input (thx for reminding; I check on the proliferation of input/@type values only occasionally), the reverse mapping would give range (used with read-only MIP) for HTML5's proposed progress as well. Genericity of XForms' set of controls (device independence, presentation agnosticism, features nice for a11y, l10n and m12n) is a better approach. HTML is not a UI (actually even GUI) language and it would be both unwise and grotesque (given the basis of HTML forms' legacy) to extend it too much in that direction. I see two very viable styling solutions, both author friendly. One is functional notations in appearance values capable of expressing the necessary facets you mention. The other is a binding (see http://lists.w3.org/Archives/Public/public-html/2009Sep/0739.html for something similar). Thoughts, preferences, anybody?

Even if progress is included, I strongly prefer a styling solution which would also be applicable beyond HTML5 (indeed, XForms comes promptly to mind).

(In reply to comment #12)
> While the best mapping of XForms' range to HTML5 would indeed most often be
> adorned input (thx for reminding; I check on the proliferation of input/@type
> values only occasionally), the reverse mapping would give range (used with
> read-only MIP) for HTML5's proposed progress as well. 

I disagree. There is no mapping from HTML5 <progress> to XForms that preserves semantic fidelity.  What you describe would be the XForms equivalent of <input type=range readonly>. But <progress> does not have the same semantics as <input type=range readonly>. One represents a progress indicator. The other represents a range with a particular value selected, and not currently alterable by the user. These are not the same thing.

> Genericity of XForms' set  of controls (device independence, presentation agnosticism, 
> features nice for a11y, l10n and m12n) is a better approach. 

This is really not the place to debate the merits of XForms vs. HTML. Suffice it to say that HTML takes a different approach.

> HTML is not a UI (actually even GUI)  language and it would be both unwise and grotesque 
> (given the basis of HTML  forms' legacy) to extend it too much in that direction. 

HTML was not originally designed as a UI language, but it has evolved to be a language for both documents and applications. And the HTML WG is chartered to evolve HTML to support both documents and applications.

> I see two very viable styling solutions, both author friendly. One is functional notations in
> appearance values capable of expressing the necessary facets you mention. 

This is still less author-friendly than a single interface that takes care of appearance, behavior and accessibility considerations at at once.

> The other is a binding (see  http://lists.w3.org/Archives/Public/public-html/2009Sep/0739.html
> for something similar). Thoughts, preferences, anybody?

HTML5 does in fact express the intended rendering and interaction behavior of the <progress> element as a binding. However, it seems to me that as specified it is not a binding that could be reused on an arbitrary element.

More generally, I think the cited message is based on an incorrect premise -- that the subject matter of HTML is only "hypertext", defined so narrowly as to exclude even multimedia. That may have been true once, but hasn't been for at least a decade.

> Even if progress is included, I strongly prefer a styling solution which would
> also be applicable beyond HTML5 (indeed, XForms comes promptly to mind).

You're certainly welcome to propose a syntax to get the styling of a native progress bar, but I think the CSS WG would be a more appropriate venue.

I'll comment on just 2 of your points, since others can be easily seen to be either obvious or highly contentious and discussed many times elsewhere.

> I disagree. There is no mapping from HTML5 <progress> to XForms that preserves
semantic fidelity.  What you describe would be the XForms equivalent of <input
type=range readonly>. But <progress> does not have the same semantics as <input
type=range readonly>. One represents a progress indicator. The other represents
a range with a particular value selected, and not currently alterable by the
user. These are not the same thing.
Of course <input type="range" readonly="readonly"> tag is also a range control in XForms which takes an approach from 50000 metres and makes distinctions among control types only as much as necessary from the perspective of binding to an underlying data model (I called it presentation agnosticism). If you want to tweak presentation, you use CSS, XBL and such. If you want to enrich semantics (and possibly base presentational aspects on it as a sensible good practice), use RDF, e.g. via WAI-ARIA. Both are laudable endeavours.

You seem to prefer a universal hammer both for painting your walls and preparing salads. I'm not here to prevent you from doing so. I just want to ensure for myself and numerous others the ability to use for particular types of tasks the tools we find most appropriate and have them interoperate in clean and simple ways. Please don't deprive us of what we believe is better. Can't we tend to solve problems in ways which don't step on each other's feet?
(I know I've taken even more liberty than you did in digressing from the bug at hand. Please understand the motivation based on our needs and the threat we perceive from some WHATWG tendencies.)

>> I see two very viable styling solutions, both author friendly. One is functional notations in appearance values capable of expressing the necessary facets you mention. 
> This is still less author-friendly than a single interface that takes care of
appearance, behavior and accessibility considerations at at once.
The CSS WG is going to work on it nevertheless. That would be a good time to discuss details. But about author friendliness I think the issue is the same as usually. If you do just toy apps, one-off eye candies or similar plankton (which is what most authors actually do, but they contribute little towards innovation and are served more easily with high level authoring tools), you'll likely prefer to have everything you find useful at your fingertips in a syntactically uniform way and won't be hindered much by quirks and inconsistencies. Still today most authors prefer presentational markup to CSS (especially for layout, which actually wasn't a priority for levels 1 and 2), although few speak about it openly, knowing it's generally frowned upon. But when you want to do something great and innovative, you start appreciating clean design with no idiosyncratic obstacles, mathematically precise rules with as few exceptions as possible, modularity, orthogonality and separation of concerns. So again, please do whatever legacy content needs but treat it as legacy, a mess to deal with, not the ideal to perpetuate, and using solutions which don't get into the ways of people knowing what they want with a sane approach.

Back to the point at hand, I'm not against the progress element type any more than against turning HTML into a bloated UI language in general, biased towards presentation in a browser and having little value without scripting. If you go ahead and keep it in, I believe the right final destination for it will anyway be something like a legacy UI module in a future version of M12N.

EDITOR'S RESPONSE: This is an Editor's Response to your comment. If you are satisfied with this response, please change the state of this bug to CLOSED. If you have additional information and would like the editor to reconsider, please reopen this bug. If you would like to escalate the issue to the full HTML Working Group, please add the TrackerRequest keyword to this bug, and suggest title and text for the tracker issue; or you may create a tracker issue yourself, if you are able to do so. For more details, see this document:
   http://dev.w3.org/html5/decision-policy/decision-policy.html

Status: Rejected
Change Description: no spec change
Rationale: <progress> fixes a serious accessibility problem with dynamic apps, and accessibility is important.

Created as Tracker Issue 96

http://www.w3.org/html/wg/tracker/issues/96