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

Orion Adrian wrote:

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


Not quite.  The only way I know to make sure a user CSS maps 100% to any 
given CSS is that there are only selectors based on elements.  How is 
the user going to know the names of the IDs and CLASS to map their CSS?  
Unless the designer follows a convention of #header, #content, #footer, 
#sidebar.  It's really becoming hit and miss after element selectors.

The best way I see around this is that the user CSS overrides 
everything, and ignores all other selectors, but this leaves the 
designer subject to random assignments of their design.  If they have 
followed all the basic principles of usability and accessibility, then 
maybe that's the best they can offer.  Would be interesting to see some 
case studies in this area.


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


Manipulating the DOM can enhance the user experience, but it can also be 
one of the greatest causes of creating bad UI behaviour.

I generally go by a run of thumb, to develop the structure and the 
presentation of a site from from any DOM programming, and only added it 
where it really is of benefit.  It's also my approach to economics of 
web development.

The DOM has really been abused, and still is, but on the other hand, web 
development really needs some real show cases out there of how to 
program the DOM showing best of practice of accessibility and usability, 
and there are people out there that are doing that.

We need to do that to move forward with SVG, AJAX and the like.  There 
are issues, but really well developed dynamic web pages can enhance 
usability, at least.  And bad ones definitely degrade it.

There are plugins for both IE and Firefox that manage different branches 
of the DOM tree, but I think this needs to become native to the whole 
user agent, rather than managed by plugins.  If you install too many 
extensions in Firefox it really slows it down as the runtime of XUL is 
never going to be as fast as native compiled code, IMHO.



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


I don't completely agree with that.  I will admit that one needs to 
invest a lot of time learning CSS, especially if you want to learn it 
from the perspective of focusing on accessible design principles using 
relative units and so on.  I think CSS is powerful, and I think 
http://csszengarden.com/ showcases that power.  Maybe we have a 
different definition of power.

My own CSS knowledge is only middle, but most good designers know it 
well enough to be very efficient with it.  There is a lot of evidence to 
show reuse of code, and a design can be radically changed with minimal 
coding changes.  Just look at the repository of templates that are 
appearing all over the place.

http://oswd.org/
http://cssliquid.com/
and the WordPress and TextPattern templates

Also, I think http://webpatterns.org/ is pointing in this direction.


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


Maybe this is true to some extent, but I do think there are others out 
there that have some pretty good strategies to tackle this problem.  
Unfortunately I haven't kept up with this.

I often feel the W3C are out of control in this area in that there are 
so many platform specific implementations coming up, that the only way 
you can build a system to serve up all this content according to correct 
specifications to multiple devices is to have one mother of a CMS.

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


Yes, I think so.  But there is also a big problem here, in that many 
people are completely unaware as to how much power they already have 
within their user agent to customise their browsing interface.

The other problem is educating clients, trying to take their design 
elements and make them more user friendly.  This is the hard work, 
educating people.  Even mainstream designers, they often have no clue of 
these issues.  People are so attached to their little design, they want 
it to have all the bit mapped features.  Even if you do a 100% CSS 
representation, and you tell them the benefits of this improved design, 
and how much more accessible and usable it is, they don't like that 
other people can override their design.  They want it 100% fixed so that 
there is out and out gaurantee that the user will see their design as 
they intended.  I don't know about you but I get this about 90% of the 
time dealing with clients.  Even to those clients who you'd think 
accessibility is a key requirement. :-(


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

I don't completely agree with that as I stated before, a designer with 
good awareness of standards, usability and accessibility will more than 
often offer an enhancement in their site of all these principles, rather 
than serving up a site without styles or left to the user.  That is the 
role of a good designer IMHO.  Maybe your experience is of the opposite 
and it may be quite valid.

--------------------
Geoff Deering
(one day I'll get a SIG)

Received on Thursday, 12 January 2006 06:39:32 UTC