Re: "Pave The Cowpaths" Design Principle

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:58:09 UTC