RE: "Pave The Cowpaths" Design Principle

Maciej Stachowiak wrote:
> 
> 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.

Minor (but potentially significant) point here: in current (Windows)screen
reading configurations, the title attribute is governed by the verbosity
setting - Experts settings (minimum punctuation read aloud) in JAWS and I
believe WindowEyes also silences the title attribute.  This is why
accessibility people keep saying that if the message is critical, you can't
hide it in the "tooltip".  So your statement above is actually not 100%
correct.


> 
> 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.

I invite you to re-read much of the "Cowpaths" thread.  There is an implied
undertone that if it's not already being used (or if something is being
under-used), it should not be considered.  A review of one of your IRC logs
also leaves that impression... (hint: @profile)


> 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>. 

Fair enough.  I do not currently believe that enough research has been put
forth that qualifies @class over @role in any meaningful way.  "We" keep
getting asked to prove our assertions, but that must be a two way street.
Currently it doesn't feel that way.


> 
> 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.

Fine, then tell me how you can work around this: <span
class="copyright">built using a stupid WYSIWYG</span>?  Jukka and others
have pointed this out in the wild, and it is as much a problem as
<...title="20070515">.  You had to chuck that out because it's broken, and
so?...  

This may make some unhappy, but if you go this route, others will be unhappy
as well.  As you said, it is a balancing act, but ensuring accessibility
*must* trump a bit of extra work and some developer unhappiness.  As for
accessibility requirements being ignored - perhaps in some circles, but
certainly not in others.  There are already laws in place that will put that
problem to rest.

The problem boils down to this - some knowledgeable developers *did* use and
respect meaningful semantic class names, but many, many didn't.  And CSS
@class selectors have been much more widely deployed than microformats -
hell Brian Suda and Tantek Celik are still out giving "microformats 101"
talks weekly (it seems).  So, rightly or wrongly, class="" has morphed into
a display selector due to poor user knowledge.  This, in and of itself,
isn't bad, but it puts the accessibility consideration into a tight spot; if
you are stating that class="" also conveys a semantic construct, but half
the time it doesn't, then it's broken before it even gets a chance to get
started.  So while the knowledgeable developers might have been doing the
right thing, the evolutionary process of @class sidetracked this, and has
polluted the ideal.


> 
> 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.

But we (I!) continue to argue that the @class solution is already broken, so
you really can't count on that.

There has been suggestions that adding a prefix or other qualifier to the
@class attribute could solve this problem, but it does not take into
consideration any kind of scalable solution - currently @class names can be
made up by anyone, for any reason.  This isn't bad, but it removes any form
of standardization - heck it reminds me of my old accesskeys battles -
anyone could declare any old key to do any old thing, that was one of the
biggest problems - there was no standardization, and further, no way to
define your non-standard choices.  And while the spec may in fact emerge
with a fixed list, what if that list is lacking?  This to me is a major
shortcoming, and one that @role has already addressed (I do not believe that
a microformats type approach is strong enough to handle the task, but I am
willing to listen). It may not be perfect, it may not be in a means that
everyone agrees with, but it already exists, so pave that cowpath too.


> 
> 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.

Well, "role" is also a pretty semantic name for what it is supposed to do,
which makes it easier for the accessibility advocates and trainers to
deploy.  

For this to work will require not just the means, but the education on how,
why, when, etc.  The accessibility community is used to this need for
outreach and education, we spend a lot of time at it already, and so an
easy-to-grasp conceptual name like "role" makes this task easier for us to
accomplish.  It's a whole new "thing" to learn, as opposed to re-learning
about @class - too many under-informed designers will think they already get
it, and do it wrong.  I realize that this has nothing to do with "code", but
it is a significant consideration in the larger context.

> 
> 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.

<snip of some pretty reasoned and reasonable use-case studies>

The thing is, currently @role is being used (tentatively) for UI elements,
and in the context of accessibility.  This is why I suggest that @role can
continue to be the "carrier" of other accessibility solutions - it has not
suffered the same fate of mis-use that @class has.  How much over-loading of
@class do you think is going to happen?  If examples from the wild are any
indication, probably not very much, and more often than not possibly
wrongly.

> 
> 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.

This is probably the best news I've heard on this list for some time.
Remember however that the semantic issues under discussion transcend simple
AT solutions - there is also the cognitive impairment impacts that good
semantic conveyance will address - a huge boon for one user-group that for
so long have continued to miss out on much of what the web can offer.

> 
> 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.
> 

Maciej, this is a fair request.  It would be helpful if members of the
working group refrain from incendiary and dismissive remarks, and try and
understand that the rules of engagement are shifting here.  It would also be
helpful to realize that when numerous accessibility advocates with long and
established precedence and pedigree are all saying the same things, that
maybe, just maybe, we *do* know better, as this is our area of expertise. I
by no means wish to become spokesperson for any group - everything I have
written has been my perspective and opinion, but the emails of support I
have received lead me to believe I am saying what a lot of others are
thinking.   Trust is a two-way street, and if we say we know you need curb
cuts, you have to trust  that we know what we are talking about.


> 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.
> 

This might be helpful, but much of what has come before has focused on
"semantic" intent.  A lot of this came from the discussion of <i> vs. <em>.
I personally think that <em> has more semantic weight, but either are poor
carriers of real meaning: they both essentially create a visual rendering, a
point T.V. Raman made about a week ago.  A more useful exercise would be to
figure out how to convey emotional intent, or differences in typographic
norms, etc.  Building upon your examples:

1) <p>Do you <em role="ax:tone:suggestive_playfulness">really</em> want to
hurt me?</p> (Boy George)
    (this might also be a conveyance of irony... it's tricky.)

2) <p>Do you <em role="ax:tone:forceful_enquiry">really</em> want to hurt
me?</p> (Movie Script)
3) <p>Do you <em role="ax:tone:shocked_surprise">really</em> want to hurt
me?</p> (Movie Script)
   (granted 2 and 3 are very nuanced, but reach for the stars, settle for
the moon)

4) <p>His insurance covered everything except <dfn="" lang="fr"
role="ax:legal_term" class="italics">force majure</dfn> occurrences</p>
(and yes, I've seen class="italics" in the wild -
http://b00mb0x.org/front/001161.html - broken no less...)

5) <p>The California poppy (<i lang="lt"
role="ax:genus:botanical">Eschscholzia californica</i>) is native to grassy
and open areas...</p>

Not saying that this is right, or the right way, but this is one of the real
needs that I see, that is currently lacking.  I honestly can't see how this
can be done with a fixed dictionary, unless it is a very large one, but I'm
willing to listen.  I am doubly curious to hear how a microformats type
mechanism can address this, as I don't think it can completely - and
half-fast is no good


> 
> 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.
> 

Uhm... Providing the right kind of info to THE USER, regardless of the
tool(s) they may choose to use.

JF

Received on Wednesday, 16 May 2007 01:08:06 UTC