W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > January to March 2006

Re: Key bindings... (user agents - was accesskey was ...)

From: Orion Adrian <orion.adrian@gmail.com>
Date: Wed, 11 Jan 2006 23:11:59 -0500
Message-ID: <abd6c8010601112011u47931314k4ef796795c6a87ea@mail.gmail.com>
To: WAI-IG <w3c-wai-ig@w3.org>

> I think, if there are any sites that are marked up in CSS out there with
> only elements as selectors, without IDs or CLASSs, they would be quite
> rare.  Most designers use these selectors to give power to their design
> implementation.
> There are two things that I can see to also consider.
> 1) User agents should be able to manage custom configuration of both the
> CSS hierarchy as well as the DOM hierarchy.  They have to raise their
> game to that level.  This may not completely solve the problem, but it
> should at least give the user more power to customise their experience,
> whilst at the same time not limiting the designer.
> 2) My second point is that web accessibility designers should not only
> understand WCAG, but they should understand the fundamental issues when
> designing for human computer interfaces so that their designs reflect
> the best interfaces for human interaction.  So to make a general point,
> a site designed properly by a web accessibility professional, using CSS,
> with whatever selectors they deem fit *should* offer a better interface
> to the majority of users, better than those with CSS turned off, and
> probably better than most custom CSSs, in most cases.
> If you manage to run a successful web accessibility business trying to
> design using only elements as selectors, let me know, I'd like to learn how.

I think I know what you're implying here, but I'm not certain. The
implication, to me, is that any site that uses more than simple
selectors (i.e. a single element), is going to be incredibly hard to
manipulate on the UA side.

So pretty much all sites use class and id.

As to your first numbered point, the DOM is something where each
change has a direct cause-effect relationship. Also the DOM doesn't
define UI behavior. CSS is incredibly hard to manipulate and requires
very advanced knowledge. While I admit that what you're talking about
may be possible, it seems to me the effort it would take far exceeds
the benefit.

As to your second numbered point, CSS is not a powerful tool. It's
expressiveness is very limited and therefore it takes a lot of
manhours to produce a quality design. If you're familiar with Jakob
Nielson's work, then you'll note that he talks about discount
usability. I call the solution to this problem usability by default.
It is important that whatever tools we produce, they produce
accessible interfaces and content by default. Much like I expect any
RAD tool to produce bug-free content. I understand they're not the
same thing, but developers have had tools built with accessibility in
mind for many years -- but just on the platform, not on the web.

Also I make a third point. It is impossible to produce a user
interface that is accessible on all devices. Every device is different
and the amount of energy needed to produce accessible designs for all
the devices it could be viewed on is, in my opinion, unacceptable;
again, from a discount usability point-of-view.

A better, solution in my mind, is to move the accessibility work as
much as possible to the UA. Let the UA handle key bindings, widget
selection, and all other factors that are best determined on the
client. Let the content authors only worry about saying what they

To let my efficiency expert side come out a bit: there are billions of
web pages and probably less than a hundred UA's. Things that don't
have to be authored or designed on the content side shouldn't be.


Orion Adrian
Received on Thursday, 12 January 2006 04:12:03 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 13 October 2015 16:21:33 UTC