I have a simple nav bar, I’m using random access keys I’ve assigned that best suits the link, my question is… is this wrong and should I be following some sort of standard? Should I be using numbers?
a - about
s - our services
g - gallery
b - bookings
There’s your answer; generally there is no “official standard” due to conflicts with various software, and Operating Systems key assignments, etc. Although ‘Numeric Keys’ were considered the most apt or least likely to conflict.
Thanks xhtml, I have checked to see if there was any conflict, everything seems ok on windows, so i gather everything else will be ok on mac etc
There’s your answer
Meaning the Government recommendation? If I force numbers instead of letters, I’ll then lose any extra visuals on the links themselves <em>a</em>.
So generally speaking, if there’s no conflict I’ll be ok to use random letters?
Though yes, basically I would suggest if you do use them you stick the ones the UK Government recommend. Personally I’d only use the ones listed in the first post, i.e. ‘0-9’ and ‘S’ unless you can be over 95%+ certain there is no other conflict.
My answer was: there is no “official standard”. Yes misunderstood Rob.
So personal preference really, I’ll have to check the other OS’s, browsers if not I’ll just use the safe option… numbers. Though like I mentioned above, losing extra visuals which is a bit of a drag very useful, unless I also add numbers to the links somehow.
Thanks BPartch, just had a read through them all… everything points to 0-9
numbers every time… you are safe with numbers
Seems like to much conflict using letters, I kept opening the media player on windows when I used ‘p’ and what people have been saying letters are very limited. Like before; bit of a shame really you can’t add that extra visual <em>a</em>
The problem with access key’s isn’t just down to the web browser being used, confliction’s occur when those assigned keys override shortcuts used by software (which you and no-one cept the end user may have access to alter). Meaning that some program a user has installed may override those key preferences and they won’t get the desired effect. It’s a case of the browser giving functionality it doesn’t really have the right to assign (on the basis that it’s not sandboxed for the browser alone).
Cheers Alex, very mixed views on what I’ve read so far today and seems like everything conflicts with each other. It might be best to keep the access keys to a absolute minimum: s - skip to content(if you don’t position your content first that is), 1 - nav bar (then use tabbing), 3 - guidelines etc
I personally don’t use accesskeys because their poorly implemented and being deprecated in HTML5 (from what I’ve read)
Yes fair comment, most of the jobs I’ve been going for accessibility is paramount(meaning companys are still using it) and not sure HTML5 will be standardized any time soon
if developers choose to use accesskey shortcuts, they must somehow notify users that the accesskey shortcuts are available
I was going to use:
Would you bother with this or just keep it in the markup?
The accesskey attribute was absent in earlier drafts of HTML5, but is now present and has been extended and attempted to fix some of the problems of accesskey in HTML4 and current implementations. However, the problems with current implementations remain until they are fixed to implement it per HTML5 (and have better UI than today).
For one thing, HTML5 allows assigning multiple alternative keys to one element which the browser can choose from based on which keys are available. For another, accesskey is available on all elements in HTML5. You can also detect with script whether and which key was actually bound to an element, so you can print out accurate discoverable in-page UI if you want.
Orca screen reader has a lot of very weird key combos… partially to avoid conflicts with Gnome shortcuts and partially… who know what reason. But keys on the numerical keypad are part of it if you’ve chosen Desktop keyboard. I’m not sure you can always assume that someone’s application can always override any particular site’s accesskeys.
BTW Sitepoint does use accesskeys (view source) and at least one regular blind user was using them here. Stuff like forums and news sites, as opposed to one-visit sales sites, may benefit more from accesskeys because people are more likely to get a benefit after spending the time to learn them.
The current accessibility standards state that accesskeys should NOT be used as they make the page less accessiblte due to conflicts between the accesskeys defined in the page and any defined by the operating system or browser.
But is that still true? IE7 still uses Alt+key (don’t know about IE8), so it’s vulnerable. Firefox/Win uses Shift+Alt+key now, so it should be safe. Opera has used Shift+Esc key for years and years and has always been safe.
I just found that Chrome/Win and Safari/Win both use Alt+key, like IE.
The thing is, as confusing and inconsistent as they are… people tend to stick to a single browser anyway (normal people don’t jump browsers regularly) and therefore the inconsistency will be less of an issue for them (especially as people with disabilities tend to be more willing and used to having to make compromises to get a good all round experience). As bad as the situation is, all the research I’ve seen shows that when accesskeys are available, people do make use of them regularly, it’s just a shame there’s such a “learning curve” in the sense of catering for a whole range of different environments when giving instructions for use.
Yes, it is still true that access keys are to be avoided if at all possible. The reason is that JAWS and other programs that help people with disabilities access the Web have their own access keys. As you have no idea which application any given visitor will be using, there is no way you can avoid using the access keys reserved for their assistive technology.
So, remember: It isn’t just the browser that needs all those access keys — it’s also the screen reader (or other assistive technology).
I understand that, but I was under the impression that modern browsers were now using activation keystrokes that shouldn’t conflict with known AT. And one might think that the onus would be on AT vendors not to choose access keys that are likely to conflict with known browsers.
And isn’t it usually the case that software access keys override author-defined access keys in a web page? In that case, all that happens is that the access keys in the page won’t work as the author intended. No harm, no foul. But they will work for those whose software doesn’t conflict with them. Progessive enhancement, that is.
Yes, modern browsers are supposed to not conflict with AT, but functions you build into your page and program access keys to do might. And if the AT function overrides the intended function you programmed into your Web page, then there is harm — that feature of your Web page is not available to anyone using that AT. In other words, it’s inaccessible.
What does Shift+Esc do in JAWS? I have no idea. I don’t need a screen reader. But even if I did, it isn’t just JAWS. It’s also NVDA, VoiceOver, and others. Each one has its own set of access keys, and you can’t tell which one a visitor to your site might use. Each one can conflict with whatever keys you choose for operating your page. And, as everyone realized quite early on in this thread, there simply are no standards for intended action of access keys.
I recall seeing somewhere a list of all the access key sequences used by current forms of AT. I can’t find it now, but the point of that Web page was that pretty much nothing is available. But there is still the issue of how perceptible your key sequences are. By that I mean, How do you let people know what those key sequences will do — without cluttering the interface?
Thus, the bottom line with WCAG is that you should find some other method for visitors to use to gain access to the features of your page.
Not if browser vendors make sure to use an access key activation mechanism that doesn’t conflict with known access keys in AT. Like Opera’s Shift+Esc. And not if AT vendors make sure not to use access keys that may conflict with the access key activation mechanism in known browsers.
No, you’re not understanding the concept of accessibility properly. Inaccessible means that you cannot access the content, or critical functions. But access keys aren’t critical functions; they are just progressive enhancement for those who have something to gain from them.
Some onus is also on the user. There is numerous browsers to choose from – most of them free of charge and available cross-platform – and they employ different access key activation mechanisms: Alt, Shift+Alt, Ctrl, Shift+Esc, … So the likelihood that you cannot find a single browser that doesn’t conflict with your AT should be quite small.
And even if that happens, the result is nothing worse than your missing out on a few short cuts on a handful of web sites.
Compared to the accessibility problems caused by abusing markup for presentational purposes, missing text equivalents, improper heading order, poor contrast, reliance on client-side scripting or plug-ins, missing background colour specification on elements with white text on a background image, etc., etc., etc., I’d say this is a minor thing.
I’m not advocating the use of access keys, but the reason isn’t that there may be conflicts in some combinations of UA+AT, but that they are virtually useless anyway. As far as I know, Opera is the only browser that can even show you what access keys are available on a particular web page. And most sites that use access keys don’t indicate what they are, except maybe on a separate page somewhere.
I agree almost entirely Tommy, the only other concern I hold with the concept of access keys was addressed earlier when I mentioned that a side effect of assigning keyboard shortcuts is that there’s a very real chance another installed application on the end users PC may hijack or reassign the combination to itself. Because the OS doesn’t reserve such key functionality (the UA being separate from the OS) it puts you in an uncomfortable position that even if you have a browser that uses access keys properly and a site declares them, there’s still a chance it may not work, or worse, cause another program to take action upon that combination being used.
