- From: <bugzilla@jessica.w3.org>
- Date: Sat, 13 Aug 2011 15:59:59 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13436 --- Comment #17 from Benjamin Hawkes-Lewis <bhawkeslewis@googlemail.com> 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. -- 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:00:04 UTC