RE: the market hasn't spoken - it hasn't bothered to listened [was Re: fear of "invisible metadata"]

Henri Sivonen wrote:
> 
> I wasn't referring to any particular language feature. I was saying
> that we should be informed and even be swayed by how markup gets used
> in practice even if you consider the usage "poor". It would be
> foolish to ignore actual usage.

Based upon this thinking, automobiles 25 (or so) years ago should never have
installed seat belts... 'cause even when they were installed, hardly anyone
used them.  This is a "rump-forward" way of thinking: just because current
usage is poor is not a reason to continue to advocate and support
accessibility enhancements.  Accessibility considerations cannot be driven
by numbers alone - and many laws in many lands say just that.

> 
> There's a big difference in installing curb-cuts as part of the
> routine paving work and chiseling them in afterwards. Installing them
> as part of the routine is relative cheap while chiseling them in
> afterwards is relatively expensive.
> 
> If we apply the curb-cut analogy to HTML, the conclusion I draw is
> that we should move to markup with built-in accessibility roles as
> part of the routine authoring process instead of advocating after-the-
> fact chiseling with role=''. That is, we should push <progress>
> instead of a bunch of divs and spans with role='wairole:progressbar'.

But what is the difference really?  Adding a whole slew of new elements
(with the learning curve involved there), or adding a universal attribute
such as @role, that can be incorporated into many of the basic elements
already being used (the notorious paved cow paths)?  WYSIWYG editors then
can expose the ability to enter the appropriate role perhaps from either a
dropdown list of standard roles, or with the added ability to "custom"
create.  We currently have *today* (on my cow path of life) WYSIWYG editors
that allow similar functionality with CSS.

> 
> I'm not making market *share* arguments. I'm arguing that we should
> be informed and potentially swayed by how markup features are used in
> practice. That is, how they are doing in the "market". Pretending
> that the design accessibility features cannot fail when exposed to
> the people out there (i.e. the market) makes no sense.

Neither does *not* including the ability to do so, simply due to poor usage.
This is where the fundamental difference lies between the two "camps":  Many
of the HTML WG contributors are talking in terms of lowest common
denominator, where-as the accessibility advocates are pleading to reach for
the sky.

What I cannot understand is how the camp that pushes for new and advanced
HTML code such as <canvas>, (which is currently experimental or proprietary
at best) see no issue with pushing these advances forward (even though their
current usage is, shall we say, poor at best); yet when the accessibility
camp asks for the same types of considerations, they are constantly argued
down due to either "complexity" or lack of general usage today.  To my mind
and point of view, this is a double standard, and one that has not yet been
satisfactorily addressed.  Nobody is forcing anyone to use @role, any more
than they are being forced to use <canvas>: *you* might want <canvas> for
your perceived needs, I want @role for my perceived needs.  Why should my
needs have any less sway than yours?  "Paved cow paths", lowest common
denominator, current market usage - IMHO it's all the wrong way of thinking,
especially when it comes to accessibility features.

JF

Received on Monday, 25 June 2007 18:34:35 UTC