Today on the WSG mailing list, Andy Budd asked:
Here’s a quick (and probably stupid) accessibility question regarding screen readers.
<label><span>S</span>earch</label>
I assume the a screen reader will read this out as “Search” and not “S earch”.
Patrick H. Lauke answered:
Tested with JAWS 4.02, and yes, it reads it as “search”.
That’s not to say, though, that all screenreaders behave this way…
Let me guess…underlines for accesskeys? [...] One thing that worries me about doing those sorts of things is that the result is very…non semantic. Not sure how, say, search engines would react to seeing Words broken up like that.
And of course Patrick is right, Google and the like might not see the word as intended. So instead of hand coding the span for each link, why not use some DOM scripting to do so? I had a go, see Dynamically underlining accesskeys in my sandbox. In some ways this could be using JavaScript to increase accessibility, or least stop mark-up getting in the way.
Accessibility · DOM | JavaScript
Bruce Boughton wrote:
Wow, that’s neat. The DOM seems very powerful and can be used increase accessibility if used correctly.
However, I worry. Do textual browsers such as Lynx support accesskey? If they do, since they don’t support Javascript, doesn’t this method leave them in the dark as to the accesskeys? Of course, if they don’t support accesskeys then my concerns don’t apply.
ACJ wrote:
I’ve used <kbd> in the past (since an accesskey is a key to be pressed by the user), but I see your point with search engines and the like. I like your DOM solution a lot, and will consider using similar methods on future projects. Thanks!
Patrick H. Lauke wrote:
“nice one our kid” as they say up here.
“doesnt this method leave them in the dark as to the accesskeys? ”
this is where i start ranting about how it should be the browser’s responsibility to expose things such as accesskey information (as well as, say, the presence of a longdesc on images, etc) to the user in a sensible way. in an ideal world, IE would behave in a similar way to what it already does with menus when you hit ALT…it should give you a hint as to what accesskeys are defined. it should also honour the system setting that tells it to keep shortcuts visible even when ALT is not pressed.
but i digress…
Patrick H. Lauke wrote:
additionally, as an aside in terms of search engines: in the footer of my site, i have the dictionary definition for “redux” (my sad online alias). the definitin calls for a bullet between “re” and “dux”. in order to try and coax some ranking for the full term, i’ve resorted to using a title on the enclosing element. here’s the markup in full (notice the title on the dt):
<dl>
<dt title=”redux”>re•dux</dt>
<dd>(<abbr title=”adjective”>adj</abbr>): brought back; returned. used postpositively. [latin : re-, re- + dux, leader; see duke.]</dd>
</dl>
Andy Budd wrote:
Rich you smartass :-)
I hope you’re going to use this for your SkillSwap next month.
Sage wrote:
Holy cow Your article made me just realize that Safari now supports accesskeys! When the hell did that happen? (For the longest time, Safari didn’t have support for ‘em, but now, suddenly…)
Phil Baines wrote:
Good work Richard! I love it. If only I had seen this a month ago, then I would have been able it on a site that I just signed off on!
I am very impressed anyway! keep it up!
Derek Featherstone wrote:
A nice technique Richard, but… why letters for accesskeys? I realize its convenient for this script, but wouldn’t it be better to do something that uses numbers to stay away from all the conflict letters bring about?
Lenny Domnitser wrote:
Bruce Boughton wrote:
“Do textual browsers such as Lynx support accesskey? If they do, since they dont support Javascript, doesnt this method leave them in the dark as to the accesskeys?”
AFAIK, Lynx does not support accesskeys, but this javascript method is no less accessible than hardcoding it into the markup. This method does not add accesskeys, it merely adds spans. Spans have no meaning-they exist solely to apply generic attributes to them (class, style, lang, etc.) and to wrap text for styling. In this method the spans are used to be highlighted by CSS, which Lynx also ignores.
Gavin Montague wrote:
Just beat me to it! I was in the middle of writing a worse version of this script when I saw Simon Willsons link to you.
One small improvement I’d suggest…..
var lowertext = linktext.toLowerCase();
var keypos = lowertext.indexOf(accesskey);
thus
<a href=”#” accesskey=”a”>A link</a>
will be underlined correctly even though the accesskey [a] doesn’t appear in the link.
Top stuff though.
Joel VanAtta wrote:
Call me naive, but couldn’t you use CSS and the :first-letter attribute?
Bruce Boughton wrote:
What if you’ve got two accesskey-ed links beginning with the same letter, Joel? In that case, the first-letter would be insufficient.
jgraham wrote:
> this is where i start ranting about how it should be the browsers responsibility to expose things such as accesskey information
You might appreciate my (alpha!) Firefox extension: http://www-jcsu.jesus.cam.ac.uk/~jg307/mozilla/extensions/accesskeys.xpi It displays a sidebar with the accesskeys defined in the current document and makes some atttempt to extract a description from the HTML . The success of this is somewhat variable – there are known issues with forms (forms are hard because the useful descriptions are often n different elements to those where the accesskeys are defined). It also sucks if my assumptions about how useful different elements and attributes are as a source of accesskey description are different to those of the author (e.g. on this page (element ‘title’ attributes should be descriptive!) ).
Bug reports are much appreciated (but may not get immediate attention;) )
Geoff Vines wrote:
I came to this article as a result of Patrick Lauke’s posting in Sitepoint re accesskeys and underlining.
I am already doing the reverse of this but it had not occured to me that there might be some value in placing them programmatically as well.
What do I mean by the reverse of this?
My navigation is loaded as an include file at the server, and yes I know I could take care of it at the server but I don’t. It’s been my philosophy to grey the link of the current page and de-activate it so you don’t have people clicking on a link for the page they are already on.
If you want to see this in action, have a look at my web site, http://1ontheweb.net and feel free to view the associated JavaScript file, http://1ontheweb.net/1otw-2.js
Toni Ivanisevic wrote:
:) its funny.
today i found your “Dynamically underlining accesskeys” posting at your blog. because i wrote a underlining accesskeys-function, that do nearly the same but it chekcs button- and label-elements, too.at: http://www.tonitone.com/javascript/underline-accesskeys-10/trackback/
bye
tonitone