- From: John Foliot <john@foliot.ca>
- Date: Tue, 18 Sep 2012 15:19:05 -0700
- To: "'Maciej Stachowiak'" <mjs@apple.com>
- Cc: "'Sam Ruby'" <rubys@intertwingly.net>, <public-html-a11y@w3.org>
Maciej Stachowiak wrote: > > But I do note that it seems to be back in the mode of > "mandate something that browsers won't implement". I will note that currently, we have at least 3 instances of native implementation by browsers (Opera, iCab, IBM HomePageReader [no longer produced or maintained by IBM]), that Firefox *does* expose @longdesc to the Accessibility API, and that at least 3 market-significant screen reading technologies (JAWs, WindowEyes and SuperNova/Hal) also provide support *across* different browser offerings. - http://www.w3.org/html/wg/wiki/ChangeProposals/InstateLongdesc/Implementatio n I will also note that according to the emergent HTML5 CR Exit Criteria (http://lists.w3.org/Archives/Public/public-html/2012Aug/0294.html), the litmus test for this 'feature' is already met: "For this specification to be advanced to Proposed Recommendation, there must be at least two independent, interoperable implementations of each feature. Each feature may be implemented by a different set of products, there is no requirement that all features be implemented by a single product." We have independent implementations, we have interoperable implementations, and they are achieved using different sets of "products", (defined as "Web browsers and other interactive user agents"). It is beyond the W3C to force any commercial company to do something that they are philosophically opposed to doing, but I posit that using that philosophical stance to frustrate progress by other vendors is antithesis to how the W3C operates. This is not mandating any one browser to do anything, it is simply recognizing facts in evidence. JF
Received on Tuesday, 18 September 2012 22:19:39 UTC