- From: Maciej Stachowiak <mjs@apple.com>
- Date: Tue, 15 May 2007 14:30:50 -0700
- To: John Foliot <foliot@wats.ca>
- Cc: 'Gervase Markham' <gerv@mozilla.org>, public-html@w3.org, www-html@w3.org
Hi John, On May 15, 2007, at 12:36 PM, John Foliot wrote: > Maciej Stachowiak wrote: >> >> The principle is about author practices as found in existing content, >> not about what tools currently do with that content. However, >> contrary to your assertion, many microformats-based tools extract >> semantic information from class names in web pages. > > While this is true, the date-time issue in microformats remains, > with no > clear solution in place. I asked Tantek about this personally, and > there is > no answer: currently we can use a CSS workaround to hide the title > attribute > information (most of the time), but that is not a very elegant > solution. The <abbr> date-time pattern is indeed problematic. The @title attribute is exposed as a tooltip and via accessibility tools, but it is in a machine-friendly rather than human-friendly format. The current HTML5 draft contains <time> to cover this use case instead. <http://www.whatwg.org/specs/web-apps/current-work/#the-time> This is why the principle is phrased as "consider". Sometimes an existing practice really does cause problems, and we need to provide a better alternate solution instead. > This is probably the most telling of potential issues when it comes to > repurposing content; what assurances do we have that repurposing > @class for > "semantics" will not cause any other unforeseen breakage? The > discussion > around class="copyright" must cause some concern. (It should!) I think the very microformats experience you cited shows some evidence that using @class for defined semantics doesn't cause significant breakage. While the <abbr> date-time mechanism has well- known problems, I don't know of any reported with class. > Let me pose another question: There seems to be this almighty > driver out > there that says that the market knows best, yet most of the > accessibility > advocates have always worked from the perspective that we must not > stray > from published standards (standards are what makes things inter- > operate) - > this is why we have no "in-the-wild" examples for the types of > enhancements > we are seeking. Sure, it's not a fair standard to say something must already be in use to be added to the standard. But I don't think anyone is requiring that. The question comes up when you have two possible ways to solve a problem, one using an existing mechanism, and one using a new mechanism. I think it's reasonable to give the existing mechanism all due consideration, to avoid bloating the language. But sometimes that doesn't work. Examples in the HTML5 spec where current solutions were not considered good enough (for accessibility and other reasons) and so new features were added include <time> and <video>. > If between now and the ratification of HTML5, a group of > individual content authors forged off on their own (similar to > microformats) > and started to use something like @role for the type of semantic > application > I have expressed (and I have a few emails of support for this > already), and > started to get this out into the wild... Would this not then be a > cow-path? > After all, Firefox is already giving some support to @role, and > building a > Firefox extension that used this type of "micro-data" would be no less > difficult that the current crop of Firefox microformat extensions... I think you're giving undue weight to only one of the listed design principles. It's all a balancing test. We have to start from the use cases and think about the best solution. Let's say our problem is: "mark elements with one or more out of an extensible set of semantic markers, where some may have a shared predefined meaning." We can solve it in the following ways: 1) Standardize the existing uses of "class" for this purpose, including possibly some predefined values in the spec and extensibility via a microformats-style approach. 2) Forbid the use of "class" for this purpose, and add "role". 3) Standardize on the use of "class" and also add "role". 4) Ignore the problem and allow ad-hoc solutions to develop. I think option #2 would make microformats advocates unhappy, and would be basically ignored. It's unreasonable to ask that already widely deployed semantic markup be changed, and to ask that data extraction tools ignore it. This could only make sense if we discovered major problems with this kind of use of class that we can't readily work around. Option #4 would be problematic as well - clearly there is a great demand for this kind of capability, given that there are at least two independently invented solutions. So basically we're down to #1 or #3 - which is a choice between having one mechanism and having two mechanisms to solve the same basic problem. I hope you can see why there is a pretty high bar for @role then - it has to provide strong enough advantages to justify adding a second mechanism to solve basically the same problem. I actually understand why the name "role" is somewhat comforting to accessibility advocates, based on how Apple's VoiceOver screen reader works and how it hooks into Safari. It is often desirable to express the purpose of a UI element in a succinct way, relying heavily on predefined values, to allow indirect control to visually impaired users. However, at least for VoiceOver purposes, what is desired is exactly one role, and it should be very strongly biased towards using a predefined value for best effectiveness. I actually think this kind of accessibility mechanism can be built based on elements and class names. For example, some common roles used in Apple's screen reader are "Button" "Checkbox", "StaticText" and "Link". Now, clearly, "Button" can be inferred from the <button>, <input type="button"> and <input type="submit"> controls. But for <input type="image"> it's less clear; and sometimes you have just a random element with an "onclick" handler that acts like a command button. For cases like this, it would be really great to have a mechanism where the common cases work with no extra markup, but the markup options exist. Things become somewhat more complex when you have higher-order UI elements, such as navigation links or calendars. Let's imagine what a mechanism based on these premises might look like. Particular elements (or particular elements with certain attributes) would have predefined roles. And we could define a set of extension roles, perhaps using a naming convention for class names, and likely with the requirement that an element may only explicitly define one primary role, with perhaps subroles available). What roles would we infer for various elements? Some possible predefined roles: <input type="button"> --> role = button <input type="text"> --> role = button <button> --> role = button <input type="text"> --> role = text-field <a href="http://example.com"> --> role = link <p> --> role = static-text <p onclick="alert('foo')"> --> role = button (let's assume anything with a static default role and a click event listener is a button unless it says otherwise) <nav> --> role = nav Explicit override of role: <img onclick="location.replace('xxx')" class="ax:link"> --> role = link (it's a bad practice to use an onclick handler to get link-like behavior but at least this way AT can understand what is going on) <a href="javascript:doSomeScriptAction()" class="ax:button"> --> role = button (it's a bad practice to use a link as a button but at least this way AT can understand what is going on) <img onclick="toggle(this)" class="ax:checkbox"> --> role = checkbox <div class="myjslib_datepicker ax:calendar"> --> role = calendar I'm just making up these "ax:" prefixed class names - perhaps they would be fine unadorned, or maybe an underscore is better than a colon, whatever. "ax:" is not a namespace prefix, just a purely text- based part of the name. This kind of approach has a few nice properties: 1) Just building your web documents and applications using the semantically correct elements will result in pretty good accessibility by default, but you can fine-tune your app to give even better accessibility definitions for the edge cases. Apple's accessibility experts used this kind of approach in designing the built-in accessibility support in the Carbon and Cocoa toolkits, and in extending this support to Safari. This is a very strong advantage because no matter how many laws we pass or how much we educate developers, many casual developers will not think very hard about accessibility. 2) It's still possible to fine-tune accessibility to do even better than the default, but content authors can focus on the parts of the page that need specialized handling, rather than having to mark up everything. 3) You can easily trigger styling, "unobtrusive script" late-binding, microformat data extraction, and in the future XBL2 binding all based on the same mechanism of "class". I'd like to claim this kind of approach is original but in fact an existing W3C editor's draft recommends something similar, at least as far as explicitly declared roles go: http://www.w3.org/WAI/PF/adaptable/HTML4/embedding-20060318.html I'm definitely going to try to learn more about accessibility and assistive technologies from the accessibility experts at Apple. Since Apple ships both a browser and a screen reader, the intersection of the two areas is of great interest to us. In exchange, however, I wish accessibility advocates would engage with the process with a focus on use cases and how we can best address them, rather than just the particular mechanisms invented partly for accessibility. It's unhelpful to assume that anyone who dislikes your proposed feature is against accessibility. They may simply have a different view on the best way to address them. Anyway, if this kind of approach seems like a good idea, I'd be happy to work up a more detailed version that also covers state (checked vs. unchecked, slider position, text contents and caret position of a text control or contentEditable area) and other such things. > At what point is "adoption" considered a de facto solution? If, for > example, a collective of major universities started to use this > proposed > solution, would that suffice? If some government agencies also > started to > use this construct, what then? The numbers might be small, but the > significance of the content might over-ride the volume issue. We > need data > on this too - you want us to play your rules, your game, then spell > it out: > we expect no less than an even playing field. I'd really prefer if we could focus on designing a good technical solution rather than the name of the attribute. After all that is what matters ultimately - providing the right kind of info to accessibility tools. Regards, Maciej
Received on Tuesday, 15 May 2007 21:57:51 UTC