Keyboard  accessibility BASIC STEPS TOWARDS A MORE USABLE AND ACCESSIBLE SITE Patrick H. Lauke / Future of Web Design Tour...
accessibility  = blind users + screenreaders?
difficult to test – need to install and learn  screenreader
many different forms of disability
keyboard or keyboard-like interfaces
easiest to test…no special software required
 
 
by default users  TAB
 
using keyboard, move from one focusable element to the next
standard focusable elements: links ,  form elements ,  image map areas
 
 
 
 
 
don’t forget the  fancy styling
 
a.action :hover  { background-color:#a82310; color:#fff !important; text-decoration:none; } #promo-dvd .content a :hover  ...
a :focus , a :hover , a :active  { … }
don’t suppress  outline !
 
keyboard accessible, but where am I?
/* =Reset Styles -  Thank you Eric Meyer  ( http://meyerweb.com/eric/thoughts/2007/05/01/reset-reloaded/ ) */ html, body, ...
/* remember to define focus styles! */
why do designers suppress outline?
 
“ get your outline out of my design!” … is there a  compromise ?
 
 
a { …  overflow: hidden ;  }
 
… only suppress it on  :active
TAB  cycle – normally just  source order
tabindex  forces a certain  TAB  cycle
anything with  tabindex  takes precedence
 
<input type=&quot;text&quot; name=&quot;author&quot;… tabindex=&quot;1&quot;  /> <input type=&quot;text&quot; name=&quot;e...
easy enough…let’s drop in some JavaScript
 
 
keyboard accessible, but  where’s the extra information ?
$('#whatever') .hover ( function() {…}, function() {…} );
$('#whatever') .hover ( function() {…}, function() {…} ); $('#whatever') .focus (function() {…}); $('#whatever') .blur (fu...
aside:  mobile browsers  don’t do hover  (well)
lightboxes …we love ’em
 
close it again on  TAB don’t invent new keyboard shortcuts
more complex solution:  manage focus
and now, the dangerous part…
JavaScript attaches behaviour to  anything
$(' div ') .click (function() {…} );
sexy tutorials out there doing it wrong
 
be lazy …use libraries that solved this YUI, jQueryUI, etc
beware  3 rd  party solutions even the big boys can get it wrong
 
 
 
hijack generated markup to  accessify  it
in conclusion…
if you style  :hover , also  :focus  and  :active
don’t suppress  outline  completely (reintroduce  :focus  and suppress  :active )
leave  tabindex  alone – source order
JavaScript on  hover  (mouseover/mouseout) also on  focus / blur (if focusable element)
lightboxes  and their problems
only attach behaviour to  focusable elements
</ rant >
www.opera.com/developer [email_address]
Upcoming SlideShare
Loading in …5
×

keyboard accessibility

3,367 views

Published on

Published in: Technology, Design
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
3,367
On SlideShare
0
From Embeds
0
Number of Embeds
11
Actions
Shares
0
Downloads
9
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide
  • If you’re using OS X, make sure you enable full keyboard access for all controls in your system preferences under Keyboard &amp; 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 &lt;div&gt; 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 &lt;div&gt; elements placed over it, all with onclick behaviours to face actual buttons. Why does Google not simply generate &lt;button&gt; 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 &lt;div&gt; elements replaced with actual &lt;button&gt; 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.
  • keyboard accessibility

    1. 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. 2. accessibility = blind users + screenreaders?
    3. 3. difficult to test – need to install and learn screenreader
    4. 4. many different forms of disability
    5. 5. keyboard or keyboard-like interfaces
    6. 6. easiest to test…no special software required
    7. 9. by default users TAB
    8. 11. using keyboard, move from one focusable element to the next
    9. 12. standard focusable elements: links , form elements , image map areas
    10. 18. don’t forget the fancy styling
    11. 20. a.action :hover { background-color:#a82310; color:#fff !important; text-decoration:none; } #promo-dvd .content a :hover img { background-color:#d5c7ae; }
    12. 21. a :focus , a :hover , a :active { … }
    13. 22. don’t suppress outline !
    14. 24. keyboard accessible, but where am I?
    15. 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; }
    16. 26. /* remember to define focus styles! */
    17. 27. why do designers suppress outline?
    18. 29. “ get your outline out of my design!” … is there a compromise ?
    19. 32. a { … overflow: hidden ; }
    20. 34. … only suppress it on :active
    21. 35. TAB cycle – normally just source order
    22. 36. tabindex forces a certain TAB cycle
    23. 37. anything with tabindex takes precedence
    24. 39. <input type=&quot;text&quot; name=&quot;author&quot;… tabindex=&quot;1&quot; /> <input type=&quot;text&quot; name=&quot;email&quot;… tabindex=&quot;2&quot; /> <input type=&quot;text&quot; name=&quot;url&quot;… tabindex=&quot;3&quot; /> <textarea name=&quot;comment&quot;… tabindex=&quot;4&quot; ></textarea>
    25. 40. easy enough…let’s drop in some JavaScript
    26. 43. keyboard accessible, but where’s the extra information ?
    27. 44. $('#whatever') .hover ( function() {…}, function() {…} );
    28. 45. $('#whatever') .hover ( function() {…}, function() {…} ); $('#whatever') .focus (function() {…}); $('#whatever') .blur (function() {…} );
    29. 46. aside: mobile browsers don’t do hover (well)
    30. 47. lightboxes …we love ’em
    31. 49. close it again on TAB don’t invent new keyboard shortcuts
    32. 50. more complex solution: manage focus
    33. 51. and now, the dangerous part…
    34. 52. JavaScript attaches behaviour to anything
    35. 53. $(' div ') .click (function() {…} );
    36. 54. sexy tutorials out there doing it wrong
    37. 56. be lazy …use libraries that solved this YUI, jQueryUI, etc
    38. 57. beware 3 rd party solutions even the big boys can get it wrong
    39. 61. hijack generated markup to accessify it
    40. 62. in conclusion…
    41. 63. if you style :hover , also :focus and :active
    42. 64. don’t suppress outline completely (reintroduce :focus and suppress :active )
    43. 65. leave tabindex alone – source order
    44. 66. JavaScript on hover (mouseover/mouseout) also on focus / blur (if focusable element)
    45. 67. lightboxes and their problems
    46. 68. only attach behaviour to focusable elements
    47. 69. </ rant >
    48. 70. www.opera.com/developer [email_address]

    ×