- From: <bugzilla@jessica.w3.org>
- Date: Sat, 13 Aug 2011 16:36:24 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13436 --- Comment #18 from Shelley Powers <shelleyp@burningbird.net> 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. -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug.
Received on Saturday, 13 August 2011 16:36:29 UTC