This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.

Bug 13436 - Editorial changes to The Video element (4 of 5)
Summary: Editorial changes to The Video element (4 of 5)
Status: CLOSED WONTFIX
Alias: None
Product: HTML WG
Classification: Unclassified
Component: HTML a11y Task Force (show other bugs)
Version: unspecified
Hardware: PC Windows XP
: P2 normal
Target Milestone: ---
Assignee: John Foliot
QA Contact: This bug has no owner yet - up for the taking
URL: http://www.w3.org/TR/2011/WD-html5-20...
Whiteboard:
Keywords: a11y, a11ytf, media
Depends on:
Blocks:
 
Reported: 2011-07-28 21:52 UTC by John Foliot
Modified: 2014-03-08 22:31 UTC (History)
13 users (show)

See Also:


Attachments

Description John Foliot 2011-07-28 21:52:11 UTC
"User agents should provide controls to enable or disable the display of closed captions, audio description tracks, and other additional data associated with the video stream, though such features should, again, not interfere with the page's normal rendering."

recommended  change:

"User agents MUST provide controls to enable or disable the display of closed captions, audio description tracks, and other additional data associated with the video stream, though such features should, again, not interfere with the page's normal rendering."

filed on behalf of the a11yTF
Comment 1 Michael[tm] Smith 2011-08-04 05:11:54 UTC
mass-move component to LC1
Comment 2 Ian 'Hixie' Hickson 2011-08-12 22:08:18 UTC
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: what if the user doesn't want a control to enable or disable captions? Should a user agent not be allowed to make the user happy?
Comment 3 Shelley Powers 2011-08-12 22:12:31 UTC
(In reply to comment #2)
> 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: what if the user doesn't want a control to enable or disable
> captions? Should a user agent not be allowed to make the user happy?

Last time I heard, web authors, developers, and designers are users, too.
Comment 4 Shelley Powers 2011-08-12 22:18:41 UTC
(In reply to comment #2)
> 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: what if the user doesn't want a control to enable or disable
> captions? Should a user agent not be allowed to make the user happy?

My previous statement was related to another bug, sorry.  

On this bug: why on earth would you not have a control that allows a person to choose subtitles/captions? If you're going to provide a control, and, in fact, you're not allowing designers and developers the ability to override providing this control (when scripting is turned off), why would you not want a comprehensive control?

If we followed your logic, blu-ray and DVD players would not provide options for people to pick captions or subtitles if the video provides them--based on some off chance there are people who may not want them.

Your decision makes no sense, at all. And it totally contradicts the addition of support for multiple tracks. Why provide multiple track API support, if you don't account for multiple tracks in the user interface?

Bizarre.
Comment 5 John Foliot 2011-08-13 00:08:03 UTC
(In reply to comment #2)
> Rationale: what if the user doesn't want a control to enable or disable
> captions? Should a user agent not be allowed to make the user happy?

Hypothetical edge-case, based on zero data. What proof do you have that any user wouldn't want to have controls over their user-experience or user-agent?

Conversely, if a user-agent fails to provide this function then it is a certainty that some (all?) users will be unable to toggle closed captions, audio description tracks, and other additional data associated with the video stream on or off.

Re-opened and awaiting a serious response
Comment 6 Tab Atkins Jr. 2011-08-13 01:27:31 UTC
The requirement is already a SHOULD.  That means that UAs have to follow it unless they have a good reason not to.  For example, like the user not wanting to see the control.

What would be helped by making this a MUST over a SHOULD?
Comment 7 Shelley Powers 2011-08-13 02:10:27 UTC
(In reply to comment #6)
> The requirement is already a SHOULD.  That means that UAs have to follow it
> unless they have a good reason not to.  For example, like the user not wanting
> to see the control.
> 
> What would be helped by making this a MUST over a SHOULD?


"means that UAs have to follow it
> unless they have a good reason not to."

This is a vague phrase that means very little from a technical perspective. The UA may decide the "good reason" is because they just don't feel like doing it. It's entirely subjective. 

You certainly can't set up a test case for "good reason not to".

If the control is displayed at all, providing a simple modification to allow a person to select from different tracks is a no brainer. It does not have to take any additional real estate and can be embedded into existing controls. 

Why provide multiple track support if it wasn't going to be exposed in the default UI? Why provide for multiple text tracks if there isn't anything in the default control allowing a person to select from among them?

Beyond bizarre.
Comment 8 Tab Atkins Jr. 2011-08-13 04:39:44 UTC
(In reply to comment #7)
> (In reply to comment #6)
> "means that UAs have to follow it
> > unless they have a good reason not to."
> 
> This is a vague phrase that means very little from a technical perspective. The
> UA may decide the "good reason" is because they just don't feel like doing it.
> It's entirely subjective. 

You don't understand what the RFC 2119 keywords mean.  Please read http://www.ietf.org/rfc/rfc2119.txt
Comment 9 Shelley Powers 2011-08-13 04:49:41 UTC
(In reply to comment #8)
> (In reply to comment #7)
> > (In reply to comment #6)
> > "means that UAs have to follow it
> > > unless they have a good reason not to."
> > 
> > This is a vague phrase that means very little from a technical perspective. The
> > UA may decide the "good reason" is because they just don't feel like doing it.
> > It's entirely subjective. 
> 
> You don't understand what the RFC 2119 keywords mean.  Please read
> http://www.ietf.org/rfc/rfc2119.txt

And the HTML5 spec states UAs "should" display the video control when scripting is disabled, yet only one UA does. So much for "should".

There is no reason not to provide a facility to choose tracks if the control is displayed. Well, unless there's a particular reason to deliberately disable video accessibility. Is there a reason to deliberately disable video accessibility? 

What is one good use case for not ensuring this capability?
Comment 10 Tab Atkins Jr. 2011-08-13 05:02:12 UTC
(In reply to comment #9)
> (In reply to comment #8)
> > (In reply to comment #7)
> > > (In reply to comment #6)
> > > "means that UAs have to follow it
> > > > unless they have a good reason not to."
> > > 
> > > This is a vague phrase that means very little from a technical perspective. The
> > > UA may decide the "good reason" is because they just don't feel like doing it.
> > > It's entirely subjective. 
> > 
> > You don't understand what the RFC 2119 keywords mean.  Please read
> > http://www.ietf.org/rfc/rfc2119.txt
> 
> And the HTML5 spec states UAs "should" display the video control when scripting
> is disabled, yet only one UA does. So much for "should".

You don't understand how to file browser bugs.

> There is no reason not to provide a facility to choose tracks if the control is
> displayed. Well, unless there's a particular reason to deliberately disable
> video accessibility. Is there a reason to deliberately disable video
> accessibility? 
> 
> What is one good use case for not ensuring this capability?

The spec doesn't mandate UI.
Comment 11 Shelley Powers 2011-08-13 05:15:07 UTC
(In reply to comment #10)
> (In reply to comment #9)
> > (In reply to comment #8)
> > > (In reply to comment #7)
> > > > (In reply to comment #6)
> > > > "means that UAs have to follow it
> > > > > unless they have a good reason not to."
> > > > 
> > > > This is a vague phrase that means very little from a technical perspective. The
> > > > UA may decide the "good reason" is because they just don't feel like doing it.
> > > > It's entirely subjective. 
> > > 
> > > You don't understand what the RFC 2119 keywords mean.  Please read
> > > http://www.ietf.org/rfc/rfc2119.txt
> > 
> > And the HTML5 spec states UAs "should" display the video control when scripting
> > is disabled, yet only one UA does. So much for "should".
> 
> You don't understand how to file browser bugs.


And you don't know how to respond in a constructive manner in bug threads. 

> 
> > There is no reason not to provide a facility to choose tracks if the control is
> > displayed. Well, unless there's a particular reason to deliberately disable
> > video accessibility. Is there a reason to deliberately disable video
> > accessibility? 
> > 
> > What is one good use case for not ensuring this capability?
> 
> The spec doesn't mandate UI.


When the progress binding applies to a progress element, the element is expected to render as an 'inline-block' box with a 'height' of '1em' and a 'width' of '10em', and a 'vertical-align' of '-0.2em'.

When the element is wider than it is tall, the element is expected to be depicted as a horizontal progress bar, with the start on the right and the end on the left if the 'direction' property on this element has a computed value of 'rtl', and with the start on the left and the end on the right otherwise. When the element is taller than it is wide, it is expected to depicted as a vertical progress bar, with the lowest value on the bottom. When the element is square, it is expected to be depicted as a direction-independent progress widget (e.g. a circular progress ring).

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.

For example, on some platforms for showing indeterminate progress there is an asynchronous progress indicator with square dimensions, which could be used when the element is square, and an indeterminate progress bar, which could be used when the element is wide.

Requirements for how to determine if the progress bar is determinate or indeterminate, and what progress a determinate progress bar is to show, are included in the definition of the progress element.
Comment 12 John Foliot 2011-08-13 06:02:25 UTC
(In reply to comment #10)
> 
> You don't understand how to file browser bugs.
> 
> The spec doesn't mandate UI.

Tab, this is not a browser bug tracker, it's the HTML5 bug tracker, and this is an editorial defect with the current Draft Spec. This bug was discussed by members of the accessibility task force media group and had support from members present at that discussion.

This is not a UI requirement but rather a control requirement. You can make it a button, a drop-down menu or any other UI widget you want it to look like, but an accessible toggle mechanism is a MUST requirement whenever captions or other accessibility support materials are present.

If you read the original bug, the phrase "...though such features should, again, not interfere with the page's normal rendering." is retained, so I am unclear why this seems so controversial. If you have a start button, you need a stop button. If you have optional asset(s) assigned to a media asset, you require a means to toggle it/them on or off. This is not a SHOULD, this is a MUST - how else will a user be able to interact with the option(s)?

If a user-agent chooses (for example) to make their native controls operate as a "show/hide" effect (such as how YouTube operates today) then that control bar MUST contain the toggle when all other controls are presented to the user. This is not mandating the UI of the controls bar, only the components present on that controls bar.
Comment 13 Benjamin Hawkes-Lewis 2011-08-13 09:34:25 UTC
(In reply to comment #12)
> > The spec doesn't mandate UI.

[snip]

> This is not a UI requirement but rather a control requirement. You can make it
> a button, a drop-down menu or any other UI widget you want it to look like, but
> an accessible toggle mechanism is a MUST requirement whenever captions or other
> accessibility support materials are present.

As always, by UI Tab does not mean *just* how the interface looks, or what widgets the interface uses, but also what the interface *is* - that is the specific functionality that user agents offer the users based on the semantics of the markup language and its APIs (their "feature sets", if you prefer). That would include "control requirements".

In general, the spec tries to specify what the language and its APIs mean, not what consuming software should do with that on the user's behalf. This frees user agents to act in the best interests of their user given their specific use case.

In this case, I don't see how your proposed text change would make any sense for user agents like wget that do not display content, or printers that do not allow interaction with content, or any user agent that does not have access to sound output and therefore cannot "display" audio description tracks.
Comment 14 Shelley Powers 2011-08-13 13:32:31 UTC
(In reply to comment #13)
> (In reply to comment #12)
> > > The spec doesn't mandate UI.
> 
> [snip]
> 
> > This is not a UI requirement but rather a control requirement. You can make it
> > a button, a drop-down menu or any other UI widget you want it to look like, but
> > an accessible toggle mechanism is a MUST requirement whenever captions or other
> > accessibility support materials are present.
> 
> As always, by UI Tab does not mean *just* how the interface looks, or what
> widgets the interface uses, but also what the interface *is* - that is the
> specific functionality that user agents offer the users based on the semantics
> of the markup language and its APIs (their "feature sets", if you prefer). That
> would include "control requirements".
> 
> In general, the spec tries to specify what the language and its APIs mean, not
> what consuming software should do with that on the user's behalf. This frees
> user agents to act in the best interests of their user given their specific use
> case.
> 
> In this case, I don't see how your proposed text change would make any sense
> for user agents like wget that do not display content, or printers that do not
> allow interaction with content, or any user agent that does not have access to
> sound output and therefore cannot "display" audio description tracks.

But then, these user agents would not provide a control at all. Nor support the multimedia API, or provide any other interactivity. 

This is entirely different from "what if the user doesn't want a control to enable or disable captions? Should a user agent not be allowed to make the user happy?"

Let's not play semantics, let's look at the real issue: if a means to control a media file is present, then user agents must provide controls to enable or disable the display of closed captions, audio description tracks, etc. 

How about a compromise?

In the section 4.8.10.13[1] on the media user interface, text can be added to ensure that the controls to enable or disable the display of closed captions, etc, are provided when circumstances warrant. 

If the user agent does provide playback control in the context menu, then it _must_ also provide the means to enable or disable captions etc. If the user agent does expose a user interface to control the media file, then it _must_ also provide the means to enable or disable captions etc. 

The user can ignore these options if they wish, and as stated in the bug, the presence of these additional controls must not interfere with the page's normal rendering, but they _must_ be provided in these circumstances.

Would something like this work instead?

[1] http://dev.w3.org/html5/spec/the-iframe-element.html#user-interface
Comment 15 Benjamin Hawkes-Lewis 2011-08-13 14:26:44 UTC
(In reply to comment #14)
> > In this case, I don't see how your proposed text change would make any sense
> > for user agents like wget that do not display content, or printers that do not
> > allow interaction with content, or any user agent that does not have access to
> > sound output and therefore cannot "display" audio description tracks.
> 
> But then, these user agents would not provide a control at all. Nor support the
> multimedia API, or provide any other interactivity. 

Not necessarily true in the last case!

> Let's not play semantics, let's look at the real issue: if a means to control a
> media file is present, then user agents must provide controls to enable or
> disable the display of closed captions, audio description tracks, etc. 

Yeah, confusion about what we all mean by "UI" aside, I don't think this is a matter of semantics but first principles of an open system like the Web.

Why should a user agent that can show captions but cannot play audio tracks and so does not show user audio description controls be non-conforming?

For example, if a user agent is designed for a device does not have sound output capable of rendering the audio tracks (like a first-generation Kindle), why should it be required to display controls to play audio descriptions?

Or again, why should a user agent designed for deafblind users that does not include audio description controls be non-conforming?

    http://www.nanopac.com/BrailleNote%20DeafBlind%20Communicator.htm

One can of course argue about whether it's good or not for the user to include information about content they cannot immediately access. But it seems to me that as usual such negotiations are best left to users and user agent developers. Trying to mandate feature sets as if we knew all the ways people might want to consume web content would be hubristic.

Of course we want easy access to audio description tracks under normal circumstances in classic user agents like Firefox, Internet Explorer, Chrome, and Safari, but I object to trying to achieve that access by baking in feature set requirements for HTML user agents into the W3C HTML spec. I don't think it's an effective way to achieve such desirable results (historically it's been fairly unsuccessful), and promoting people's freedom to consume web content however they want (and build conforming user agents that allow them to do so) is (I think) more important. That freedom does, after all, allow people to build user agents that provide easy access to audio description tracks. Ultimately that freedom can even correct accessibility failings of user agents in jobs and public places. For example, let's say in two years user agents common in the workplace and public web access points like libraries support <video> but don't provide controls for audio descriptions, due to failings in the enforcement of discrimination laws or whatever. The freedom to build user agents that serve particular needs allows one to go ahead and construct (say) a proxy that adds on-page controls providing access to audio description tracks similar to how WebAnywhere provides screenreading access anywhere:

    http://webanywhere.cs.washington.edu/wa.php

In practice, I think the big problem will be getting the audio descriptions in the first place, rather than finding software capable of playing them back. The admitted problems of @longdesc access in popular user agents are less significant to society than a widespread absence of long text alternatives.
Comment 16 Shelley Powers 2011-08-13 14:50:58 UTC
(In reply to comment #15)
> (In reply to comment #14)
> > > In this case, I don't see how your proposed text change would make any sense
> > > for user agents like wget that do not display content, or printers that do not
> > > allow interaction with content, or any user agent that does not have access to
> > > sound output and therefore cannot "display" audio description tracks.
> > 
> > But then, these user agents would not provide a control at all. Nor support the
> > multimedia API, or provide any other interactivity. 
> 
> Not necessarily true in the last case!
> 

There should still be accessibility controls in the latter case, but appropriate to the circumstance. 

> > Let's not play semantics, let's look at the real issue: if a means to control a
> > media file is present, then user agents must provide controls to enable or
> > disable the display of closed captions, audio description tracks, etc. 
> 
> Yeah, confusion about what we all mean by "UI" aside, I don't think this is a
> matter of semantics but first principles of an open system like the Web.
> 
> Why should a user agent that can show captions but cannot play audio tracks and
> so does not show user audio description controls be non-conforming?
> 
> For example, if a user agent is designed for a device does not have sound
> output capable of rendering the audio tracks (like a first-generation Kindle),
> why should it be required to display controls to play audio descriptions?
>

Actually, first generation Kindles do have audio. Are you talking about the ability to translate text into audio? Regardless, that's beside the point since we're talking about HTML5 media. 

Again, the accessibility controls would reflect the circumstances. If the device has no audio, no support for audio is provided, including accessibility support. However, video support _must_ be provided. 
 
> Or again, why should a user agent designed for deafblind users that does not
> include audio description controls be non-conforming?
>

Again, it doesn't have to add to the overall length of the HTML5 document to detail accessibility control requirements based on circumstances. 
 
>     http://www.nanopac.com/BrailleNote%20DeafBlind%20Communicator.htm
> 
> One can of course argue about whether it's good or not for the user to include
> information about content they cannot immediately access. But it seems to me
> that as usual such negotiations are best left to users and user agent
> developers. Trying to mandate feature sets as if we knew all the ways people
> might want to consume web content would be hubristic.
> 

No, they're not. 

You mention longdesc later in your comment. If user agents had properly supported longdesc, how much more would its correct use had been advanced? 

In my opinion, too many user agents have demonstrated a mostly lukewarm interest in supporting accessibility. It seems that user agents are more interested in competing with each other over the latest gee wiz geegaw than in providing accessibility. 

After all, "BANG! SPLASH!" drives more news articles than something like support for longdesc. 

Since user agents have demonstrated such lukewarm support, we need to up the ante--make accessibility a conformance issue.

And we're not talking incorporating a burdensome amount of text into the HTML5 spec, either. The HTML5 document contains a complete section on recommended uses of HTML for specific circumstances where there are no specific elements. Well, media accessibility is as important--more important--than that particular section. We're talking about ensuring a basic set of accessibility features for media elements, rather than leave such up to each individual user agent (and their interpretation of "good reasons").


> Of course we want easy access to audio description tracks under normal
> circumstances in classic user agents like Firefox, Internet Explorer, Chrome,
> and Safari, but I object to trying to achieve that access by baking in feature
> set requirements for HTML user agents into the W3C HTML spec. I don't think
> it's an effective way to achieve such desirable results (historically it's been
> fairly unsuccessful), and promoting people's freedom to consume web content
> however they want (and build conforming user agents that allow them to do so)
> is (I think) more important. 

What does this have to do with ensuring accessibility? Seriously, what you just wrote sounds noble, but how does providing accessible controls impede user freedom to consume media however they want? 

Just like with today's blu-ray players, people don't have to turn on subtitles or captions. Just like with today's Kindle, people don't have to turn on audio translations of books. This capability in no way impedes people's use of the media.

However, _not_ having this capability does impede the freedom of use for a portion of the user community. 

So, on the one hand, all web users have access, and on the other, only a portion of the consumers have access. Frankly, I'll take option number 1.


That freedom does, after all, allow people to
> build user agents that provide easy access to audio description tracks.
> Ultimately that freedom can even correct accessibility failings of user agents
> in jobs and public places. For example, let's say in two years user agents
> common in the workplace and public web access points like libraries support
> <video> but don't provide controls for audio descriptions, due to failings in
> the enforcement of discrimination laws or whatever. The freedom to build user
> agents that serve particular needs allows one to go ahead and construct (say) a
> proxy that adds on-page controls providing access to audio description tracks
> similar to how WebAnywhere provides screenreading access anywhere:
> 
>     http://webanywhere.cs.washington.edu/wa.php
> 
> In practice, I think the big problem will be getting the audio descriptions in
> the first place, rather than finding software capable of playing them back. The
> admitted problems of @longdesc access in popular user agents are less
> significant to society than a widespread absence of long text alternatives.

Again, what you wrote sounds noble, but is largely irrelevant to ensuring that accessibility is baked into the HTML5 media controls. 

This isn't about laws, or libraries, or whether the audio tracks are even available--this is about ensuring HTML5 media elements are accessible.
Comment 17 Benjamin Hawkes-Lewis 2011-08-13 15:59:57 UTC
(In reply to comment #16)
> Again, the accessibility controls would reflect the circumstances. If the
> device has no audio, no support for audio is provided, including accessibility
> support. However, video support _must_ be provided.

I disagree that UAs should be required to do anything at all with <video> or any other element not of interest.
 
> > Or again, why should a user agent designed for deafblind users that does not
> > include audio description controls be non-conforming?
> >
> 
> Again, it doesn't have to add to the overall length of the HTML5 document

Concision is a good thing, but the length of the draft is not my motivating concern here. I think it's inherently risky to predict and try to cover all "circumstances". As we can see from the discussion so far, John's proposed change did not cover all circumstances. I see no reason why you or I can imagine all circumstances. SHOULD does cover all circumstances.

> > One can of course argue about whether it's good or not for the user to include
> > information about content they cannot immediately access. But it seems to me
> > that as usual such negotiations are best left to users and user agent
> > developers. Trying to mandate feature sets as if we knew all the ways people
> > might want to consume web content would be hubristic.
> 
> No, they're not.
>
> You mention longdesc later in your comment. If user agents had properly
> supported longdesc, how much more would its correct use had been advanced? 

I think the poor implementation status of @longdesc is only a tiny contributor to the rarity of long text alternatives on the Web. I've not seen a concrete case where someone has made an explicit decision not to provide a long text alternative *because* @longdesc is poorly supported, as opposed to simply adopting another (perhaps inferior) mechanism. Similarly, I think whether user agents like Firefox include audio description track controls in their default UI is only going to be a tiny contributor to the frequency of audio description on the Web over the next decade, and especially given the existence of a clientside API for detecting and playing such tracks, it's not going to be a substantial barrier to access. It seems like it would be fairly trivial to make an addon or bookmarklet to expose such tracks.

> In my opinion, too many user agents have demonstrated a mostly lukewarm
> interest in supporting accessibility. It seems that user agents are more
> interested in competing with each other over the latest gee wiz geegaw than in
> providing accessibility. 
>
> After all, "BANG! SPLASH!" drives more news articles than something like
> support for longdesc. 

Perhaps, but I think you'd be hard-pressed to demonstrate that popular user agents are worse in this respect than other large software projects.

> Since user agents have demonstrated such lukewarm support, we need to up the
> ante--make accessibility a conformance issue.

I disagree that baking MUST-level conformance requirements into the HTML spec is the right approach.

> > Of course we want easy access to audio description tracks under normal
> > circumstances in classic user agents like Firefox, Internet Explorer, Chrome,
> > and Safari, but I object to trying to achieve that access by baking in feature
> > set requirements for HTML user agents into the W3C HTML spec. I don't think
> > it's an effective way to achieve such desirable results (historically it's been
> > fairly unsuccessful), and promoting people's freedom to consume web content
> > however they want (and build conforming user agents that allow them to do so)
> > is (I think) more important. 
> 
> What does this have to do with ensuring accessibility? Seriously, what you just
> wrote sounds noble, but how does providing accessible controls impede user
> freedom to consume media however they want? 
>
> Just like with today's blu-ray players, people don't have to turn on subtitles
> or captions. Just like with today's Kindle, people don't have to turn on audio
> translations of books. This capability in no way impedes people's use of the
> media.

You're potentially mandating people work on features that their users do not want or that they cannot provide.

Either they take that requirement seriously, which takes time away from them working on features that their users do want or (worse) it stops them building the software in the first place.

Or (vastly more likely) they ignore that requirement, and treat the spec with less respect for trying to place such restrictions on their free use of the Web. If you train implementors to ignore conformance requirements, then you encourage more fundamental lack of interoperability. If you destroy interoperability, then you make it even harder to build tools that depend on an interoperable substrate, such as WebAnywhere.

In practice, since WHATWG takes a firm line on not mandating UI, since popular browser implementors appear to be using the WHATWG spec as the basis of implementations rather than the W3C spec, and since naturally implementors pick-and-mix features to implement, the only real-world impact would be to make the W3C spec more irrelevant. It's not like the W3C creating UAAG made popular browsers actually implement UAAG. You need people involved in developing browsers to agree that these features are important and implement them. If they are, a SHOULD level requirement is more than enough *and* it protects us from our inability to consider all possible circumstances.

> However, _not_ having this capability does impede the freedom of use for a
> portion of the user community. 
> 
> So, on the one hand, all web users have access, and on the other, only a
> portion of the consumers have access. Frankly, I'll take option number 1.

If I thought a MUST requirement would such a difference, I'd be more inclined to agree.

> what you wrote sounds noble, but is largely irrelevant to ensuring that
> accessibility is baked into the HTML5 media controls. 
>
> This isn't about laws, or libraries, or whether the audio tracks are even
> available--this is about ensuring HTML5 media elements are accessible.

I can see how you if you imagine that by adding these MUST-level requirements we'd actually get implementations whereas with SHOULD-level requirements you could might be willing to trample over the free consumption of the Web to get there. I place a lot less faith in the power of spec text.

Spec text can enable the creation of accessible content and code that supports that content but it cannot actually make people create the content or write the code. The time spent spilling ink arguing for fairly futile MUST-level requirements would be better spent in a code editor building the features, not least because doing so is likely to uncover problems in the spec that we *do* need to fix to get interoperable accessibility in popular browsers. Or, if you can't code, it's better spent advocating directly to user agent vendors. Bug reports trump spec requirements, which is why the development of this HTML draft has so often been based on user agent developers explaining they will not conform to a requirement because of bug reports. The squeaky wheel gets the grease, and the W3C HTML spec is actually a very quiet wheel.
Comment 18 Shelley Powers 2011-08-13 16:36:22 UTC
(In reply to comment #17)
> (In reply to comment #16)
> > Again, the accessibility controls would reflect the circumstances. If the
> > device has no audio, no support for audio is provided, including accessibility
> > support. However, video support _must_ be provided.
> 
> I disagree that UAs should be required to do anything at all with <video> or
> any other element not of interest.

Apologies if my writing was less than clear. 

I meant that if no controls are present, or certain types of functionality aren't applicable, then of course the accessibility controls reflect this state.

However, if the control (whether a UI or context menu) are present, and the functionality is supported, then it must be accessible. 


> 
> > > Or again, why should a user agent designed for deafblind users that does not
> > > include audio description controls be non-conforming?
> > >
> > 
> > Again, it doesn't have to add to the overall length of the HTML5 document
> 
> Concision is a good thing, but the length of the draft is not my motivating
> concern here. I think it's inherently risky to predict and try to cover all
> "circumstances". As we can see from the discussion so far, John's proposed
> change did not cover all circumstances. I see no reason why you or I can
> imagine all circumstances. SHOULD does cover all circumstances.
> 
> > > One can of course argue about whether it's good or not for the user to include
> > > information about content they cannot immediately access. But it seems to me
> > > that as usual such negotiations are best left to users and user agent
> > > developers. Trying to mandate feature sets as if we knew all the ways people
> > > might want to consume web content would be hubristic.
> > 
> > No, they're not.
> >
> > You mention longdesc later in your comment. If user agents had properly
> > supported longdesc, how much more would its correct use had been advanced? 
> 
> I think the poor implementation status of @longdesc is only a tiny contributor
> to the rarity of long text alternatives on the Web. I've not seen a concrete
> case where someone has made an explicit decision not to provide a long text
> alternative *because* @longdesc is poorly supported, as opposed to simply
> adopting another (perhaps inferior) mechanism. Similarly, I think whether user
> agents like Firefox include audio description track controls in their default
> UI is only going to be a tiny contributor to the frequency of audio description
> on the Web over the next decade, and especially given the existence of a
> clientside API for detecting and playing such tracks, it's not going to be a
> substantial barrier to access. It seems like it would be fairly trivial to make
> an addon or bookmarklet to expose such tracks.
>


I'm having a hard time understanding your logic on this one. We hope that content providers provide captions or alternative audio tracks or whatever is necessary in order to make the media elements accessible. 

However, this has nothing to do with whether user agents support this functionality or not. Accessibility is not market driven. 

What you're almost saying is that user agents like Firefox are lazy, and only want to provide support based on market interest--leaving accessibility to third party providers because, frankly, it can't be bothered to ensure accessible media support.

Is this what you're implying? That a user agent like Firefox really can't be bothered to ensure accessibility of the media? If so, then it becomes even more imperative to ensure that the user agent, like Firefox, is given an additional incentive to ensure it provides accessibility.


 
> > In my opinion, too many user agents have demonstrated a mostly lukewarm
> > interest in supporting accessibility. It seems that user agents are more
> > interested in competing with each other over the latest gee wiz geegaw than in
> > providing accessibility. 
> >
> > After all, "BANG! SPLASH!" drives more news articles than something like
> > support for longdesc. 
> 
> Perhaps, but I think you'd be hard-pressed to demonstrate that popular user
> agents are worse in this respect than other large software projects.
>

But browsers are, most likely, the primary agents for delivering HTML5 media. As such, ensuring they're accessible has a strong, positive impact in the industry.

 
> > Since user agents have demonstrated such lukewarm support, we need to up the
> > ante--make accessibility a conformance issue.
> 
> I disagree that baking MUST-level conformance requirements into the HTML spec
> is the right approach.
>

When it comes to accessibility, it's the only way.

To repeat: accessibility is not market driven.
 

> > > Of course we want easy access to audio description tracks under normal
> > > circumstances in classic user agents like Firefox, Internet Explorer, Chrome,
> > > and Safari, but I object to trying to achieve that access by baking in feature
> > > set requirements for HTML user agents into the W3C HTML spec. I don't think
> > > it's an effective way to achieve such desirable results (historically it's been
> > > fairly unsuccessful), and promoting people's freedom to consume web content
> > > however they want (and build conforming user agents that allow them to do so)
> > > is (I think) more important. 
> > 
> > What does this have to do with ensuring accessibility? Seriously, what you just
> > wrote sounds noble, but how does providing accessible controls impede user
> > freedom to consume media however they want? 
> >
> > Just like with today's blu-ray players, people don't have to turn on subtitles
> > or captions. Just like with today's Kindle, people don't have to turn on audio
> > translations of books. This capability in no way impedes people's use of the
> > media.
> 
> You're potentially mandating people work on features that their users do not
> want or that they cannot provide.
>

Huge difference between "users do not want" and "cannot provide".

No one is dictating that user agents that "cannot provide" this capability be forced to provide this capability. The text to make this clear could be included in the UI section I mentioned earlier.

However, "users do not want" is, frankly, unacceptable. You're basing your whole argument on accessibility being market driven, when, to repeat, accessibility is not market driven.

There are some users that do want this functionality. In point of fact, when you including subtitle support in with caption support, I believe you'll find the majority of users want this functionality. But regardless, even if this functionality is only useful for a smaller subsection of the user population, it's _essential_ for that population.

Providing this support does not impact, in any way, on those who don't need this support. Again, it's little different than a TV providing closed captioning support: people can turn it on or off. Those who don't need it, don't turn it on; those who do, do.

So "users do not want" actually makes no sense at all, and does not reflect the web. 

> Either they take that requirement seriously, which takes time away from them
> working on features that their users do want or (worse) it stops them building
> the software in the first place.
>

Oh, now, this is the real key, isn't? User agents would rather spend their time on gee wiz geegaws than on accessibility.

My answer? Tough.

If we use care in the text, there won't be an unreasonable burden on user agents. There won't be a case where audio only user agents have to provide access to text tracks, or the like. 

But when the device/user agent is capable of displaying something like text tracks for a video, the option must be provided.
  
The gee wiz geegaw can just wait a couple of days.


> Or (vastly more likely) they ignore that requirement, and treat the spec with
> less respect for trying to place such restrictions on their free use of the
> Web. If you train implementors to ignore conformance requirements, then you
> encourage more fundamental lack of interoperability. If you destroy
> interoperability, then you make it even harder to build tools that depend on an
> interoperable substrate, such as WebAnywhere.
>

Then they won't be in conformance, and can't brag about their "HTML5" support to the world, or folks will call them on it. 

But that's true of every last aspect of HTML5. It doesn't stop the spec from peppering "must" all throughout. 
 
> In practice, since WHATWG takes a firm line on not mandating UI, since popular
> browser implementors appear to be using the WHATWG spec as the basis of
> implementations rather than the W3C spec, and since naturally implementors
> pick-and-mix features to implement, the only real-world impact would be to make
> the W3C spec more irrelevant. It's not like the W3C creating UAAG made popular
> browsers actually implement UAAG. You need people involved in developing
> browsers to agree that these features are important and implement them. If they
> are, a SHOULD level requirement is more than enough *and* it protects us from
> our inability to consider all possible circumstances.
>

This is the W3C. The WHATWG has their own priorities, among which seems to be lack of interest in accessibility. Whatever. Accessibility is a priority for the W3C. 

We're not arguing about what's including in whatever document at the WHATWG. We're talking about what's in the W3C HTML5 specification.
 
Your statement seems, on first, read, to be almost a threat. That if the HTML5 spec does mandate accessibility, the browser companies will basically have a snit and take their marbles and go home? I hope I'm reading your statement incorrectly. 

Are you saying that browser companies are that hostile to accessibility? 

Disturbing.

> > However, _not_ having this capability does impede the freedom of use for a
> > portion of the user community. 
> > 
> > So, on the one hand, all web users have access, and on the other, only a
> > portion of the consumers have access. Frankly, I'll take option number 1.
> 
> If I thought a MUST requirement would such a difference, I'd be more inclined
> to agree.
> 
> > what you wrote sounds noble, but is largely irrelevant to ensuring that
> > accessibility is baked into the HTML5 media controls. 
> >
> > This isn't about laws, or libraries, or whether the audio tracks are even
> > available--this is about ensuring HTML5 media elements are accessible.
> 
> I can see how you if you imagine that by adding these MUST-level requirements
> we'd actually get implementations whereas with SHOULD-level requirements you
> could might be willing to trample over the free consumption of the Web to get
> there. I place a lot less faith in the power of spec text.
> 
> Spec text can enable the creation of accessible content and code that supports
> that content but it cannot actually make people create the content or write the
> code. The time spent spilling ink arguing for fairly futile MUST-level
> requirements would be better spent in a code editor building the features, not
> least because doing so is likely to uncover problems in the spec that we *do*
> need to fix to get interoperable accessibility in popular browsers. Or, if you
> can't code, it's better spent advocating directly to user agent vendors. Bug
> reports trump spec requirements, which is why the development of this HTML
> draft has so often been based on user agent developers explaining they will not
> conform to a requirement because of bug reports. The squeaky wheel gets the
> grease, and the W3C HTML spec is actually a very quiet wheel.


I'm stating that HTML5 must meet the needs of a community of users, and among this community are those who have need of, and interest in, these accessible features. 

Accessibility is more important than something like WebGL, and a heck of a lot easier to implement--not to mention, more secure.

No, your argument just highlights to me why the use of "must" is absolutely essential.
Comment 19 Benjamin Hawkes-Lewis 2011-08-13 18:17:38 UTC
(In reply to comment #18)
> > > You mention longdesc later in your comment. If user agents had properly
> > > supported longdesc, how much more would its correct use had been advanced? 
> > 
> > I think the poor implementation status of @longdesc is only a tiny contributor
> > to the rarity of long text alternatives on the Web. I've not seen a concrete
> > case where someone has made an explicit decision not to provide a long text
> > alternative *because* @longdesc is poorly supported, as opposed to simply
> > adopting another (perhaps inferior) mechanism. Similarly, I think whether user
> > agents like Firefox include audio description track controls in their default
> > UI is only going to be a tiny contributor to the frequency of audio description
> > on the Web over the next decade, and especially given the existence of a
> > clientside API for detecting and playing such tracks, it's not going to be a
> > substantial barrier to access. It seems like it would be fairly trivial to make
> > an addon or bookmarklet to expose such tracks.
>
> I'm having a hard time understanding your logic on this one. We hope that
> content providers provide captions or alternative audio tracks or whatever is
> necessary in order to make the media elements accessible.

Indeed.

> However, this has nothing to do with whether user agents support this
> functionality or not. 

I think whether or not content providers make use of the relevant semantics will have a *lot* more impact on whether user agents provide UI for it than spec text. There's a bit of a chicken and egg situation here, but not much of one, as it's so trivial for users to get access via a bookmarklet or addon.

> Accessibility is not market driven. 

I didn't say it was and I'm not sure what that means.

> What you're almost saying is that user agents like Firefox are lazy, and only
> want to provide support based on market interest--leaving accessibility to
> third party providers because, frankly, it can't be bothered to ensure
> accessible media support.
> 
> Is this what you're implying? That a user agent like Firefox really can't be
> bothered to ensure accessibility of the media? If so, then it becomes even more
> imperative to ensure that the user agent, like Firefox, is given an additional
> incentive to ensure it provides accessibility.

I think characterising an open software project like Firefox as "lazy" is a sort of category error, so no that's not what I'm saying.

I don't think spec text in itself constitutes a strong incentive for user agent feature sets.

> > > In my opinion, too many user agents have demonstrated a mostly lukewarm
> > > interest in supporting accessibility. It seems that user agents are more
> > > interested in competing with each other over the latest gee wiz geegaw than in
> > > providing accessibility. 
> > >
> > > After all, "BANG! SPLASH!" drives more news articles than something like
> > > support for longdesc. 
> > 
> > Perhaps, but I think you'd be hard-pressed to demonstrate that popular user
> > agents are worse in this respect than other large software projects.
> >
> 
> But browsers are, most likely, the primary agents for delivering HTML5 media.
> As such, ensuring they're accessible has a strong, positive impact in the
> industry.

Spec text doesn't ensure anything. You're picking the weakest possible tool to
influence a large and complex ecosystem.

> > > Since user agents have demonstrated such lukewarm support, we need to up the
> > > ante--make accessibility a conformance issue.
> > 
> > I disagree that baking MUST-level conformance requirements into the HTML spec
> > is the right approach.
> >
> 
> When it comes to accessibility, it's the only way.
> 
> To repeat: accessibility is not market driven.

I don't think spec text changes market forces, if that's what you're hoping.

> > > > Of course we want easy access to audio description tracks under normal
> > > > circumstances in classic user agents like Firefox, Internet Explorer, Chrome,
> > > > and Safari, but I object to trying to achieve that access by baking in feature
> > > > set requirements for HTML user agents into the W3C HTML spec. I don't think
> > > > it's an effective way to achieve such desirable results (historically it's been
> > > > fairly unsuccessful), and promoting people's freedom to consume web content
> > > > however they want (and build conforming user agents that allow them to do so)
> > > > is (I think) more important. 
> > > 
> > > What does this have to do with ensuring accessibility? Seriously, what you just
> > > wrote sounds noble, but how does providing accessible controls impede user
> > > freedom to consume media however they want? 
> > >
> > > Just like with today's blu-ray players, people don't have to turn on subtitles
> > > or captions. Just like with today's Kindle, people don't have to turn on audio
> > > translations of books. This capability in no way impedes people's use of the
> > > media.
> > 
> > You're potentially mandating people work on features that their users do not
> > want or that they cannot provide.
> >
> 
> Huge difference between "users do not want" and "cannot provide".
> 
> No one is dictating that user agents that "cannot provide" this capability be
> forced to provide this capability. The text to make this clear could be
> included in the UI section I mentioned earlier.
> 
> However, "users do not want" is, frankly, unacceptable. You're basing your
> whole argument on accessibility being market driven, when, to repeat,
> accessibility is not market driven.

I don't know what you mean when you say my argument is based on "accessibility being market driven"?

> There are some users that do want this functionality. In point of fact, when
> you including subtitle support in with caption support, I believe you'll find
> the majority of users want this functionality. But regardless, even if this
> functionality is only useful for a smaller subsection of the user population,
> it's _essential_ for that population.

If the content gets created, then users who want access to it will need a way to access it. It would certainly be preferable if that support was provided out-of-the-box by popular user agents on consumer devices. I don't think spec text has much influence on this.
 
> Providing this support does not impact, in any way, on those who don't need
> this support. Again, it's little different than a TV providing closed
> captioning support: people can turn it on or off. Those who don't need it,
> don't turn it on; those who do, do.

This clearly isn't true. Additional elements of UI increase cognitive load (making it harder to find the right item in a context menu or the right button on a remote control) and the amount of additional interaction (keyboarding through more items in a menu or turning off accidentally triggered captions). (Personally, I would like my browser to provide me with access to audio descriptions just as I would like my TV to provide me with captions. But I'm not going to pretend that's zero-cost.)

> So "users do not want" actually makes no sense at all, and does not reflect the
> web. 

I'm opposed to user agent conformance criteria based on these sorts of overarching generalizations about the users of the Web want. Who are we to dictate to users, and the developers who serve them, what they want? Especially when the users and the developers are one and the same!

> > Either they take that requirement seriously, which takes time away from them
> > working on features that their users do want or (worse) it stops them building
> > the software in the first place.
> >
> 
> Oh, now, this is the real key, isn't? User agents would rather spend their time
> on gee wiz geegaws than on accessibility.
> 
> My answer? Tough.
> 
> If we use care in the text, there won't be an unreasonable burden on user
> agents. There won't be a case where audio only user agents have to provide
> access to text tracks, or the like. 
> 
> But when the device/user agent is capable of displaying something like text
> tracks for a video, the option must be provided.
> 
> The gee wiz geegaw can just wait a couple of days.

I think people who want to work on "gee wiz" features and do not want to work on the mandated functionality are going to work on the former regardless of the proposed spec text.

I think popular browsers will ship - and compete successfully in the market - regardless of whether they comply with W3C HTML.

> > Or (vastly more likely) they ignore that requirement, and treat the spec with
> > less respect for trying to place such restrictions on their free use of the
> > Web. If you train implementors to ignore conformance requirements, then you
> > encourage more fundamental lack of interoperability. If you destroy
> > interoperability, then you make it even harder to build tools that depend on an
> > interoperable substrate, such as WebAnywhere.
> >
> 
> Then they won't be in conformance, and can't brag about their "HTML5" support
> to the world, or folks will call them on it. 

Popular browser vendors will crow about their HTML5 support regardless and the odd person might call on it, but that crowing will not help accessibility at all. I don't know why people imagine it well help with HTML5 where it did not help with HTML4.

Browser vendors don't have a completist approach to standards support anyway. Heck Microsoft is already talking about their web engine as an "HTML5 engine":

    http://blogs.msdn.com/b/ie/archive/2011/06/29/site-ready-html5-second-ie10-platform-preview-available-for-developers.aspx

> But that's true of every last aspect of HTML5. It doesn't stop the spec from
> peppering "must" all throughout.

Sure, but MUST is reserved for the basic substrate of interoperability: how do you parse some bytes into markup, what order do you execute scripts in, etc. These MUST requirements are realistic to impose on user agent developers, because they help user agent developers avoid bug reports, not because they create new bug reports. Adhering to those requirements makes it easier to build user agents, including user agents with specific accessibility focuses such as Edbrowse or WebAnywhere. The MUST requirements are not some sort of tool for browbeating hapless UA developers into adding features to their product; they are a tool to help them build whatever features they like. That's ultimately good for end-users, especially end-users who want to participate in development. An interoperable substrate is actually a massive boon for accessibility development, since less time will be occupied reverse engineering basic web engine functionality like parsing HTML. By contrast, UI requirements do not reduce the need for reverse engineering, so they don't actually free up any developer resource.
 
> > In practice, since WHATWG takes a firm line on not mandating UI, since popular
> > browser implementors appear to be using the WHATWG spec as the basis of
> > implementations rather than the W3C spec, and since naturally implementors
> > pick-and-mix features to implement, the only real-world impact would be to make
> > the W3C spec more irrelevant. It's not like the W3C creating UAAG made popular
> > browsers actually implement UAAG. You need people involved in developing
> > browsers to agree that these features are important and implement them. If they
> > are, a SHOULD level requirement is more than enough *and* it protects us from
> > our inability to consider all possible circumstances.
> >
> 
> This is the W3C. The WHATWG has their own priorities, among which seems to be
> lack of interest in accessibility. Whatever. Accessibility is a priority for
> the W3C. 
> 
> We're not arguing about what's including in whatever document at the WHATWG.
> We're talking about what's in the W3C HTML5 specification.
> 
> Your statement seems, on first, read, to be almost a threat. That if the HTML5
> spec does mandate accessibility, the browser companies will basically have a
> snit and take their marbles and go home? I hope I'm reading your statement
> incorrectly. 
> 
> Are you saying that browser companies are that hostile to accessibility? 
> 
> Disturbing.

I do not believe WHATWG has a (particular) "lack of interest in accessibility" or that "browser companies are  hostile to accessibility".

I can't make a "threat" on behalf of browser vendors (I'm not even a browser developer!), but I can observe what is actually happening.

As far as I can tell, the frozen W3C version of the spec is already basically irrelevant to mainstream browser development (as ooposed to marketing), and was always going to be so, except as a source of patent protection. (Fortunately, HTML WG influences the WHATWG draft too.) People don't need to implement the spec to gain such patent protection.

Adding mandatory UI requirements will reinforce that irrelevancy to browser development, while making it a worse tool for the small number of conservative authors who read such specs and unrealistically expect them to describe features that have been widely implemented.

The only rationale for imposing such UI requirements is to try to force popular browser vendors to adopt them. Since this won't work, that rationale doesn't hold.

In so far as browser vendors are friendly towards accessibility we don't need this MUST-level requirement. In so far as they are apathetic about accessibility, it won't help much.

> I'm stating that HTML5 must meet the needs of a community of users, and among
> this community are those who have need of, and interest in, these accessible
> features.

Adding this MUST-level requirement won't do enough to help that.

> Accessibility is more important than something like WebGL, and a heck of a lot
> easier to implement--not to mention, more secure.

Statements about the importance of accessibility by W3C have close-to-zero impact on an individual FOSS developer who happens to want to work on WebGL rather than this context menu item or on a commercial vendor that thinks WebGL has more market importance. Section 508-style legislation, including requirements around audio description access, might have a little more impact on the later.

Writing spec text aiming to change developer or company action that shows a disregard for how developers or companies work is an inherently bad idea.

Creating UAAG techniques that can be cited by 508-style legislation and that a company seeking 508-compliance can apply to HTML5 would be a better use of the advocacy that is going into trying to cram mandatory UI into the HTML spec itself.
Comment 20 Shelley Powers 2011-08-13 20:04:16 UTC
> > However, this has nothing to do with whether user agents support this
> > functionality or not. 
> 
> I think whether or not content providers make use of the relevant semantics
> will have a *lot* more impact on whether user agents provide UI for it than
> spec text. There's a bit of a chicken and egg situation here, but not much of
> one, as it's so trivial for users to get access via a bookmarklet or addon.
>

That's the same as saying that the browser makers are abrogating any responsibility for accessibility to third party developers.

Rather callous and indifferent of them, if true. 

 
> > Accessibility is not market driven. 
> 
> I didn't say it was and I'm not sure what that means.
>

By this I mean you're not going to get millions of people demanding accessibility--you can't make implementation of accessibility be based on market demand.

Millions of people didn't demand handicapped parking spaces. They came about because society wanted to ensure that those who had mobility problems could access stores, shops, government agencies, and so on.

The same is true for closed captioning. The majority of people won't ask for it because they don't need it. I hope the majority of people do support efforts to ensure those who need assistive technologies have access to these technologies.  However, they won't necessarily put "support for closed captioning" as one of their top priorities when it comes to which browser or other user agent to use. 


> > What you're almost saying is that user agents like Firefox are lazy, and only
> > want to provide support based on market interest--leaving accessibility to
> > third party providers because, frankly, it can't be bothered to ensure
> > accessible media support.
> > 
> > Is this what you're implying? That a user agent like Firefox really can't be
> > bothered to ensure accessibility of the media? If so, then it becomes even more
> > imperative to ensure that the user agent, like Firefox, is given an additional
> > incentive to ensure it provides accessibility.
> 
> I think characterising an open software project like Firefox as "lazy" is a
> sort of category error, so no that's not what I'm saying.
> 

And Firefox is one of the better when it comes to accessibility--but it has a ways to go, that's for sure. 

> I don't think spec text in itself constitutes a strong incentive for user agent
> feature sets.
> 


Then why are the browser makers even involved in creating HTML5? 


> > > > In my opinion, too many user agents have demonstrated a mostly lukewarm
> > > > interest in supporting accessibility. It seems that user agents are more
> > > > interested in competing with each other over the latest gee wiz geegaw than in
> > > > providing accessibility. 
> > > >
> > > > After all, "BANG! SPLASH!" drives more news articles than something like
> > > > support for longdesc. 
> > > 
> > > Perhaps, but I think you'd be hard-pressed to demonstrate that popular user
> > > agents are worse in this respect than other large software projects.
> > >
> > 
> > But browsers are, most likely, the primary agents for delivering HTML5 media.
> > As such, ensuring they're accessible has a strong, positive impact in the
> > industry.
> 
> Spec text doesn't ensure anything. You're picking the weakest possible tool to
> influence a large and complex ecosystem.
>

But that's why folks are here, isn't it? 

I'm sure there are other efforts to influence software developers. But in this place, all we have is the HTML5 specification. 

 
> > > > Since user agents have demonstrated such lukewarm support, we need to up the
> > > > ante--make accessibility a conformance issue.
> > > 
> > > I disagree that baking MUST-level conformance requirements into the HTML spec
> > > is the right approach.
> > >
> > 
> > When it comes to accessibility, it's the only way.
> > 
> > To repeat: accessibility is not market driven.
> 
> I don't think spec text changes market forces, if that's what you're hoping.
>


Seems to me browsers are rather obsessive about their results in the ACID tests a while back. And they seem to also brag about support for this or that specification. 

If accessibility isn't a driving force in the market, "supports HTML5" is.

 
> > > > > Of course we want easy access to audio description tracks under normal
> > > > > circumstances in classic user agents like Firefox, Internet Explorer, Chrome,
> > > > > and Safari, but I object to trying to achieve that access by baking in feature
> > > > > set requirements for HTML user agents into the W3C HTML spec. I don't think
> > > > > it's an effective way to achieve such desirable results (historically it's been
> > > > > fairly unsuccessful), and promoting people's freedom to consume web content
> > > > > however they want (and build conforming user agents that allow them to do so)
> > > > > is (I think) more important. 
> > > > 
> > > > What does this have to do with ensuring accessibility? Seriously, what you just
> > > > wrote sounds noble, but how does providing accessible controls impede user
> > > > freedom to consume media however they want? 
> > > >
> > > > Just like with today's blu-ray players, people don't have to turn on subtitles
> > > > or captions. Just like with today's Kindle, people don't have to turn on audio
> > > > translations of books. This capability in no way impedes people's use of the
> > > > media.
> > > 
> > > You're potentially mandating people work on features that their users do not
> > > want or that they cannot provide.
> > >
> > 
> > Huge difference between "users do not want" and "cannot provide".
> > 
> > No one is dictating that user agents that "cannot provide" this capability be
> > forced to provide this capability. The text to make this clear could be
> > included in the UI section I mentioned earlier.
> > 
> > However, "users do not want" is, frankly, unacceptable. You're basing your
> > whole argument on accessibility being market driven, when, to repeat,
> > accessibility is not market driven.
> 
> I don't know what you mean when you say my argument is based on "accessibility
> being market driven"?
>

See above
 
> > There are some users that do want this functionality. In point of fact, when
> > you including subtitle support in with caption support, I believe you'll find
> > the majority of users want this functionality. But regardless, even if this
> > functionality is only useful for a smaller subsection of the user population,
> > it's _essential_ for that population.
> 
> If the content gets created, then users who want access to it will need a way
> to access it. It would certainly be preferable if that support was provided
> out-of-the-box by popular user agents on consumer devices. I don't think spec
> text has much influence on this.
>

Repeating same question: then why are browser companies even involved in HTML5?

 
> > Providing this support does not impact, in any way, on those who don't need
> > this support. Again, it's little different than a TV providing closed
> > captioning support: people can turn it on or off. Those who don't need it,
> > don't turn it on; those who do, do.
> 
> This clearly isn't true. Additional elements of UI increase cognitive load
> (making it harder to find the right item in a context menu or the right button
> on a remote control) and the amount of additional interaction (keyboarding
> through more items in a menu or turning off accidentally triggered captions).
> (Personally, I would like my browser to provide me with access to audio
> descriptions just as I would like my TV to provide me with captions. But I'm
> not going to pretend that's zero-cost.)
>

Funny, but the people who have provided custom JavaScript controls that do provide subtitle/caption support don't seem to have a problem with this. Maybe the browser companies can contract with the JS developers to help them work through the UI issues?
 

> > So "users do not want" actually makes no sense at all, and does not reflect the
> > web. 
> 
> I'm opposed to user agent conformance criteria based on these sorts of
> overarching generalizations about the users of the Web want. Who are we to
> dictate to users, and the developers who serve them, what they want? Especially
> when the users and the developers are one and the same!
>


And who are the browser companies to dictate to the blind and deaf that their needs aren't important, because people who aren't blind or who aren't deaf don't need the assistive technologies?


> > > Either they take that requirement seriously, which takes time away from them
> > > working on features that their users do want or (worse) it stops them building
> > > the software in the first place.
> > >
> > 
> > Oh, now, this is the real key, isn't? User agents would rather spend their time
> > on gee wiz geegaws than on accessibility.
> > 
> > My answer? Tough.
> > 
> > If we use care in the text, there won't be an unreasonable burden on user
> > agents. There won't be a case where audio only user agents have to provide
> > access to text tracks, or the like. 
> > 
> > But when the device/user agent is capable of displaying something like text
> > tracks for a video, the option must be provided.
> > 
> > The gee wiz geegaw can just wait a couple of days.
> 
> I think people who want to work on "gee wiz" features and do not want to work
> on the mandated functionality are going to work on the former regardless of the
> proposed spec text.
> 
> I think popular browsers will ship - and compete successfully in the market -
> regardless of whether they comply with W3C HTML.
>

To repeat the earlier question: then why are the browser companies even involved in HTML5?

It seems to me that the browser companies have an inordinate influence on HTML5 --to the point of disabling almost all accessible features. Yet at the same time, if I understand what you're saying correctly, the browser makers probably won't follow the text anyway.

There's a term I could use for the browser companies right now, that starts with "a" and ends with "es", but wouldn't be polite to include in a Bugzilla comment. 
 
> > > Or (vastly more likely) they ignore that requirement, and treat the spec with
> > > less respect for trying to place such restrictions on their free use of the
> > > Web. If you train implementors to ignore conformance requirements, then you
> > > encourage more fundamental lack of interoperability. If you destroy
> > > interoperability, then you make it even harder to build tools that depend on an
> > > interoperable substrate, such as WebAnywhere.
> > >
> > 
> > Then they won't be in conformance, and can't brag about their "HTML5" support
> > to the world, or folks will call them on it. 
> 
> Popular browser vendors will crow about their HTML5 support regardless and the
> odd person might call on it, but that crowing will not help accessibility at
> all. I don't know why people imagine it well help with HTML5 where it did not
> help with HTML4.
> 

But the popular browsers have always been the "good guy" in the past. 

Firefox is the "good guy" because it followed all the standards, while Internet Explorer did not. 

Well, if Firefox implements everything in HTML5 BUT accessible features...seriously, how long will it continue to have the "good guy" persona? 

This could actually be an extremely powerful tool to ensure compliance. Much more so than you're giving it credit. 


> Browser vendors don't have a completist approach to standards support anyway.
> Heck Microsoft is already talking about their web engine as an "HTML5 engine":
> 
>    
> http://blogs.msdn.com/b/ie/archive/2011/06/29/site-ready-html5-second-ie10-platform-preview-available-for-developers.aspx
>

But implementing most features but those having to do with accessibility is going to cast a rather ugly light on the browser companies, don't you think? I can't even imagine what this will mean from a legal perspective. 

PR nightmare.
 
 
> > But that's true of every last aspect of HTML5. It doesn't stop the spec from
> > peppering "must" all throughout.
> 
> Sure, but MUST is reserved for the basic substrate of interoperability: how do
> you parse some bytes into markup, what order do you execute scripts in, etc.
> These MUST requirements are realistic to impose on user agent developers,
> because they help user agent developers avoid bug reports, not because they
> create new bug reports. Adhering to those requirements makes it easier to build
> user agents, including user agents with specific accessibility focuses such as
> Edbrowse or WebAnywhere. The MUST requirements are not some sort of tool for
> browbeating hapless UA developers into adding features to their product; they
> are a tool to help them build whatever features they like. That's ultimately
> good for end-users, especially end-users who want to participate in
> development. An interoperable substrate is actually a massive boon for
> accessibility development, since less time will be occupied reverse engineering
> basic web engine functionality like parsing HTML. By contrast, UI requirements
> do not reduce the need for reverse engineering, so they don't actually free up
> any developer resource.
> 

That's where we differ: I'm all up for browbeating hapless UA in order to ensure they enable accessible features. 

Because it's a lot harder for a person being blind to get around on the web, then it is for some browser developer to implement text captions. In addition, the developer only has to implement the feature once--job done, pain over--but when you're blind, you're blind all the time.



> > > In practice, since WHATWG takes a firm line on not mandating UI, since popular
> > > browser implementors appear to be using the WHATWG spec as the basis of
> > > implementations rather than the W3C spec, and since naturally implementors
> > > pick-and-mix features to implement, the only real-world impact would be to make
> > > the W3C spec more irrelevant. It's not like the W3C creating UAAG made popular
> > > browsers actually implement UAAG. You need people involved in developing
> > > browsers to agree that these features are important and implement them. If they
> > > are, a SHOULD level requirement is more than enough *and* it protects us from
> > > our inability to consider all possible circumstances.
> > >
> > 
> > This is the W3C. The WHATWG has their own priorities, among which seems to be
> > lack of interest in accessibility. Whatever. Accessibility is a priority for
> > the W3C. 
> > 
> > We're not arguing about what's including in whatever document at the WHATWG.
> > We're talking about what's in the W3C HTML5 specification.
> > 
> > Your statement seems, on first, read, to be almost a threat. That if the HTML5
> > spec does mandate accessibility, the browser companies will basically have a
> > snit and take their marbles and go home? I hope I'm reading your statement
> > incorrectly. 
> > 
> > Are you saying that browser companies are that hostile to accessibility? 
> > 
> > Disturbing.
> 
> I do not believe WHATWG has a (particular) "lack of interest in accessibility"
> or that "browser companies are  hostile to accessibility".
> 
> I can't make a "threat" on behalf of browser vendors (I'm not even a browser
> developer!), but I can observe what is actually happening.
> 

Fair enough, it is your observation. Unfortunately, I'm observing much the same thing (though I must admit that a couple of browser makers do seem to be more concerned about accessibility than the others).


> As far as I can tell, the frozen W3C version of the spec is already basically
> irrelevant to mainstream browser development (as ooposed to marketing), and was
> always going to be so, except as a source of patent protection. (Fortunately,
> HTML WG influences the WHATWG draft too.) People don't need to implement the
> spec to gain such patent protection.
> 

Ha, just tell that one to Apple. 


> Adding mandatory UI requirements will reinforce that irrelevancy to browser
> development, while making it a worse tool for the small number of conservative
> authors who read such specs and unrealistically expect them to describe
> features that have been widely implemented.
> 
> The only rationale for imposing such UI requirements is to try to force popular
> browser vendors to adopt them. Since this won't work, that rationale doesn't
> hold.
> 

The only rationale for incorporating these requirements is because they're the right thing to do. 

> In so far as browser vendors are friendly towards accessibility we don't need
> this MUST-level requirement. In so far as they are apathetic about
> accessibility, it won't help much.
> 
> > I'm stating that HTML5 must meet the needs of a community of users, and among
> > this community are those who have need of, and interest in, these accessible
> > features.
> 
> Adding this MUST-level requirement won't do enough to help that.
> 
> > Accessibility is more important than something like WebGL, and a heck of a lot
> > easier to implement--not to mention, more secure.
> 
> Statements about the importance of accessibility by W3C have close-to-zero
> impact on an individual FOSS developer who happens to want to work on WebGL
> rather than this context menu item or on a commercial vendor that thinks WebGL
> has more market importance. Section 508-style legislation, including
> requirements around audio description access, might have a little more impact
> on the later.
> 
> Writing spec text aiming to change developer or company action that shows a
> disregard for how developers or companies work is an inherently bad idea.
>

You make it seem as this kind of support is an incredible burden. I've not seen any indication that any of this support would be an excessive burden on the browser companies.

It's not like we're asking for a secure WebGL or anything.
 
> Creating UAAG techniques that can be cited by 508-style legislation and that a
> company seeking 508-compliance can apply to HTML5 would be a better use of the
> advocacy that is going into trying to cram mandatory UI into the HTML spec
> itself.

But can't this happen in parallel? And again, that's another group, another organization.


This is a bug for HTML5, within the W3C's HTML WG. That's all we can control in this space.

I would say we're not going to agree, and I think we're beginning to repeat at this point--or at least, I feel I am. 

I did want to say I appreciated the thoughtful discussion, Benjamin.
Comment 21 Ian 'Hixie' Hickson 2011-12-02 17:27:28 UTC
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: Given that user agents aren't even required to offer a control to start or stop playback, requiring them to offer controls to show closed captions (even if, say, the browser in question has no screen!) makes no sense.
Comment 22 Mark Sadecki 2014-03-08 22:31:38 UTC
Discussed in HTML Accessibility TF Bug Triage Meeting on 26 Feb 2014
http://www.w3.org/2014/02/26-a11y-bugs-minutes.html#item05

RESOLVED to consider for HTML 5.1

Moved to HTML a11y Task Force component on 08 MAR 2014 for additional info.