�ݺ�ߣ

Editor's Notes

• #8: If you’re using OS X, make sure you enable full keyboard access for all controls in your system preferences under Keyboard & Mouse settings.
• #9: In Safari (both in OS X and Windows) you need to also explicitly set “Press Tab to highlight each item on a webpage”) in your Advanced preferences.
• #11: Opera has a slightly different keyboard control scheme – instead of using TAB, you use CTRL + cursor arrows up/down to move to the previous/next link. There is also a different mode, Spatial Navigation, which behaves very differently and is beyond the scope of this presentation (mainly as it actually behaves more like a mouse, thus removing all requirements outlined in this presentation…but we don’t advocate designing just for Opera, of course).
• #14: IE’s link outline is the classic dotted line. The colour of this line seems to depend on the background colour(s) used.
• #15: Firefox uses the dotted outline – the colour matches the link colour set for the focused link.
• #16: Safari uses a large blue box around the link.
• #17: Google Chrome uses an orange-ish box around links to highlight them.
• #18: Opera uses both a blue box and highlights the text of the link with its default selection colour.
• #20: Andy’s “for a beautiful web” site is nicely keyboard accessible. A few details – mainly eye candy – only appear when using a mouse, however: the “sign up” buttons change colour and the DVD boxes get a lighter outline on hover.
• #24: Paul’s “boagworld” suppresses any outline completely, making it impossible to know where a keyboard user is within the page. The problem is exacerbated in browsers that either don’t have a status bar (such as Google Chrome) or which for some reason don’t show the link target when using the keyboard (Safari).
• #27: Many people using Eric’s reset.css seem to overlook (or simply ignore) this little warning in the original code…
• #29: Carsonified.com is beautifully art-directed and designed, with lots of image replacement. Again, because of Eric Meyer’s reset.css, outlines and :focus styles are completely suppressed though.
• #31: Carsonified makes extensive use of image replacement. Forcing the focus outline to be visible shows that, in one instance – the “Follow us on Twitter” button – the outline betrays the “off-left” CSS image replacement that was used, by going off to the left of the window…an ugly effect that designers just won’t stand for!
• #32: An intial quick fix to Carsonified would be to add overflow:hidden to the twitter button. Now, at least, the outline remains contained around the image-replaced link and doesn’t go off to the left of the page.
• #34: Being a boring pedant, I tried all sorts of variations (removing outline altogether, reintroducing it on focus, removing it again on active, etc) to try and find an acceptable solution that lets keyboard users still see the outline, but that doesn’t trigger the outline when users click on image-replaced links.
• #39: The default Wordpress theme’s comment form has tabindices on all fields. No matter how many links there are on the page or in the actual blog post, a keyboard user coming to the page and hitting TAB for the first time is bounced straight to the comment form…not very useful if they haven’t even read the blog post yet!
• #42: jQuery’s homepage has three links in its central section, which all have informative “fancy tooltips” springing up on mouse hover. These tooltips give information not immediately available on the page. Sadly, they don’t come up for keyboard users.
• #43: Paul’s “boagworld” again…this time, we look at the “latest shows” section on the right. Moving the mouse over each show expand “boagworld’s magic hover accordion” thing to present the show’s synopsis. This makes people seasick, including myself…but it only triggers on mouseover. Why not make keyboard users just as sick and give them the same information immediately?
• #49: Lokesh Dhakar’s Lightbox JS is one of the first lightbox scripts I remember coming across many years ago. It works fine via keyboard – TAB to the thumbnail, activate it, and the lightbox appears. Now, TAB again…the lightbox remains on screen, and you’re tabbing behind the dimmed background layer. The lightbox does say “press X to close”, but this isn’t immediately helpful. If it’s already listening out for “X” why not also listen out for TAB?
• #51: Particularly important if you’re using a “thickbox”, i.e. a lightbox that contains more than just an image and some text. Use JavaScript to place the focus inside the box, so keyboard users can get to the thickbox’s content (links etc). When they close the box, programmatically focus them back on the link/thumbnail that activated the box in the first place (closures?)
• #56: WebDesignerWall’s jQuery tutorials for designers are really great. The whole site sports a beautiful design, so I’m not “slagging” it. However, the examples it shows are of the worst kind: buttons, accordions, etc all feature <div> elements and such with onclick behaviours…completely keyboard inaccessible.
• #60: A look under the hood of the markup that Google Maps spits out shows that the controls are nothing more than one big image with invisible <div> elements placed over it, all with onclick behaviours to face actual buttons. Why does Google not simply generate <button> elements, as would be semantically appropriate and keyboard accessible?
• #61: My Dev.Opera article shows how – in a kludged way – the Google Maps markup can be hijacked and the <div> elements replaced with actual <button> elements. Note that since the article was published, Google seem to have further modified their markup, breaking one aspect of my interim solution…one more reason why we should really lobby Google to actually fix the problem at source.