Re: <span> within a word any issue for screen readers?

Patrick H. Lauke wrote:

>
> Geoff Deering wrote:
>
>> Yes, I agree.  The accesskey is assigned to the A element, the SPAN 
>> is just serving as a non structural element as a visual indicator 
>> that there is an accesskey assigned to that link.  It's following the 
>> GUI  standards of assigning accelerator keys to menuing functions.
>
>
> Is this not something that should be left up the user agent to 
> implement, with its own algorhythm of "if there is an accesskey, go 
> through the link text (if any), find the first occurrence of the 
> letter matching the  accesskey defined, and visually (and 
> structurally, aurally, etc) distinguish it from the rest of the text" 
> (even based on user settings, where a user can choose whether or not 
> she wants that kind of highlighting)? Incidentally, this is what 
> happens in XUL: you define the accesskey as an attribute, and the 
> platform itself takes care of the visual underlining).


I think there is more discussion needed on this.  I think it's the 
correct approach, but the world of hypertext throws up more random 
values than the world of GUIs, and that could end up being counter 
productive as it would then impact cognitively.

In the world of GUIs we tend to have pretty standard sub sets of 
accelerator keys F for File, E for Edit, V for View, H for Help etc.  If 
the user uses a few applications they can easily learn the accelerator 
keys for that application and become very productive in it.  For 
instance, I have often heard it said that a developer who uses VI with 
it's focus on accelerator keys can be far more productive in moving 
around the code/text than a developer with a GUI/mouse IDE.

So in hypertext environments, as you suggest, the assignment would be 
quit random.  If on one page their was a link "accessibility" followed 
by "about", "accessibility" would be assigned "a" as accesskey and 
"about" would be assigned "b".  The user then goes to another site where 
the order is reversed and "about" is assigned "a" and "accessibility" is 
assigned "c".  Now we have a usability problem caused by the randomness 
of this implementation.

Still, this approach does leave an openning for the user to assign 
preference to the way the system assigns accesskeys, therefore taking 
the issue away from the designer/developer and putting into the hands of 
the user agent and the client's preferences.  But we are a long way from 
seeing this level of user agent functionality.

I agree that this is technically the better implementation, but for all 
it's good intention I think accesskeys in hypertext are difficult to 
implement properly as the media is not really suited to it.  I have to 
agree with the general John Foliot principle of avoiding accesskeys, 
with the one exception of heavy web form based Intranet applications.


>
> I fear that advocating use of span to underline accesskeys is moving 
> us back towards using markup for presentation.
>


Yes, I agree with that, in principle.  I dream of simple markup with no 
DIVs, but I'm afraid it's not real.


-------------------
Geoff Deering

Received on Monday, 9 January 2006 22:07:16 UTC