Accessibility Tips for Front End Developers

I gave a short talk last Saturday on accessibility at Treweb, consisting of a few easy tips you can do to improve the accessibility of your web site or app, as a developer. This blog post is a summary of my main points.

Don’t prevent keyboard-only navigation

There are various reasons why some might be unable to use a mouse, but good keyboard support for web navigation also benefits power users. Unfortunately, some of the most popular CSS frameworks and resets include the following rule:


a:focus {
  outline: none
}

While this makes a lot of graphic designers happy, in practise it makes tabbing through links on a site practically impossible. Often the frameworks expect that you will redefine your own focus styles, but this rarely happens. The best option then is just to not disable them in the first place. A good second is to make hover and focus styles the same:


a:hover,
a:focus {
  background: #990099;
}

In forms, it can help to have a similar distinction for the active element, especially if the form is long. Placing form elements on top of each other (instead of side-by-side) will also make keeping track of the focused element easier.

Make pop-ups easy to close

The new tweet modal on twitter.com

Pop-up windows should be easy to get rid of, whether they’re “virtual” modal layers or actual windows (increasingly rare). It doesn’t matter if the pop-up was created via a user action or not, closing it should be simple both with a mouse and a keyboard. Make the click target big enough (see below) and support the ESC key:


$(document).keydown(function(e) {
  // ESC pressed
  if (e.keyCode == 27) {

    // ...insert code to hide popup here...

  }
}

Big click targets

In today’s touch-device-filled world you should be doing this anyway, but large click zones will also help anyone with difficulties using a mouse, such as people with Parkinson’s, the elderly, or you after a wild night out. For touch, a generally recommended size is 44 pt. Read this post by Luke Wroblewski on Touch Target Size.

Dropdowns

A long-time favourite annoyance of mine are large dropdown menus that just won’t stay open. Setting a delay (500-1000 ms) before a menu closes (after the mouse cursor leaves) will help all users. Also, test tabbing through your menus with a keyboard, can you tab through to the dropdowns?

Superfish and hoverIntent.js will help with both of the above issues. Superfish also supports touch.

Support custom stylesheets

According to the European Dyslexia Association, dyslexia affects about 8% of the population. Often dyslexics find that using a different font (such as Comic Sans) can help reading, so it’s a good idea to keep basic typographic styles fairly simple, thus making them easy to override with a custom style sheet.

Other good tips on catering to dyslexic users can be found in this blog post by UX Movement.

Use WAI-ARIA landmarks and roles

This is the definition of WAI-ARIA from the World Wide Web Consortium website.

WAI-ARIA, the Accessible Rich Internet Applications Suite, defines a way to make Web content and Web applications more accessible to people with disabilities. It especially helps with dynamic content and advanced user interface controls developed with Ajax, HTML, JavaScript, and related technologies.

In brief, ARIA includes a large set of attributes that add more semantics to HTML, and are especially useful in making complex dynamic UIs accessible to assistive devices, such as screen readers. However, the accessibility of any web page can be improved by ARIA landmarks, such as role="article", main, navigation, search and complementary. All popular screen readers support dividing the page into according to these roles, thus making skipping to a specific area of the page quicker. I won’t go into more detail here, instead I suggest reading this introduction to landmarks on the Opera website.

Screenshot of my blog, showing ARIA-marked areas
A view of my blog generated by the ARIA Landmark Inspector Booklet

The default theme for WordPress has included ARIA landmarks for at least the last 4 years.

Use enough contrast and support zooming text

For users with low vision and/or color blindness, a sufficient contrast between foreground and background is important. Total black-on-white is not necessarily the best option though, instead a slightly off-black (#222) on off-white (#eee or #ffe) might be better for a lot of users. For a long list of different contrast checking tools, go to 456 Berea Street.

Also check that your site supports zooming without breaking the page and hiding content. Using Ems and percentage units will help there.

Books

There are many books on accessibility, but I can recommend these:

Miten varmistat, ettei käyttäjää suututa niin paljon

Emme yleensä pidä siitä, kun jokin menee pieleen tai ei toimi. Vielä vähemmän pidämme siitä, että meitä syytetään asioista, jotka eivät johdu meistä. Varsinkin suuressa ja ihmeellisessa “ATK-Internetissä” itsesyytökset ovat herkässä, kun jokin ei menekään niin kuin piti.

Tätä tunnetta voi huomattavasti vähentää fiksuilla sanamuodoilla, kuten Twitter tekee, jos viserrys ei jostain syystä mennytkään perille:

Twitter error message: we did something wrong
Anteeksi! ME teimme jotain väärin.

Syyllisyyden ohjaaminen yksiselitteisesti palveluun helpottaa hitusen käyttäjän oloa ja kannustaa yrittämään uudestaan. Ainakin kerran.

Miten saat käyttäjän suuttumaan

Yritin hiljattain varata vuokra-autoa kolmesta eri yhdysvaltalaisesta autonvuokrausfimasta verkon välityksellä. Lopulta vuokraus onnistui, mutta parilta ensimmäiseltä firmalta jäi asiakas saamatta yksinkertaisesti siitä syystä, etten tykkää siitä että minua kiusataan.

Hertz veti pohjat. Varauslomakkeen yhteydessä kysytään paikkakunnan lisäksi, minä päivänä ja mihin aikaan auto halutaan vuokrata. Tämän jälkeen käyttäjälle näytetään lista autonvuokraamoista, jotka sijaitsevat lähellä toivottua paikkaa. Ajan kysymisestä huolimatta lista sisältää myös vuokraamoja, jotka eivät ole auki toivottuna ajankohtana. Epähuomiossa valitsin siis vuokraamon, joka onkin kiinni, ja sain seuraavanlaisen ilmoituksen:

Hertzin virheilmoitus
Tässä vaiheessa vain hitusen kiukuttaa.

 

Eipä tässä mitään, ajattelin, ja napsautin hyödyllisen näköistä “Help me find a location” -linkkiä. Hertzillä on vähän erikoinen käsitys auttamisesta, sillä seuraavalle ruuduilla avautui lista kaikista maailman maista, joissa on autovuokraamoja.

Lista kaikista maista, joissa on Hertzin autovuokraamo
Nyt jurppii oikein kunnolla.

Tässä kohtaa alun suhteellisen miellyttävä käyttökokemus hajosi täysin, ja vaihdoin firmaa. Vinkkinä siis vastaavanlaisia sivustoja toteuttaville: huomioi myös virhetilanteet! Tässäkin tapauksessa olisi suhteellisen yksinkertaista tallentaa muistiin käyttäjän alun perin toivoma sijainti. Tämän tiedon avulla olisi helppo näyttää uudelleen lista vain kyseisellä paikkakunnalla sijaitsevista vuokraamoista. Vieläkin parempi vaihtoehto olisi ehkäistä virhetilanteiden synty alun perin huomioimalla vuokraamojen aukioloajat.

Ulkoasu-uudistuksia tulevassa WordPressissä

Tulevassa WordPressin 3.2 -versiossa on todennäköisesti luvassa muutamia yllätyksiä.

CSS-päivitykset ovat vielä kesken, joten ylläoleva kuva ei välttämättä vastaa lopullista tyyliä. On toki myös mahdollista, etteivät kaikki uudistukset päädy lopulliseen julkaisuversioon. Käyttöliittymäkehitystä voi seurata Make WordPress UI -blogissa ja kehitysversiota yleisesti WordPress Development Updates -blogissa.

Uutta tulevassa julkaisussa on myös mm. uusi TwentyEleven-teema. Sen asetuksissa on hauska lisä, joka lisää WP:n “oletuspaketin” räätälöitävyyttä:

3.2-julkaisua lupaillaan kesäkuun lopun nurkille, ja saamme suomenkielisenkin version varmasti samoihin aikoihin pihalle. Lisäys: kehitysversiolla on helpointa leikkiä WordPress Beta Tester -lisäosan avulla.