- From: <bugzilla@jessica.w3.org>
- Date: Sat, 13 Aug 2011 20:04:16 +0000
- To: public-html-a11y@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=13436 --- Comment #20 from Shelley Powers <shelleyp@burningbird.net> 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. -- 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 20:04:24 UTC