Empfohlen
Weitere ähnliche Inhalte
Andere mochten auch
Ähnlich wie keyboard accessibility
Ähnlich wie keyboard accessibility (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (20)
keyboard accessibility
- 1. Keyboard accessibility BASIC STEPS TOWARDS A MORE USABLE AND ACCESSIBLE SITE Patrick H. Lauke / Future of Web Design Tour / Glasgow / 14 September 2009
- 2. accessibility = blind users + screenreaders?
- 3. difficult to test – need to install and learn screenreader
- 4. many different forms of disability
- 5. keyboard or keyboard-like interfaces
- 6. easiest to test…no special software required
- 9. by default users TAB
- 11. using keyboard, move from one focusable element to the next
- 12. standard focusable elements: links , form elements , image map areas
- 18. don’t forget the fancy styling
- 20. a.action :hover { background-color:#a82310; color:#fff !important; text-decoration:none; } #promo-dvd .content a :hover img { background-color:#d5c7ae; }
- 21. a :focus , a :hover , a :active { … }
- 22. don’t suppress outline !
- 24. keyboard accessible, but where am I?
- 25. /* =Reset Styles - Thank you Eric Meyer ( http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ ) */ html, body, div, span, applet, object, iframe, h1, h2, h3, h4, h5, h6, p, blockquote, pre, a, abbr, acronym, address, big, cite, code, del, dfn, em, font, img, ins, kbd, q, s, samp, small, strike, strong, tt, var, dl, dt, dd, ol, ul, li, fieldset, form, label, legend, table, caption, tbody, tfoot, thead, tr, th, td { margin: 0; padding: 0; border: 0; outline: 0; font-weight: inherit; font-style: inherit; font-size: 100%; font-family: inherit; vertical-align: baseline; } :focus { outline: 0; }
- 26. /* remember to define focus styles! */
- 27. why do designers suppress outline?
- 29. “ get your outline out of my design!” … is there a compromise ?
- 32. a { … overflow: hidden ; }
- 34. … only suppress it on :active
- 35. TAB cycle – normally just source order
- 36. tabindex forces a certain TAB cycle
- 37. anything with tabindex takes precedence
- 39. <input type="text" name="author"… tabindex="1" /> <input type="text" name="email"… tabindex="2" /> <input type="text" name="url"… tabindex="3" /> <textarea name="comment"… tabindex="4" ></textarea>
- 40. easy enough…let’s drop in some JavaScript
- 43. keyboard accessible, but where’s the extra information ?
- 44. $('#whatever') .hover ( function() {…}, function() {…} );
- 45. $('#whatever') .hover ( function() {…}, function() {…} ); $('#whatever') .focus (function() {…}); $('#whatever') .blur (function() {…} );
- 46. aside: mobile browsers don’t do hover (well)
- 47. lightboxes …we love ’em
- 49. close it again on TAB don’t invent new keyboard shortcuts
- 50. more complex solution: manage focus
- 51. and now, the dangerous part…
- 52. JavaScript attaches behaviour to anything
- 53. $(' div ') .click (function() {…} );
- 54. sexy tutorials out there doing it wrong
- 56. be lazy …use libraries that solved this YUI, jQueryUI, etc
- 57. beware 3 rd party solutions even the big boys can get it wrong
- 61. hijack generated markup to accessify it
- 62. in conclusion…
- 63. if you style :hover , also :focus and :active
- 64. don’t suppress outline completely (reintroduce :focus and suppress :active )
- 65. leave tabindex alone – source order
- 66. JavaScript on hover (mouseover/mouseout) also on focus / blur (if focusable element)
- 67. lightboxes and their problems
- 68. only attach behaviour to focusable elements
- 69. </ rant >
Hinweis der Redaktion
- If you’re using OS X, make sure you enable full keyboard access for all controls in your system preferences under Keyboard & Mouse settings.
- 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.
- 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).
- IE’s link outline is the classic dotted line. The colour of this line seems to depend on the background colour(s) used.
- Firefox uses the dotted outline – the colour matches the link colour set for the focused link.
- Safari uses a large blue box around the link.
- Google Chrome uses an orange-ish box around links to highlight them.
- Opera uses both a blue box and highlights the text of the link with its default selection colour.
- 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.
- 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).
- Many people using Eric’s reset.css seem to overlook (or simply ignore) this little warning in the original code…
- 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.
- 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!
- 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.
- 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.
- 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!
- 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.
- 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?
- 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?
- 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?)
- 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.
- 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?
- 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.