Few people think much about web accessibility. Even fewer people understand it, and without understanding there won’t be empathy or change. However, a string of high-profile class action lawsuits in 2019, like the one against Beyonce’s management company, brought the issue to light — and I expect we’ll see a lot more companies prioritizing web accessibility in 2020.
At the same time, the US and many European countries are more rigorously enforcing their by-laws applying to free content accessibility. Companies will no longer be able to afford to ignore this issue.
It’s no surprise that visually impaired people are demanding better access. Populated with Instagram ‘stories’ and online stores that display 360-degree, high-definition product images and video, the web has become a visual public space. That puts many people at an unnecessary disadvantage.
It’s not only lawsuits driving demand for greater visual access, but the growing problem of poor vision. According to the World Health Organization (WHO), around 1.3 billion people have some visual impairment, such as low vision, color blindness, and (partial) blindness. That’s nearly 20 percent of the global population — including your website visitors — who struggle with accessibility.
Adjust your mindset
I’ll be the first to accept that the US is more lawsuit-happy than most. Maybe you live in another country, with a different legal culture and don’t think you need to worry about accessibility. That’s the wrong mindset.
As a frontend developer, I do care about web accessibility; it’s my responsibility. I don’t want visitors just to have ‘access.’ I want them to have the best possible experience. Let’s take a closer look now at some of the different types of visual impairments people have and how to address them on a site.
Light sensitivity
Light sensitivity is a very common issue, especially for people who sit in front of computer screens all day. Light-sensitive people can find it hard, painful, or even impossible to read and concentrate under bright lights, on bright screens, or on web pages where bright colors are combined.
This is why most developers like me switch to dark themes in their dev tools, IDE, or their OS (if it has one). It’s also why popular apps like Twitter, Google, Facebook Messenger, and recently iOS, provide “Dark Mode.”
One difficulty is that there’s no one standard for light sensitivity. It varies by person and setting, so it’s impossible to devise one configuration set that works for all light-sensitive people.
Solution: Light sensitivity themes
Offer “Dark Mode” or a “Light Theme” for your users and allow them to set the brightness, essentially letting them decide for themselves.
There are several approaches to achieve this, depending on your technology stack and browser support. A straightforward way is to combine a CSS variable and the CSS invert method: filter: invert().
By defining invert(1), the browser inverts all colors available in your apps to the exact opposite matching colors.
/*Define css variable for dark/light mode*/:root { --nightMode: 0;}/*Apply the mode change to the whole app on */body { filter: invert(var(--nightMode));}
This filter effect also applies to all images within the app. You might want to add some code to make sure colors are reserved even in inverted mode (dark or light).
Warning: filter is still not supported in IE. If IE support is critical for your app, consider using other approach such as CSS-in-JS (styled components for Vue or for React).
Contrast sensitivity
Contrast sensitivity occurs where people struggle to read text that is placed over images and videos. This happens when white text is placed on a light background, black text is placed on a dark background, or text is placed on a visually ‘busy’ background.
Solution: Tools and resources
Unlike light sensitivity, contrast sensitivity issues are easy to identify. Popular browsers including Chrome and Firefox now include a ‘contrast score check’ in their dev tools, which flag any page sections that aren’t visible enough. You shouldn’t rely solely on these tools, however, because the automatic scores are not always 100 percent accurate.
To address contrast sensitivity fully, refer to the Web Content Accessibility Guidelines (WCAG). It states that text, or images of text, must have a contrast ratio of at least 4.5:1. Exceptions are large text (where it’s 3:1), invisible, and decorative text and logotypes, where the text is part of a brand name.
To summarize some of the main points:
Addressing contrast sensitivity shouldn’t be confused with changing color schemes. It’s all about ensuring that people can read webpage text by providing the optimal contrast between text and its background.
Larger text has a lower contrast criteria. This is because larger text is, by nature, easier to read. 18 point text or a 14 point bold text is considered “large text.”
Contrast also applies to images of text, not just strictly applied to fonts — for example, a JPG image of a brand logo.
Color blindness (or color vision deficiency) makes it difficult (or impossible) for affected people to identify or distinguish between specific colors.
Imagine a colorblind person visits an online store to buy a red t-shirt and sees only green ones. How would this visitor know which ones to buy?
Solution: Translate colors to text
In some cases it will be impossible to adapt an image to appear correctly for someone with color vision deficiency. For these, the options are to either provide chat/live support or text prompts (or, ideally, both).
To provide text prompts, we add the name of the color as text to images using the alt attribute. So instead of saying that an image is a ‘t-shirt,’ we would explicitly state that it is a red t-shirt. The more specific, the better. Yellow is somewhat helpful, but ‘mustard yellow’ is much more descriptive.
This will involve some light coding, or you can use one of the image management tools on the market that help automate this process.
Solution: Pattern your colors
Another option is to provide a unique pattern to represent each different color on your webpage. The standard approaches are not straightforward — either designers need to manually code something or use image editing software like Photoshop or Gimp to create an extra resource for each colorblind case.
The free version of my company‘s own software includes a transformation “e_assist_colorblind effect” to make this process easier. For example, you can add stripes to highlight the difference between hot (red) and cold (green) colors.
Hopefully this has given you some ideas for how to address the most common issues around visual accessibility. By focusing on this important issue, you’ll not just avoid litigation, but you’ll attract more site visitors, raise engagement, and potentially boost revenue as well.
Accessibility is essential for developers and businesses who want to make a high-quality website and reach as many people as possible. It is often being referred to as A11y, which is an abbreviation of the word accessibility itself.
A is the beginning of the word, 11 represents letters in the middle, and y at the end of the word.
When you work with accessibility in mind, it will improve the experience of everyone who uses your website.
A great website should be accessible to as many people as possible, regardless of their hardware, software, language, location, or ability. Many companies and developers are not sure why they should invest their time to make their website and digital content accessible. But, it is important and actually can be seen as a competitive advantage for their business. Here are some of the reasons:
Leads to good practices Resulting in semantic and better mark-up for SEO.
Helps to avoid legal concerns In the year 2000, The Sydney Organizing Committee for the Olympic Games has to paid AUD 20,000 because the official website failed to supply adequate accessibility to the blind user. Read the full story here.
Enhance your brand Implementing accessibility will increase the positive image of a company with their diversity and inclusion efforts.
Disabilities can affect people in different ways. In this article, we will discuss web accessibility for three types of disability: vision disability, hearing impairment, and mobility and cognition disability.
Most of the web content and navigation are designed for visual interaction. So, I believe your website already has a beautiful and functional design. However, to offer accessibility for people with various types of visual disabilities, you need to take a couple of things into considerations.
Color blindness The most common example is the blindness of red and green. There is also a case of monochrome vision. Check the contrast of your website when designing by desaturating it.
Poor eyesight Maybe you often see people with poor eyesight squinting their eyes when reading an article on their phone or computer. So, to make a better experience for them, avoid using fixed size for text, adjust the size according to the screen size. Give users the option to resize the text as well.
Low vision Low vision conditions like cataracts and glaucoma can cause a blurry-vision. Make sure your website works with the screen-reader app. For instance, by using captions or alternate attribute (alt) for your HTML image element. To simulate the low vision situation, you can add a blur filter to your website content. At this point, you won’t be able to see the content of your website. Now, try to use the screen-reader app to navigate your site by hitting cmd f5 to enable the built-in VoiceOver tool for Mac or download the NVDA VoiceOver tool for Windows.
Other things you can do to improve the visual accessibility of your website are using regular text instead of an image as text, and not using scrolling/running and flashing text.
There are several types of mobility and cognition disabilities, such as Cerebral Palsy, Stroke, and Parkinson. To make your website accessible to people with these disabilities, you should:
Provide a keyboard-friendly content. Make sure your user can access the entire content of your websites using a keyboard. If possible, support an alternative to handle drag-and-drop or any gestural input.
Provide enough time for users to complete the action (read or click) for slider/carousel type content.
Minimize the number of steps to accomplished a task by adding keyboard shortcuts, simplifying the UI.
Provide a large clickable area.
Depending on the target audiences of your website and where you live, there will be a couple of different guidelines you can adopt.
WCAG 2.0 has been gaining traction globally as the go-to web accessibility requirements. Most likely because it was created by the world’s experts, the documents are well organized, and it covers a wide range of disabilities.
Note: There is a newer version which is WCAG 2.1 that was published on 5 June 2018. It will extends WCAG 2.0 to 13 guidelines and 78 success criteria. I will update the list to WCAG 2.1 later. Please wait for the update.
WCAG 2.0 was published on 11 December 2008. It has four principles as the foundation for web accessibility:
Perceivable Users must be able to perceive the information being presented.
Operable Users must be able to operate the interface.
Understandable Users must be able to understand the information as well as the operation of the user interface.
Robust Users must be able to access the content as technologies advance.
Across these principles, there are 12 guidelines and 61 testable success criteria provided to allow WCAG 2.0 to be used where requirements and conformance testing are necessary, such as in design specification, purchasing, regulation, and contractual agreements. In order to meet the needs of different groups and different situations, three levels of conformance are defined:
Level A Most basic web accessibility features
Level AA Biggest and most basic common barriers
Level AAA The highest level of accessibility
My recommendation for the conformance level you should meet on your website is Level AA, which satisfies all the Level A and Level AA success criteria. The checklist below is designed to fulfill this level.
Computer games are a big deal: they are part of our culture, they provide and can promote social inclusion, they can educate (from encouraging and supporting player creativity through making modifications and new game levels, to being used as teaching aids) and they are a hugely popular means of recreation.
Just as with other walks of life, accessibility in computer games — and, importantly, their surrounding communities of online play, modifications and level design — is something for which we should strive, and many developers are. Historically, games have been regarded as a very hard accessibility problem to solve. It’s true there are some compelling challenges, but huge strides have been made, with the potential for game accessibility to become the norm.
Some of the earliest computer games were fairly accessible by nature: interactive fiction takes advantage of the greatest rendering hardware known — the human brain — to create immersive and compelling worlds in which the player could explore, vanquish monsters, maybe nick a bit of treasure, and generally save the day. However, it’s important to consider that they do require good reading skills, and for their players to be able to type!
Text-based games reached their peak of popularity from the 1970s to the 1980s, though online variants, such as multi-user dungeons (MUDs), were popular into the 1990s. However, graphics pervaded every genre, including adventures, by this time. Most games had graphical user interfaces (GUIs), and it was increasingly common for them to require precise timing and deft cognitive and motor skills from their players. Whilst graphical games reached popularity in the late 1970s, these features and expectations were now the only mainstream option. Barriers to entry were created, either due to a disability or situational impairment of the otherwise-gamer. Games became challenging, even in ways they didn’t intend to be.
But, as game accessibility consultant Ian Hamilton points out, games have to be challenging in order to be rewarding experiences for their players. So, does this mean accessible games are a pipe dream? Of course not! There are many reasons why people may be unable to play games, but there are also many ways to present and interact with game worlds.
From the early days of computer gaming, there have been efforts to make games accessible, including specialist controller hardware such as sip/puff devices (some made by mainstream games companies) and assistive hardware and software features such as speech synthesis to assist blind people. You can find some excellent examples documented on the Accessible Gaming History Exhibit page at OneSwitch (specifically, check out the Accessible Gaming Displays PDF).
Some of the early specifically-made accessible games fall under the broader category of “Audiogames” (as opposed to video games) — these are games specifically designed with sound as the main means of expressing their world to the player. Some very imaginative, immersive and well-respected games were created by small studios, even one-person companies, many specifically for gamers who are blind (e.g. Monkey Business, Grizzly Gulch, and Chillingham). Others, such as Papa Sangre and The Nightjar were designed for all, with the high-tech audio engines and lack of video adding to the atmosphere of the game, and achieving significant mainstream attention at the time. These are great games, and fill a vital role. In parallel, however, the goal of accessibility in the majority of, if not all, games is an alluring one.
In recent years we’ve seen the benefits of much hard awareness-raising work by organisations such as the IGDA Game Accessibility Special Interest Group and many others, as well as corresponding effort from developers to make their games more accessible:
mainstream console and other gaming platforms now come with built-in assistive tools and APIs;
But accessibility features don’t only help people who experience a permanent disability; some accessibility features are more commonly used than you might think. In Assassin’s Creed Origins, 60% of players turned subtitles on, so in the following game Ubisoft enabled them by default, and 95% of Assassin’s Creed Odyssey players left subtitles on.
So-called situational disabilities may be particularly prevalent for mobile/casual gaming, where players may be in a bright, busy or noisy environment, or not be able to use both hands to interact with the game.
Content accessibility
A great deal can be achieved with careful attention to content design. Games, more than web sites or apps, are all about their content. Simple, but fundamental techniques, like ensuring that information conveyed using colour is also conveyed by other means, such as shape, can have a profound impact for many people, even those who don’t regard themselves as having a disability for example. (Some great examples of using more than colour can be found on the Game Accessibility Guidelines site.)
For example, the following two symbols differ in both shape and colour, thus providing two ways to tell them apart. In a puzzle game, this can empower and include significantly more players than if colour alone had been used as the differentiator.
◆●
The key thing here is that this is accessible without the user having to turn on an accessibility setting — thus promoting inclusion out-of-the-box.
Spatial audio can provide surprisingly rich information to the player on the environment in which they’re in (a giant echoing chasm, or in tight quarters on a spaceship), and where they should explore. Attentive audio design really can afford accessibility SightlessKombat is a Killer Instinct player who rose to the top tier of players, despite not being able to see. However, access to the games’ user interfaces can still pose problems — most games are unable to interface with assistive technologies such as screen-readers. In many cases, blind gamers have to learn the buttons to press in order to navigate through the user interface to get into the game.
Of course, using spatial audio is an enabler for some people, but others (whether they be in a noisy environment, or perhaps have trouble hearing the game) may struggle to get the most out of it. Visual cues can also be used to convey information that is also provided through sound. Examples of this can be found in Half-Life, which uses visual effects to indicate the direction from which the player is taking damage, and “Everybody’s gone to the rapture”, which can visually highlight objects emitting relevant audio.
There are several sets of guidelines to which game developers can refer for help and advice on content design decisions that can afford accessibility to various different groups of people — check out the references section at the end for more info.
What’s missing?
Sometimes it’s not possible to provide content to cater for all situations. (In fact this is partly why closed captions were introduced to the Source engine: to allow the games to be marketed in areas where the developers didn’t have the resources to provide full localised character voice recordings, as recounted in the GamesCC Interview with Marc Laidlaw from Valve.)
Even if we wanted to support all possible choices users might have for reading the game’s user interface and using their preferred input devices, then we’d have to provide the following content…
Audio for every UI element…
…in several languages
…at several speeds
Make sure it’s navigable with a keyboard…
…and a mouse
…and works with a controller
…and with a single switch
There’s also the fact that sometimes, content comes not from the game’s developers directly, but from other players. This could include communications from other players (or maybe even procedurally-generated content from the game, for which pre-recording isn’t possible). It’s vital that people with disabilities are able to take part in such communication, and it is also now a legal requirement in the U.S. that communications functions in games (including the user interfaces necessary to reach them) are accessible (Ian Hamilton’s ’blog has more info on the 21st Century Communications and Video Accessibility Act (CVAA)).
Whilst content is essential to the game experience and ensuring it’s compelling and enjoyable, it can only take us so far. The player still needs to be able to navigate that content, particularly the game’s user interface, and understand and interact with it in a way that works for them. With websites and apps, users have access to various tools that can provide them with such access…
Assistive technologies and user interface accessibility
Screen-readers, screen-magnifiers, alternative modes of visual and auditory presentation and the ability to use different input devices are common in the mainstream world of desktop and mobile websites and apps. These assistive technologies are able to interpret information coded into websites and apps, and expose that to their users, e.g. by speaking that content, or expressing it as Braille, or in larger text, for example.
When native apps use standard widgets/controls provided by the Operating System (OS), they’re accessible because those controls automatically come with the required accessibility information. The screen-reader (for example) sits between the OS and apps, and can query for this information.
App
Accessibility layer → Assistive technology
Operating system
But games, in order to present a distinct and self-contained identity, and to promote immersion and entertainment, almost always use custom user interface elements that are entirely graphical in nature (even words on the screen are rendered as pixels ultimately, and the underlying text is not exposed to the Operating System).
Some consoles and gaming platforms are beginning to provide accessibility APIs such as text-to-speech (e.g. Xbox Narrator), which is excellent, though it’s still early days for such features, and they’re not available on all platforms.
The Unreal and Unity engines are those on which the majority of new games are based, and Unreal has recently started supporting preliminary screen-readers directly, with support from Unity expected to follow. This is excellent news for the industry, and is the path that most games will likely use towards improved accessibility in future. In parallel I have been wondering if all the existing infrastructure we have in browsers might help us bridge the user interface gap mentioned above, and support accessibility when games are delivered via the web, and by any engine…
The web and user interface accessibility
Assistive technologies work in a similar way with web sites and web apps as with native apps. The browser provides an accessibility tree that exposes various properties of the elements in the page’s Document Object Model (DOM) tree (such as the types of controls they represent, or their text content), mirroring its structure. The accessibility tree is then picked up by assistive technologies.
Web site/app
Accessibility tree → Assistive technology
Browser
The best (simplest) way to provide accessibility on the web is to use the standard HTML elements for the job. Using the standard HTML elements automatically brings the needed accessibility information (the purpose of the element; its content; its label, state and value, if it’s a form control). The “native” HTML elements also provide accessible keyboard handling by default, such as Space to activate a button and Enter to follow a link.
The following code shows a standard button, link and “landmark region” demarcating where the primary content on the page (which makes it easy for screen-reader users to find).
However, if we’d used elements with no inherent meaning, no accessibility information would be there to convey. This sometimes happens when web developers make custom controls, instead of using the native elements. However, we could add the semantics using ARIA attributes. This fills in the gaps in the accessibility tree for assistive technologies. (Though that’s all it does, so keyboard handling code would need to be added manually to fill in that which would’ve been provided by the native elements above.)
The following code is semantically equivalent to the native HTML elements given above.
OK
Sazerac recipe
Important
Assistive technologies (e.g. screen-readers) can pick up on these cues, but how is this relevant to games?
Web game user interface accessibility proof-of-concept
Somewhere in the code behind the game, the intent of various user interface controls, and the text displayed, is present in a form that could be made accessible. The challenge is how to bridge from this information to players’ assistive technologies.
Many games these days, especially educational games are developed for the web, or web-like platforms (Wikipedia article on Web Games). In addition, the technologies exist to compile native code into a format that can be run efficiently in the browser: WebAssembly. This technology can be used to achieve near-native speeds — in fact one of the early prototypes was running the then-latest Unreal game engine in the browser! (Unreal Engine 3 in-browser; Unreal Engine 4 in-browser).
Instead of compiling a game to run natively on the computer’s hardware…
Source code, e.g. in C, is compiled directly to a form that will run on the computer’s hardware
The native code can be compiled to WebAssembly binary format (a “.wasm” file) and run in a browser alongside existing JavaScript code…
Source code, e.g. in C or Rust, is compiled to WebAssembly and then run in a browser alongside the general accessibility library (JavaScript code that creates and manages the proxy UI elements)
The browser gives us a ready-made opportunity to expose the accessibility information. It works as follows…
A library of JavaScript code sits in the browser and provides a simple API to create HTML elements that match the visual-but-not-semantic user interface controls in the game.
We add a small amount of accessibility code to the existing native game’s source code, which is included only when compiling to WebAssembly. This provides the information to the JavaScript in the browser to create the proxy UI elements.
The JavaScript accessibility layer code moves focus around the proxy objects, in synch with the focus management that the game is doing visually, in response to the player’s inputs. This causes the player’s screen-reader to announce the proxy widgets at the same time the in-game widgets are displayed on-screen.
Thus, it seems like the game’s user interface has been made accessible, as it is conveyed by the user’s screen-reader. Here are some screengrabs of the system in action, with the rendered game on the left and the proxy UI elements (which would normally be visually hidden) on the right…
Example game main menu, featuring links to “New Game”, “Options” and “Help” menus, and an “Exit” button, with the first item in both the rendered game menu and the proxy UI area focused. All of the options are grouped in a fieldset element with a legend of “Main Menu”.
When the user presses the down arrow, the next menu item is highlighted in-game, and the next proxy button element is focused behind the scenes, causing the player’s screen-reader to announce the change.
The same image as above, with the second item, “Options”, focused
In theory, issues such as focus handling and keyboard interaction should be fairly easy to solve, even if they are not accessible out-of-the-box, as the game UI has to be operable as-is, and usually this is supported by the keyboard (or a game controller, which could be emulated by a keyboard within the host OS). The main goal of the in-browser accessibility layer is to create the proxy objects for the UI that the user’s assistive technologies can understand.
The figures above show the use of links in the proxy UI area to represent sub-menus and a button to represent an immediate action. Input controls are required for a fully interactive UI too. The following figures demonstrate custom rendered controls that map to textboxes and sliders, with their labels appropriately associated.
Player options screen showing textboxes for specifying the player’s name and team nameSound options screen showing slider/range controls proxying the custom volume controls used in-game
Potential efficiency improvements
With this approach, real DOM elements must be created on the host web page. Whilst they can be hidden, we know they’re there. Also, the code used to create them is JavaScript, which is slower than the WebAssembly code and the browser’s internal APIs that are called to actually create and expose these proxy elements to assistive technologies.
There’s an upcoming standard called Accessibility Object Model (AOM) that provides for much more fine-grained control over the accessibility tree exposed by the browser. In fact, it removes the need for there to be real elements in the DOM, so this could be bypassed. What’s more: the Accessibility Object Model APIs are implemented in the browser’s (native) code, and are thus more efficient. On top of all of this, there’s a new method for WebAssembly code to directly call into the APIs provided by the browser, bypassing the need for JavaScript completely. This could make the whole UI proxying process vastly more efficient.
There is a consequence of this, however: the code to manage the Accessibility Object Model would have to be moved into the WebAssembly sphere, meaning that it would have to be provided by the game — or, most likely, the engine/middleware being used. This is not really a problem, as it makes sense for an engine to provide this code in a real-world scenario. Effectively decreasing the distance between the game developer and the accessibility code means there’d likely be opportunities to make the authoring tools more supportive of creating accessible user interfaces. For example, a lot could potentially be automated.
Next steps
These explorations demonstrate that, for games compiled to the web, it’s possible to make use of people’s existing assistive technologies such as screen-readers to expose any accessibility information that the game might provide.
Native games should use the accessibility support forming in the main game engines, but in the cases where games are delivered via the web, or are based on different technology stacks, this approach may be of help. It certainly demonstrates just how far browsers and assistive technologies have come in terms of performance and capability in recent years. There are two areas I’m continuing to explore…
Adapting existing in-game GUIs and games to use this approach. By doing this, a standard and minimal “accessibility layer” could be created that could be adopted to convey UI semantics to the browser, with minimal intervention from the developer.
Investigating how use of the upcoming Accessibility Object Model (AOM) standard might make things more efficient, and any other possibilities it might open up.
I’ll be talking about the latest developments in this work at the CSUN Accessibility conference in March 2020 — if you’re going to be in town, pop in and say hello, and if you can’t make it, then check out The Paciello Group ’blog, where we’ll post the slides afterwards.
It’s awesome to build sites that are inclusive and accessible to everyone. There are at least six key areas of disability we can optimize for: visual, hearing, mobility, cognition, speech and neural. Many tools and resources can help here, even if you’re totally new to web accessibility.
Over 1 billion people live with some form of disability. You might have been in a loud room at some point trying to hear the conversation around you or in a low-lighting condition trying to find something in the dark. Do you remember the frustration you felt with that circumstance? Now, imagine if that temporary condition was permanent. How different would your experience on the web be?
To be accessible, sites need to work across multiple devices with varying screen-sizes and different kinds of input, such as screen readers. Moreover, sites should be usable by the broadest group of users, including those with disabilities. Here are a sample of just a few disabilities your users may have:
Vision
Hearing
Mobility
– Low vision – Blind – Color blind – Cataracts – Sun glare
– Hard of hearing – Deaf – Noise – Ear infection
– Broken arm – Spinal cord injury – Limited dexterity – Hands full
Ensure all user interface components can be used with assistive technologies such as screen readers, magnifiers and braille displays. This entails ensuring that UI components are marked up such that accessibility APIs can programmatically determine the role, state, value and title of any element.
Tip: Inspect element in Chrome, Edge and Firefox DevTools displays a tooltip of CSS properties that includes a quick check for color contrast ratio.
I personally live with low-vision and am embarrassed to say, I’m that person that always zooms in on sites, their DevTools and terminal. While supporting zoom is almost never at the top of anyone’s list, optimizing for low-vision users is always appreciated… ?
Hearing issues mean a user may have issues hearing sound emitted from a page.
Make the content understandable using text alternatives for all content that is not strictly text.
Ensure you test that your UI components are still functional without sound.
Mobility issues can include the inability to operate a mouse, a keyboard or touch-screen.
Ensure pages are correctly marked up for assistive technologies; these users may use technologies such as voice control software and physical switch controls, which tend to use the same APIs as other assistive technologies like screen readers.
Cognitive issues mean a user may require assistive technologies to help them with reading text, so it’s important to ensure text alternatives exist.
Be mindful when using animations. Avoid a visual presentation that is repetitive or flashing as this can cause some users issues.
The prefers-reduced-motion CSS media query allows you to limit animations and autoplaying videos for users who prefer reduced motion.
/*
If the user expressed a preference for reduced motion, don't use animations on buttons.
*/@media(prefers-reduced-motion:reduce){button{animation:none;}}
Avoid interactions that are timing-based.
This may seem like a lot of bases to cover, but we’ll walk through the process for assessing and then improving the accessibility of your UI components.
When auditing your page’s UI components for accessibility, ask yourself:
Can you use your UI component with the keyboard only? Does it manage to focus and avoid focus traps? Can it respond to the appropriate keyboard events?
Can you use your UI component with a screen reader? Have you provided text alternatives for any information which is presented visually? Have you added semantic information using ARIA?
Can your UI component work without sound? Turn off your speakers and go through your use cases.
Can it work without color? Ensure your UI component can be used by someone who cannot see colors. A helpful tool for simulating color blindness is a Chrome extension called SEE, (try all four forms of color blindness simulation available). You may also be interested in the Daltonize extension which is similarly useful.
Can your UI component work with high-contrast mode enabled? All modern operating systems support a high contrast mode. High Contrast is a Chrome extension available that can help here.
Native controls (such as and ) have accessibility built-in by the browser. They are focusable using the tab key, respond to keyboard events (like Enter, space and arrow keys), and have semantic roles, states and properties used by accessibility tools. The default styling should also meet the accessibility requirements listed above.
Custom UI components (with the exception of components that extend native elements like ) do not have any built-in functionality, including accessibility, so this needs to be provided by you. A good place to start when implementing accessibility is to compare your components to an analogous native element (or a combination of several native elements, depending on how complex your component is).
Tip: Most browser DevTools support inspecting the accessibility tree of a page. In Chrome, this is available via the Accessibility tab in the Elements panel.
Firefox also has an Accessibility panel and Safari exposes this information in the Element’s panel Node tab.
The following is a list of questions you can ask yourself when attempting to make your UI components more accessible.
Can your UI component be used with the keyboard alone?
Ideally, ensure that all functionality in your UI component can be reached by a keyboard. During your UX design, think about how you would use your element with the keyboard alone, and figure out a consistent set of keyboard interactions.
Firstly, ensure that you have a sensible focus target for each component. For example, a complex component like a menu may be one focus target within a page, but should then manage focus within itself so that the active menu item always takes focus.
Managing focus within a complex element
Using tabindex
The tabindex attribute allows elements / UI components to be focused using the keyboard. Keyboard-only and assistive technology users both need to be able to place keyboard focus on elements in order to interact with them. Native interactive elements are implicitly focusable, so they don’t need a tabindex attribute unless we wish to change their position in the tab order.
There are three types of tabindex values:
tabindex=”0″ is the most common, and will place the element in the “natural” tab order (defined by the DOM order).
a tabindex value greater than 0 will place the element in a manual tab order — all elements in the page with a positive tabindex value will be visited in numerical order before elements in the natural tab order.
a tabindex value equal to -1 will cause the element to be programmatically focusable, but not in the tab order.
For custom UI components, always use tabindex values of 0 or -1, as you won’t be able to determine the order of elements on a given page ahead of time — and even if we did, they may be subject to change. A tabindex value of -1 is particularly useful for managing focus within complex components as described above.
Also ensure that focus is always visible, whether by allowing the default focus ring style, or applying a discernible focus style. Remember not to trap the keyboard user — focus should be able to be moved away from an element using only the keyboard.
You may also be interested in the roving tabindex or aria-activedescendant approaches, covered over on MDN.
Using autofocus
The HTML autofocus attribute allows an author to specify that a particular element should automatically take focus when the page is loaded. It is already supported on all web form controls, including . To autofocus elements in your own custom UI components, call the focus() method supported on all HTML elements that can be focused (e.g document.querySelector('myButton').focus()).
Adding keyboard interaction
Once your UI component is focusable, try to provide a good keyboard interaction story when a component is focused, by handling appropriate keyboard events — for example, allow the user to use arrow keys to select menu options, and space or enter to activate buttons. The ARIA design patterns guide provides some guidance here.
Finally, ensure that your keyboard shortcuts are discoverable. For example, a common practice is to have a keyboard shortcut legend (on-screen text) to inform the user that shortcuts exist. For example, “Press ? for keyboard shortcuts”. Alternatively a hint such a tooltip could be used to inform the user about the shortcut existing.
The importance of managing focus cannot be understated. One example is a navigation drawer. If adding a UI component to the page you need to direct focus to an element inside of it otherwise users may have to tab through the entire page to get there. This can be a frustrating experience, so be sure to test focus for all keyboard navigable components in your page.
Tip: You can use Puppeteer to automate running keyboard accessibility tests for toggling UI states. WalkMe Engineering have a great guide on this I recommend reading.
// Example for expanding and collapsing a category with the spacebar keyconstcategory=awaitpage.$(`.category`);// verify tabIndex, role and focusexpect(awaitpage.evaluate(elem=>elem.getAttribute(`role`),category)).toEqual(`button`);expect(awaitpage.evaluate(elem=>elem.getAttribute(`tabindex`),category)).toEqual(`0`);expect(awaitpage.evaluate(elem=>window.document.activeElement===elem,category)).toEqual(true);// verify aria-expanded = falseexpect(awaitpage.evaluate(elem=>elem.getAttribute(`aria-expanded`),category)).toEqual(`false`);// toggle category by press spaceawaitpage.keyboard.press('Space');// verify aria-expanded = trueexpect(awaitpage.evaluate(elem=>elem.getAttribute(`aria-expanded`),category)).toEqual(`true`);
Can you use your UI component with a screen reader?
Around 1–2% of users will be using a screen reader. Can you determine all important information and interact with the component using the screen reader and keyboard alone?
The following questions should help guide you in addressing screen reader accessibility:
Do all components and images have meaningful text alternatives?
Wherever information about the name or purpose of an interactive component is conveyed visually, an accessible text alternative needs to be provided.
For example, if your UI component only displays an icon such as a Settings menu icon to indicate that it is a settings menu, it needs an accessible text alternative such as “settings”, which conveys the same information. Depending on context, this may use an alt attribute, an aria-label attribute, an aria-labelledby attribute, or plain text in the Shadow DOM. You can find general technical tips in WebAIM Quick Reference.
Any UI component which displays an image should provide a mechanism for providing alternative text for that image, analogous to the alt attribute.
Do your components provide semantic information?
Assistive technology conveys semantic information which is otherwise expressed to sighted users via visual cues such as formatting, cursor style, or position. Native elements have this semantic information built-in by the browser, but for custom components you need to use ARIA to add this information in.
As a rule of thumb, any component which listens to a mouse click or hover event should not only have some kind of keyboard event listener, but also an ARIA role and potentially ARIA states and attributes.
For example, a custom UI component might take an ARIA role of slider, which has some related ARIA attributes: aria-valuenow, aria-valuemin and aria-valuemax. By binding these attributes to the relevant properties on your custom component, you can allow users of assistive technology to interact with the element and change its value, and even cause the visual presentation of the element to change accordingly.
Can users understand everything without relying on color?
Color shouldn’t be used as the only means of conveying information, such as indicating a status, prompting for a response or distinguishing a visual custom component. For example, if you created an component using color to distinguish between heavy, moderate and light traffic, an alternative means of distinguishing traffic levels should also be made available: one solution might be to hover over an element to display information in a tooltip.
Is there sufficient contrast between the text/images and the background?
Any text content displayed in your component should meet the minimum (AA) contrast bar. Consider providing a high-contrast theme which meets the higher (AAA) bar, and also ensure that user agent style sheets can be applied if users require extreme contrast or different colors. You can use this Color Contrast Checker as an aid when doing design.
Is the moving or flashing content in your components stoppable and safe?
Content that moves, scrolls or blinks that lasts for anything more than 5 seconds should be able to be paused, stopped or hidden. In general, try to flash no more than three times per second.
Accessibility Tooling
A number of tools are available that can assist with debugging the accessibility of your visual components.
Axe provides automated accessibility testing for your framework or browser of choice. Axe Puppeteer can be used for writing automated accessibility tests.
The Lighthouse Accessibility audits provide helpful insights for discovering common accessibility issues. The accessibility score is a weighted average of all accessibility audits, based on Axe user impact assessments. For monitoring accessibility via continuous integration, see Lighthouse CI.
Tenon.io is useful for testing common accessibility problems. Tenon has strong integration support across build tools, browsers (via extensions) and even text editors.
There are many library and framework specific tools for highlighting accessibility issues with components. e.g web.dev covers using eslint-plugin-jsx-a11y to highlight accessibility issues for React components in your editor:
If you use Angular, codelyzer provides in-editor accessibility audits too:
You can examine the way that assistive technologies see web content by using Accessibility Inspector (Mac), or Windows Automation API Testing Tools and AccProbe (Windows). Additionally you can see the full accessibility tree that Chrome creates by navigating to chrome://accessibility.
The best way to test for screen reader support on a Mac is using the VoiceOver utility. You can use ⌘F5 to enable/disable, Ctrl Option ←→ to move through the page and Ctrl Shift Option ↑↓ to move up/down tree. For more detailed instructions, see the full list of VoiceOver commands and the list of VoiceOver Web commands.
tota11y is a useful visualiser for assistive technology issues built by Khan Academy. It’s a script that adds a button to your document that triggers several plugins for annotating things like insufficient contrast ratio and other a11y violations.
On Windows, NVDA is a free, open source screen reader which is fully featured and rapidly gaining in popularity. However, note that it has a much steeper learning curve for sighted users than VoiceOver.
ChromeLens helps develop for the visually impaired. It’s also got great support for visualising keyboard navigation paths http://chromelens.xyz/
ChromeVox is a screen reader which is available as a Chrome extension, and built in on ChromeOS devices.
We still have a long way to go improving accessibility on the web. Per the Web Almanac:
4 out of every 5 sites have text which easily blends into the background, making it unreadable.
49.91% of pages still fail to provide alt attributes for some of their images
Only 24% of pages that use buttons or links include textual labels with these controls.
Only 22.33% of pages provide labels for all their form inputs.
To learn more about accessibility fundamentals to help us improve the above, I recommend the Accessible to all docs on web.dev. There’s much we can do to build experiences that are more inclusive of everyone.
Accessibility has a great impact on user experience (UX). Creating an accessible website ensures that people, regardless of their physical or mental limitations, can obtain the information they need and communicate with your organization like the rest of the world.
With internet technology becoming mainstream, making your fully accessible is more important than ever. Adhering to the web accessibility standards is a legal requirement (as provided in the American Disability Act of 1990). Public and private organizations also consider it a social responsibility.
Building and Construction Accessibility.
Physical access to offices, healthcare facilities, schools, and commercial establishments is a basic civil right. When constructing a building, the owner should ensure that accessibility is incorporated into the planning and design process. For example, people in wheelchairs should be able to conveniently enter a building through the presence of ramps or via elevators. There should be parking areas allocated only for clients or guests with disabilities, doors should be kept open where possible, signs must be placed where customers can easily see them, and specialized devices or equipment that cater to their needs should be made available.
Website Accessibility.
The federal law requires that all public accommodations should be accessible to anyone with or without a disability. With billions of people using the internet to transact with government offices, buying all sorts of stuff online, booking a hotel, flight or restaurant reservations, searching for local businesses, etc, it is also important that websites are made accessible and navigable to them.
When designing a website, a lot of developers and business owners tend to overlook the importance of website accessibility. What they don’t realize is that it compromises their brand, hurts their reputation, and increases their risk of lawsuits.
The Americans with Disabilities Act (ADA) is a comprehensive law aimed to protect the rights of people with disabilities. It requires that all offices, organizations, or institutions (public or private) make their goods or services accessible to those with physical or cognitive limitations.
While web accessibility was not specifically outlined in the ADA, it is considered part of Title III: Public Accommodations. ADA compliance is a hot topic today and many businesses have faced lawsuits because of violations due to non compliance.
What is Section 508?
Also known as 508 Compliance, it is the shorthand for the law requiring government websites to be accessible for people with disabilities. It is an amendment to the Workforce Rehabilitation Act of 1973 which basically requires accessibility on all federal electronic and information technology (EIT).
What is WCAG?
Because the ADA does not directly define web accessibility and it’s scope, web designers and developers refer to the Web Content Accessibility Guidelines (WCAG). It is a set of international standards that provides specific recommendations on how to make websites accessible.
Differences between WCAG 2.0 and 2.1
WCAG 2.1 is the updated version of the guide which was published early in 2018. It defines the success criteria provided in 2.0 but with a few more additions to address mobile accessibility, people with low vision, and people with cognitive and learning disabilities. It’s important to note that WCAG 2.1 conforms to 2.0 which means that the accessibility requirements outlined in the WCAG 2.1 are the same as that of the earlier version.
What is VPAT?
The Voluntary Product Accessibility Template (VPAT) was originally used as a tool to conduct government research on the use of information and communications technology (ICT). Now, it is being utilized to test a website’s accessibility in conformance to the rules and regulations provided in the ADA and Section 5.
When it comes to website design, we often think about aesthetics. Of course, to attract more visitors, we want to make our websites beautiful with beautiful fonts, graphics, buttons, and other visual elements.
But creating a website that is both beautiful and accessible is possible. When designing your website, consider the following steps:
Enable keyboard navigation for web design.
ADA-compliant websites are keyboard-accessible. This means that all their functionalities can be accessed through the keyboard. In addition to traditional keyboards, note that some disabled users make use of specialized computer keyboards. Thus, your website navigation order must be logical and intuitive. This means it should follow a visual flow, such as “right to left” or “top to bottom”. Basically, you want to make it easy for users to navigate links, buttons, and form controls on your website via their keyboards.
Prioritize text clarity.
Written content such as articles page info and calls-to-actions should be easy to read. Vision problems like color blindness, near or farsightedness, cataract, and low vision are among the most common disabilities not just in the U.S. but in the world. Thus, it only makes sense to prioritize text clarity when designing websites.
Don’t rely exclusively on color.
While color is important, they are not the only consideration to make when creating an accessible user interface. The font style and size are important too. Times New Roman, Verdana, Arial, and Calibri are among the most recommended font styles.
Order content in HTML for screen readers.
When structuring content, always consider how it can be accessed by people that use screen readers. These are devices that translate digital text into synthesized speech. Note that a screen reader presents content linearly or one item at a time.
Add explanatory link text.
Providing a text description can help users distinguish one link from the others and determine whether to follow the link. When the link redirects users to an image, the text alternative will describe the unique function of the link. If it contains both text and an image, the description can be used to describe both the content and the image.
Use a 40×40 pt. clickable area for touch controls.
People with mobility issues make use of touch controls to navigate the web. When creating the layout of your web interface, provide enough space for CTAs and other clickable areas.
Do not forget to follow the accessibility checklist.
An accessibility checklist ensures that all parts of your website adhere to the WCAG. Everything from the images, colors, text, audio, video, navigation, site structure, forms, and text elements.
Accessible web design does not only lead to better experience among users with disabilities but also among those who do not have disabilities or limitations. Many accessibility requirements improve user experience, particularly in limiting situations.
For example, the use of contrasting colors or easy-to-ready fonts benefits people accessing a website from a small screen (such as a mobile phone) or in a dark room. Text alternative benefits users with limited bandwidth while audio transcription is a great tool for users who are unable to use earphones to access audio content.
Websites that follow the WCAG and ADA-requirements for web accessibility can benefit from creating a page solely for accessibility information. A great example of an accessibility guide is the one from the BBC website. It outlines how users can navigate and make the most from their website if they are blind, can’t see very well, unable to hear, or unable to use the keyboard or mouse to browse. Meanwhile, the accessibility statement is a powerful declaration of their commitment to making their site accessible. It includes information about the company’s accessibility goals and the methods they are using to achieve them.
After making the necessary changes, web designers should test whether they have achieved their accessibility goals.
Accessibility testing can be done in two ways: manual or automated. Accessibility firms like Be Accessible Inc. combine these approaches by using tools and conducting end-user testing involving real people with disabilities to examine the accessibility of a website.
Usability testing, on the other hand, is carried out to determine how useful the website is based on several criteria, such as learnability, efficiency, and user satisfaction. A more practical and effective way for businesses to measure the usability and accessibility of their websites is by outsourcing it to a third-party testing company.
Accessibility, in a nutshell, is usability for all.
It ensures that everyone has equal access to your website, no matter what limitations or disabilities they have.
Accessible websites have all elements from the text to the visuals and audio components available for people with disabilities.
It’s hard to cater to all disabilities, but by following the recommendations provided by the WCAG, Section 508, and relevant policies on accessibility, you can make your website usable and accessible for people with varying disabilities.
There’s an article circulating that claims accessibility and aesthetics are at odds with each other, creating a paradox that forces us to compromise. Here’s why I find that belief completely and utterly false:
The article claims that if we are “too accessible,” we will meet the needs of the minority but end up hurting those of the majority. This creates a false equivalence between having legitimate access needs and having a preference for a certain aesthetic.
Let’s assume two people are looking at a poster to check for movie times. Person A can read it just fine, but Person B can’t read it at all. The words are too small and the colors are too faint to see. So Person B requests a new poster.
The movie theater takes the feedback into account and releases a new poster. Now, both people can read it. But Person A doesn’t think it looks nice.
These needs are simply not the same.
The majority-minority mentality itself is a harmful way to divide people. To provide an example of how this plays out in planning, the 80–20 rule suggests that we should focus development efforts on the majority use case that plays out 80% of the time.
Oftentimes, ableist people use this as an excuse to avoid designing for disabled people. That’s not what this rule is actually about. This rule is intended to focus on the most common user goals and scenarios. Take a pet supply online store, for example. If 80% of people want to buy pet food, we can de-prioritize the case where 20% of people want a treat tasting subscription service. But people should be able to buy pet food whether they are Blind, or Deaf, or have cerebral palsy, or have any kind of disability that requires accessibility.
Edge cases refer to scenarios, not humans.
The article constantly compares people with visual impairments to people with “normal vision.”
Normal is a lazy word. When people say someone is normal, they usually mean able-bodied. Or white. Or cisgender. Or male. Or heterosexual. Normal is an othering tool because it implies marginalized people are abnormal.
In an age where technology is constantly straining our eyes, breaking our posture, and forcing us into sedentary lifestyles, having access needs is normal. When nearly 13% Americans have a disability and nearly 75% use some sort of vision correction, disability is normal (disability source, vision source).
Rather than use the word normal, I find it’s helpful to use specific terms:
Blind vs. sighted
Deaf vs. hearing
Disabled vs. non-disabled
Disabled vs. able-bodied
Instead of acting as an inhibitor, accessibility is often a driving factor in aesthetics. You don’t need to sacrifice aesthetics in order to be accessible (and if you think the two concepts are polar opposites of each other, I don’t think you’re trying hard enough).
To prove it, here are some of my favorite examples of beautiful accessible design:
OXO Swivel
Eames leg splint
RX bar packaging
Prime Access Consulting
Gov.UK design system
Cash App
(None of these were paid product endorsements.)
OXO Swivel
Kitchen tools like potato peelers were notoriously difficult to use. Fashioned purely out of thin metal rods, they often hurt to hold, especially for people with arthritis.
(It’s worth noting that this was a health issue that disproportionately affected women, since they were often expected to carry out household labor without complaining.)
OXO released their Good Grips line in 1990, with the swivel peeler as their flagship product designed specifically for people with arthritis. It’s significantly easier to grip and has a charming, bold look. I personally love the contrast between the chunky black handle and the thin, metal peeler.
Eames leg splint
Disabled veterans were a major reason why accessibility became a top issue in post WWII America. Specifically, medics found the standard metal leg splint actually made injuries worse and needed a better solution, so they went to the Eames designers.
Charles and Ray Eames, arguably the two most famous industrial designers in history, were commissioned to design a light-weight, easily manufacturable leg splint for veterans. They created the splint using bent plywood (their most well-known medium of choice). I find this object really elegant and impressive to look at, and far more friendly than the metal version.
RX Bar packaging
Most packaged foods list the ingredients on the back in fine print, making it difficult and sometimes impossible to read.
(This poses a real issue to folks with allergies and specific dietary needs.)
RX Bar values transparency in their design by listing all the ingredients in big bold letters. This benefits people with low vision, and ultimately everyone who wants to take a closer look at the ingredients. I find the simplicity of this package design makes a beautiful, bold impact.
Prime Access Consulting and Purple Rock Scissors
Prime Access Consulting (PAC) is a consultancy that specializes in accessibility and inclusion. They do a lot of impressive work, especially for museums, which are historically inaccessible to Blind folks.
(When we think about visually accessible design it’s important to consider that Black and Indigenous people have higher rates of visual impairment, so this is as much a race issue as a disability issue. source)
PAC has created braille labels and audio recordings for Cooper Hewitt, a bold new website for the Field Museum and MCA Chicago with high contrast and large touch targets, and an image description management system called the Coyote Project.
Purple Rock Scissors is an independent strategic creative agency. They specialize in a holistic approach including UX design, content, business strategy, and agile tech.
Compare the Louvre’s site with that of the Field Museum’s, which Purple Rock Scissors redesigned while also consulting Sina, the founder of PAC.
The visual clutter on the Louvre’s site is distracting and makes it difficult to look for and focus on what you want to do. In comparison, the clean aesthetic of the Field Museum’s site — with big bold text, helpful visuals, and clear call to actions — is more accessible and better looking. Purple Rock Scissors has an awesome case study about this project.
GOV.UK Design System
Government agencies are required to meet rigorous accessibility standards (as they should, they serve the people). But I think anyone who has used a government institution’s website can relate to these sites being difficult to use. Often stuck in the 90’s, they typically have small font sizes, overly dense text, and are not responsive on mobile.
Compare, for example, the San Francisco Department of Public Health’s website with that of GOV.UK.
What a big difference. Not only was the SF website full of clutter but I swear it took about 10 seconds to fully load all the images (on my Google chrome browser). In comparison the GOV.UK site places all the essential information front and center and took about 1 second to load. I find their high contrast, simple writing, and clear status messages really supportive and highly aesthetic.
Related to the UK design system is Adam Silver’s website. Adam is currently a designer for the UK ministry and also writes a blog about creating accessible UI. His site is intentionally very clean, with large font sizes and clever use of white space. I think it creates a really pleasant look overall.
Cash App
I use Venmo, Paypal, Chase Pay, and Cash App to send money to people. In my experience, most of these apps have several distracting elements on the screen. Especially on Venmo and Chase Pay, I have to navigate through several options before I find what I need. (And Venmo keeps showing me other people’s transactions? Why?)
In my opinion, Cash App is the most intuitive. When you open it, you can immediately request or pay money without having to navigate to another page. Its simple interface creates a playful and minimalist look.
Update: Cash App is definitely aesthetic and almost accessible! The color contrast runs just shy of passing WCAG compliance. Here’s a comparison chart showing what the app would look like at AA large, AA, and AAA. Thanks to the very observant reader for that catch.
And many more
I shared some of the most notable examples of beautiful accessible design that come to mind, though I want to point out that there are many more examples out there that I didn’t mention.
If any come to mind that you want to share, comment or tweet at me @thetuttingtutor.
Of course disability rights is about disabled people.
It’s also about women. And race. And class. Every social issue is also a disability issue. This means accessibility is not just a matter of compliance, it’s a means of working toward restorative justice.
When we talk about accessibility, we have to talk about systemic barriers as well. It is completely legal for employers to pay disabled people below minimum wage (source). The state can take away benefits when they get married (source). The healthcare industry charges them exorbitant prices for medical care (see the price of insulin) and mobility aids (see the price of wheelchairs).
When we pit aesthetics and accessibility against each other, we are complacent in the systems that create barriers for disabled people. When we prioritize aesthetics over accessibility — as subjective as that judgment may be — we actively oppress disabled people further.
However…
When we declutter our designs to focus on the essentials, we create minimalist interfaces that are accessible for people with cognitive disabilities. And aesthetic.
When we design objects to be ergonomic and naturally form with our bodies, we create products that are accessible to physically disabled people. And aesthetic.
When we up the contrast, increase the font size, and choose a clear typeface, we become accessible to people with low vision. And aesthetic.
Accessibility drives aesthetics because the ability to use something is beautiful.
12–02–2019: Made correction that Purple Rock Scissors redesigned the Field Museum website, not PAC. Apologies for the misinformation.
If you’re working on web design projects, then it follows that web accessibility should be one of your top user experience considerations. Whether it’s finessing on-page readability for users with visual impairment, or ensuring that your web page’s visual cues remain effective on mobile devices, sometimes color alone may be what’s standing between you and a truly accessible and inclusive design.
One of the most important considerations is contrast ratio — or the luminance relationship between light and dark elements (most often text) in your design. Users with certain cognitive disabilities may require lower contrast text, while low vision readers may need high contrast user interface considerations in the visual design they consume.
Likewise, color blindness is also a consideration that needs the attention of any designer implementing a design process which strives towards equitable, accessible design.
The good news is that there are a handful of inexpensive — and even free — tools that can help you become more cognizant of design for all, and how you can help people equitably experience the design you’re creating.
1. Contrast
Contrast is a macOS app that offers designers a way, like its namesake, to immediately gauge the contrast ratio of color choices to assure they are in alignment with Web Content Accessibility Guidelines (WCAG). An app that’s built for immediate feedback without being a burden to your design workflow, Contrast also offers a guide on their site that acts as a primer on some of the WCAG accessibility standards.
The app acts as a small menu bar which you can integrate into whatever design software you’re using, or move the menu bar around your desktop to use as a floating window anywhere else on your screen.
2. Color Safe
If you’re looking for an in-browser option, Color Safe is a web-based tool that allows designers to generate color palettes based on WCAG standards for contrast ratio. Simply select your project’s background color, font family, font size and weight — plus the WCAG standard you’re trying to achieve — and Color Safe will generate palettes whose contrast ratio scores you can compare.
3. Tanaguru Contrast-Finder
Tanaguru Contrast-Finder is an easy-to-use, web-based tool that allows you to simply enter your preferred foreground and background colors (in either RGB or as a hex code) to monitor your design’s contrast ratio. The tool allows you to select your desired minimum contrast ratio scores, while also generating a list of adjacent colors to evaluate.
These provided alternatives also come with in-use samples of different text sizes, weights, and their resultant contrast ratios — giving you a sense for which color and text choices will not only be more accessible, but play nicely together as part of your overall design.
4. Stark
With plugins for Adobe XD, Figma, and Sketch, Stark is a plugin that features a suite of tools to foster accessible and inclusive design standards — right from within the software designers are already working with. Stark’s contrast checker tool allows designers to double-check that their typography and font size — in conjunction with the design’s background colors or supporting visuals — provides the necessary legibility and sufficient contrast to harmonize with accessibility guidelines.
As a bonus, Stark also assists with additional accessibility issues, including color-blindness. The app allows designers to view their work in color-blindness simulation and make tweaks to their design system.
5. Spectrum
Spectrum is also a free tool that can assist you as you design with color-blind users in mind. A free Google Chrome extension developed by Yehor Lvivski, Spectrum also allows designers to directly test their sites across a range of over eight different versions of color vision deficiencies, including an array of red-green and blue-yellow color blindness.
With over 200 million people in the world who are visually impaired, web accessibility should be a top consideration in every designer’s process. Now that you’ve got some handy apps in your toolkit, it’s your turn to get out there and make the web a more accessible place for all!
This week I’ve been brooding about web performance and accessibility. It all began when Ethan Marcotte made a lot of great notes about the accessibility issues that are common with AMP:
In the recordings above, I’m trying to navigate through the AMP Story. And as I do, VoiceOver describes a page that’s impossible to understand: the arrows to go back or forward are simply announced as “button”; most images are missing text equivalents, which is why the screen reader spells out each and every character of their filenames; and when a story’s content is visible on screen, it’s almost impossible to access. I’d like to say that this one AMP Story was an outlier, but each of the nine demos listed on the AMP Stories website sound just as incomprehensible in VoiceOver.
Ethan continues to argue that these issues are so common in AMP that accessibility must not be a priority at all:
Since the beginning, Google has insisted AMP is the best solution for the web’s performance problem. And Google’s used its market dominance to force publishers to adopt the framework, going so far as to suggest that AMP’s the only format you need to publish pages on the web. But we’ve reached a point where AMP may “solve” the web’s performance issues by supercharging the web’s accessibility problem, excluding even more people from accessing the content they deserve.
I’ve been thinking a lot about this lately — about how accessibility work is often seen as an additional feature that can be tacked onto a project later — rather than accessibility work being a core principle or standard of working on the web.
And I’ve seen this sentiment expressed time and time again, in the frameworks, on Twitter, in the design process, in the development process, and so much so that arguing about the importance of accessibility can get pretty exhausting. Because at some point we’re not arguing about the importance of accessibility but the importance of front-end development itself as a series of worthy skills to have. Skills that can’t be replaced.
I love fast software. That is, software speedy both in function and interface. Software with minimal to no lag between wanting to activate or manipulate something and the thing happening. Lightness.
Later in the piece, Mod describes fast software as being the very definition of good software and argues that every action on a computer — whether that’s a website or an app — should feel as if you’re moving without any latency whatsoever. And I couldn’t agree more; every loading screen and wait time is in some degree a mark of failure.
The takeaway here is that you literally can’t afford desktop or iPhone levels of JS if you’re trying to make good web experiences for anyone but the world’s richest users, and that likely means re-evaluating your toolchain.
I’m sort of a jerk when it comes to this stuff. I don’t think a website can be good until it’s fast. The kind of fast that takes your breath away. As fast as human thought, or even faster. And so my point here is that web performance isn’t something we should aspire to, it should be the standard. The status quo. The baseline that our work is judged by. It ought to be un-shippable until the thing is fast.
The good news is that it’s easier than ever to ship a website with these base requirements of unparalleled speed and accessibility! We have Page Speed Insights, and Web Page Test, not to mention the ability to have Lighthouse perform audits with every commit in GitHub automatically as we work. Ire Aderinokun showed us how to do this not so long ago by setting up a performance budget and learning how to stick to it.
The tools to make our websites fast and accessible are here but we’re not using them. And that’s what makes me mad.
While I’m on this rant — and before I get off my particularly high horse — I think it’s important to make note of Deb Chachra’s argument that “any sufficiently advanced negligence is indistinguishable from malice.” With that in mind, it’s not just bad software design and development if a website is slow. Performance and accessibility aren’t features that can linger at the bottom of a Jira board to be considered later when it’s convenient.
Instead we must start to see inaccessible and slow websites for what they are: a form of cruelty. And if we want to build a web that is truly a World Wide Web, a place for all and everyone, a web that is accessible and fast for as many people as possible, and one that will outlive us all, then first we must make our websites something else altogether; we must make them kind.
