Accessibility is about ensuring that the products we build are able to be used by as wide an audience as possible. While the ARIA specification might be daunting, building accessible interface elements isn't as difficult as it may seem.
Chris Lienert will take you through his experience building a responsive UI library sharing the failures and successes along the way.
This stair/ramp combination - affectionately known as a βstrampβ - was designed by Arthur Erikson as part of Robson Square in Vancouver, Canada . Eriksen designed Robson Square following the principles of universal design which first gained traction in architecture in the early 1960s.
Hereβs a complicated poster covering the principles of universal designβ¦ but it will be easier for all of us if I summarise them.
Able to be used by people with diverse abilities.
Able to be used in a variety of ways according to individual preference.
The design should make sense without requiring a manual. Much is discussed about intuitive interfaces and the psychology is certainly interesting: touch UIs that are so natural to us now arenβt as straight forward as one might think. Expectations also change with time and circumstance and must be taken into account.
If you canβt perceive it, it doesnβt exist. Humans first demonstrate object permanence at around 8 months. In interaction design, object permanence is a lot stronger.
Error messages make people cry. If youβre happy with that, you might skip this point however the humanists among us will want to ensure that we avoid or accommodate all sorts of failures without undue despair.
We shouldnβt have to perform gymnastics.
Appropriate size and space available for interaction regardless of individual abilities
How does any of this apply to software? Joe is essentially describing Universal Design and, in effect, thatβs what accessibility is for software development.
When I started at JLT Interactive in Singapore last year, I gave myself the task of uniting and standardising the companyβs global UI in a style guide and open-source library. Iβll be referencing this site a few times so feel free to play along at home.
No legacy, no history, no baggage. The rationale is to avoid othersβ baggage and weight. Do you want to live and die on someone elseβs sword? I donβt.
Essentially, take all of theseβ¦
β¦and throw them out.
How hard could it be?
The answer is not very. After years of using jQuery, I thought it would be a big problem leaving in the dust but element.querySelector() and element.querySelectorAll() do pretty much everything youβd want.
ARIA roles and properties add an extra layer to HTML describing a range of UI elements. They act to glue various elements together in a coherent form.
Heydon Pickeringβs point here applies to ARIA roles too. First step is to get your HTML in decent order and then embellish.
Surprising things happen when you use ARIA roles and attributes. Having adopted BEM naming scheme, you'd normally use the modifier to note state changes.
ARIA roles and attributes circumvent many of these and add a clarity to the code that you'd otherwise not get.
JavaScript is also clearer
Early on I went a little crazy and wrote things like this. The problem is itβs global and doesnβt allow for any animations.
Far better to namespace with a class or element selector so you know what youβre targeting.
Youβll want to get familiar with the W3C documentation which tells you much of what you need to know. As scary as W3C documentation can be, the authoring practices guide is quite helpful describing what various UI elements do, how they should behave and what markup they need.
One problem I found is the quality of the examples can be limited. Fortunately other people have done some of the heavy work.
Setting out to create a hierarchical tree picker, I borrowed heavily from Lea Verouβs magnificent Awesomplete.
The most difficult scenarios are where youβre building something that doesnβt exist in the ARIA documentation. In this situation, Iβve found it handy to use the documented components as a guide. Once you get into the rhythm of it, itβs not too hard to create something new.
This is a prototype hierarchical picker built to simplify some rather complex data.
While thereβs nothing that matches in the ARIA list, the result is a hybrid auto-complete and tree view.
Broadly speaking, this covers Universal Design principles simple & intuitive, perceptible, low effort and right size and space.
The general rules with text sizing, is donβt make it so small. You probably canβt read this.
This is getting better but still isnβt great.One of the problems with text sizing is those of us designing these things are more likely to have better eyesight than, say, a cricket umpire.
Now weβre getting somewhere. Bumping up your font sizes will make the world a better place: 16pt is a good base line. I often get resistance to this especially for transactional sites but itβs typically nothing more than change resistance.
In the past, it wasnβt uncommon to see tiny interaction elements because, with a tiny mouse cursor, you could get there in the end. The general rule is an interaction target needs to be βbig enoughβ.
With the widespread adoption of touch interfaces and the research that came with them, concrete targets became available.
The average human finger pad size is 10mm and we humans can generally hit targets as small as 7mm. Once you take into account various screen sizes and resolutions, youβre looking at a minimum of 24px (Google/Apple; Microsoft: 26px).
Really important to test on devices because things can get weird.
We might encounter colour contrast in the form of colour blindness tests like the Ishihara plate here.
The crux of colour contrast in is ensuring that the ratio between text and the background meets a minimum ratio: 4.5:1 for small text (< 20pt) and 3:1 for larger text. The difficult bit is how to test for this.
Fortunately there is a range of browser extensions that help you out.
It gets a bit harder when you have complex background images, but there are tools for that too.
I canβt remember the last time I received a design that had every element pass contrast tests so itβs really down to developers to give feedback to designers to get this right.
Because human colour perception is biased toward certain colour combinations, the WCAG ratios arenβt actually all of it. The UX team at Shopify looked into thisβ¦
β¦describing scenarios like this where WCAG ratios and subjective guidance disagree.
Their research took them a 1992 method of describing legibility of highway signage which shows different results that the simpler W3C ratios. Note thereβs an error in this illustration with incorrect description on the right white-on-red image.
Roughly putting the βobviousβ together: buttons need to look like buttons. More technically, interactive elements should look interactive. In iOS7, Apple pushed an unfortunate trend where buttons werenβt always.
Google followed suit with Material. Looking at these three, we have good, good and what on earth? How do you know what that is?
How big is the interaction target?
The image on the left is marked as the correct method; the one on the right, incorrect. There are nuances here but the guiding principles here are not great for accessibility. The buttons on the right might be a little garish but the intent is much clearer.
Back to⦠buttons need to look like buttons.
Taking it a step further, interaction states help smooth the cognitive flow. Subtle animations are fantastic for this.
Key is to provide appropriate feedback for a given action.
Keyboard access is probably one of the most important aspects of enabling access. In practise, it gets down to only a few keys that need to be supported - tab, enter, space and arrows.
The ARIA guide really comes into itβs own with the keyboard documentation. Thereβs still a lot to learn from playing with examples but this is about as good a specification as youβre likely to get.
Because Iβm lazy, I started out on Google looking for a good example of tabs and Remy Sharpβs example was a great starting point.
Using this tab demo, Iβll firstβ¦
β¦click the second tab. And then switch to keyboard navigation andβ¦
β¦tab to select that tab thenβ¦
β¦left arrow to select the third tab.
Getting stuck into this, I thought there was nothing new to know about keyboard events. The correct and standard way to do this is with the KeyboardEvent.key value. Unfortunately, browser support isnβt perfect: Firefox, IE11, Edge and, as of version 51, Chrome.
This takes us to KeyboardEvent.charCode which returns an ASCII key code supporting Safari, older Chrome and older IE.
Then throw in KeyboardEvent.keyCode if you need additional support back to IE8.
To interpret the result, drop the variations into a case statement. Notice the non-standard variation of the key value to older IE.
With that, everythingβs fine. Hereβs a kitten to remind you how fine it is.
A large part of accessibility is ensuring that we donβt break the ground rules when we do something new.
Essential to the induction process at Disney is ensuring that the ground rules are followed. The key to is to, putting it politely, βDonβt mess with the mouse.β
Sacred ground exists in every realm and itβs critically important that you know what it is before diving in. On the web, that sacred ground is default behaviour.
Back to the tabs, what rules apply here?
enable back/forward
and without losing state⦠except when it's expected
ensure browser shortcuts aren't killed
The magic whip here is the storage API. Little known, even less implemented, it lets you store all sorts of state values.
Consumer products company OXO was founded in 1990 when founder Sam Farber noticed his arthritic wife Betsy struggling to use a kitchen peeler. By making a peeler his wife could use, Farber improved the product as a whole and this is why accessibility is important: your work will be universal.