large_Crossover Series NFTs.png

medium_Crossover Series NFTs.png

small_Crossover Series NFTs.png

thumbnail_Crossover Series NFTs.png

From Photography to NFT Art: Twisted Digital Landscapes with Nate Hill

From Design System to ‘NFT Design System’: Creating TinyFaces

Neurodiversity and Inclusion: Choosing Kinder Design

medium_652ccf22c8853584bde5553986a4eed0.png

small_652ccf22c8853584bde5553986a4eed0.png

thumbnail_652ccf22c8853584bde5553986a4eed0.png

Web5 is here. Goodbye Web3? TBD.

<a href="http://ift.tt/2pfZPCH">uxdesign.cc &ndash; User Experience Design &mdash; Medium</a> | Adhithya 
<h4>A comprehensive visual guide to making web technology available to a diverse world.</h4>
<img alt="" src="http://ift.tt/2obGhy6">This post is part of <a href="http://ift.tt/2ohu63C">the journey of the team at uxdesign.cc on learning more about Diversity and Design</a> — and sharing what they learn along the way.
<blockquote>ac·ces·si·bil·i·ty: the quality of being able to be reached or entered.</blockquote>
<img alt="" src="http://ift.tt/2iWF11L">
<h3>What is accessibility and why is it important?</h3>
In a diverse world like ours, we cannot simply assume that all the users access and experience digital products in the same way. That&#8217;s when accessibility becomes a crucial element of the design process that has inclusion and diversity in mind.
An accessible product — in it’s simplest sense is making sure that all of your users can consume your content. The products we work on are designed with the perceived majority of our users in mind — users who do not experience any difficulty in using a web or mobile application. In many cases, there is very little thought that is put into designing components for most products that work for almost any user — be it someone who has a broken hand, someone who’s hard of hearing, or someone who has visual impairments.
<img alt="" src="http://ift.tt/2objbrE">
Digging deeper into <a href="http://ift.tt/1Km7LsK">accessibility statistics</a>, it was found that close to 56.7 million Americans, that is 18.7% of the U.S population, experience some type of disability. Out of this number, it was found that 38.3 million have serious disability problems. This accounts for 12.6% of the entire U.S population.
These are figures are as of 2012, for just one country. When scaled up to the entire population of the world, these numbers would reach an alarming point, and it is no more a case of a “minority user base”.
<blockquote>Accessible design aids in creating a better experience not just for people with disability, but also for people without it.</blockquote>
<img alt="" src="http://ift.tt/2oFZMC2">Curbed ramps. Image courtesy: Google
Curbed ramps have been designed for helping people in a wheelchair move around cities. This also has a plethora of other uses — parents walking the streets with strollers, people out for a run, people using the sidewalk to skate etc.
<img alt="" src="http://ift.tt/2obBGMH">Push to open doors. Image Courtesy: Google
Push to open buttons have been installed in most buildings to help people on a wheelchair open doors. This is also used by people to open doors when they’re carrying a lot of bags, or a child, or just use it all the time because it is easier than pulling/pushing doors open.
<a href="http://ift.tt/1I8CGTd">Section 508 Law</a> mandates that federal agencies have their digital/electronic applications accessible to people with disability. Companies have a minimum required level of compliance based on <a href="http://ift.tt/1Oi9gs1">WCAG</a> to aid people with disability in using their products a lot easier.
<blockquote>More than laws and compliance rules, is it not just human to make sure that our products can be more widely used?</blockquote>
It is important to not view accessibility as a checkbox that you need to tick to meet requirements, but as a tool that helps to design for people, those we have been ignoring all these years.
<img alt="" src="http://ift.tt/2iWF11L">
<h3>Current landscape of Assistive Technologies</h3>
Before delving deeper into patterns, do’s and don’ts, it is imperative to get an understanding of how existing assistive technologies for the web work. The Mac OS comes with <a href="http://ift.tt/2hsSRWg">VoiceOver</a>, and Windows users have the option of using NVDA (<a href="http://ift.tt/2loVsDk">NonVisual Desktop Access</a>).
<blockquote>It is highly recommended to try using a website by dimming the screen brightness and using assistive technologies such as VoiceOver or NVDA. This would help designers empathize with how users who are differently abled use the computer.</blockquote>
Assistive technologies for the web read three attributes of any component that is focused through tabbing — Role, Name, and Value.
<img alt="" src="http://ift.tt/2oG9rc5">Role, name and value are represented at the bottom of the screen.
<h3>Recommended visual patterns for an accessible interface</h3>
<h3>1. Color Contrast</h3>
The first step towards an accessible UI is to get the color contrast for your product right.
<img alt="" src="http://ift.tt/2oblASX">Recommended contrast for web applications.
<blockquote>The recommended contrast is 3:1 for large text and 4.5:1 for small text.</blockquote>
What does this mean? The readability created from the difference of foreground and the background color is the contrast generated. Large text is any font larger than 18px when bold, or larger than 24px for regular font-weight. Small text is anything smaller than 18px.
Tools that help with contrast check <a href="http://colorsafe.co/">Color Safe</a> is a great tool if you are starting a project fresh and want to figure out beforehand what colors work for accessibility.
However, products we work on already have an established color guide, or a set of brand colors to choose from. In such cases, it is important to find contrast ratios of colors from the product’s palette. <a href="http://ift.tt/RtjACE">WebAim</a> is the go-to tool for such checks.
Quickly identifying areas to improve contrast Even the process of checking on WebAim for each of your foreground and background combinations can be a daunting task. A quick way to run a first-pass to get a sense of probable trouble points in your design is by using a nifty Chrome tool called <a href="http://ift.tt/1xbJ4qL">Color Contrast Analyzer</a> developed by awesome folks at NCSU.
<img alt="" src="http://ift.tt/2oG5zHV">From this quick analysis, it is clear that the subtitles on each of these articles have poor contrast ratios and could use some work to make the page accessible.
This quickly identifies areas that require work on a screen. The areas on a screen that maintain good contrast is highlighted by white lines, and areas with poor contrast have subtle outlines that are not very prominent.
<h3>2. Focus</h3>
Focus is one of the most important accessibility features that enables users to use a computer with only a keyboard without the need for a mouse. Most reset stylesheets have this one line of code that causes major accessibility failure &#8211;
<pre>:focus { outline: 0; }</pre>
This is an anti-pattern that needs to be avoided like the plague. Keyboard only users know what elements on the page they are interacting with the help of focus styles.
<blockquote>Focus highlighting should be used only for interactive components within a page such as form elements, buttons etc.</blockquote>
There are websites out there, in the attempt to make their content more accessible, the heading and body text is tweaked programmatically to highlight on focus. This is absolutely unnecessary effort as screen readers would read the content out by default and directing focus to such content particularly does not help in any way. There are a few caveats to this rule which will be discussed later with examples.
<h4>Focus Contrast</h4>
As a rule of thumb, it is necessary to have the focus color as distinct as possible from your background color.
<img alt="" src="http://ift.tt/2obBFs7">Left: The contrast is poor and competes with the background hence making it difficult to spot the elements being focused . Right: The contrast is clear enough to differentiate the focus elements.
<h4>Off-screen content</h4>
When off-screen content hidden from the viewport exists in the form of hamburger menus, modals etc, it is likely that when a user is tabbing through focus points, they would lose track of the focus as it is highlighting something that is off the working area. This can cause confusion and make users lose track of their current position on the screen.
<img alt="" src="http://ift.tt/2oGmJoH">Left: What users see when they are tabbing through off-screen elements. Right: The actual position of the focus. When the menu is closed, the flow of focus is obfuscated to the user.
Recommended Solution: One way to tackle this issue is by either hiding the elements when the menu is closed with CSS with display: none, or making sure the focus does not enter the menu when collapsed by programmatically altering the flow of focus with JavaScript.
<h4>Modals</h4>
Modals are another type of off-screen elements that can be a huge accessibility disaster when not executed fittingly. When a user is navigating within the modal, it is necessary for the focus to remain within the modal and not move through points behind the modal.
<blockquote>This is one of those rare use-cases where it is okay to programmatically force the focus to get to the title of the modal window to ensure that users are not deviating from the intended flow.</blockquote>
<img alt="" src="http://ift.tt/2obpA61">Left: The focus is outside the modal after tabbing through a few times. User loses control of actions within the modal. Right: The focus alternates between the two available options until the user decides to close the modal.
<h4>Hover States and Focus</h4>
Hover states and focus have different functionality. Many products have actions hidden under hover states. A good example is Facebook’s hover states for reactions.
<img alt="" src="http://ift.tt/2oGhvcK">Facebook has actions within hover states. They do a great job of highlighting it on focus as well, making it navigable for keyboard only users.
A bad example is Product Hunt’s cards. They show multiple actions that become visible only on hover which is not keyboard-only accessible.
<img alt="" src="http://ift.tt/2obGiSG">Product Hunt, on the other hand, has specific actions (highlighted above) that show up on hover. These actions are not visible on focus and makes it hard for keyboard only users to perform those actions.<img alt="" src="http://ift.tt/2oG5AvC">Left: Focus ignoring on hover actions and jumping to the next focus element. Right:Focus states allowing users to perform actions that are hidden within a mouse-hover state.
<h4>Scenarios to “re-focus”</h4>
When an UI element on the page is removed from a user’s action, it is important to refocus to an element within the context of the current working area. A good example to this is when a user decides to delete an item — the focus disappears from the current element and moves to the top of the page. There is a clear need to bring the focus back to an element after the deleted item.
<img alt="" src="http://ift.tt/2obhr1s">Left: After deleting the list item, the focus is lost. The user might have to tab through all the way again to reach this point. Right: The focus is shifted to the next element on the list thereby making the browsing experience more continuous.
<h3>3. Click Targets</h3>
<h4>Cards</h4>
Cards are very prominently used in products these days. Thanks to Material Design, there is a lot of structure and guidance over how cards should be designed. However, it is important to create accessibility-friendly ones. Cards can get quickly complex with multiple states based on the type of interaction being performed on them.
Another bad example of card design are cards used on the Product Hunt page (Sorry guys, I really love Product Hunt but this seemed like another apt example). Imagine a user tabbing through these cards without using a mouse.
<img alt="" src="http://ift.tt/2oGeLfw">Is it possible to identify which card is being focused? If you look closely, you’d realize it is the second card. It is hard to identify this for even people with 20/20 (perfect) vision.
A great example of how cards can be made accessible is Google Inbox —
<img alt="" src="http://ift.tt/2obxwEi">
☑ They assign specific focus states for cards when they are navigated to. ☑ They hover action is accomplished when on focus. ☑ Only actionable items are focused and not every element within the card.
<h4>Target Areas</h4>
Users with motor impairments find it hard to select items on the page with precision. It is our job as designers to make sure that target areas are not very narrow or hard to access.
<img alt="" src="http://ift.tt/2oGdZ1Y">Left: Very narrow click target areas. Right: Considerably better target areas to click on.
<h3>4. Quick Access to Content</h3>
If you are a user navigating with only a keyboard, and you would like to get to the content immediately. But, there is a high possibility that there are multiple menu items or other navigational items before you can actually get to the content of your product.
It can be a pain for users to sift through each one of those links before they can get a glimpse of the product.
Below is an example of a bad experience from a very famous blogging platform —
<img alt="" src="http://ift.tt/2obu2Sr">A user has to tab through multiple links before they can get to the content of the page.
One possible solution to this problem is by providing a quick way for users to jump to the content as they start tabbing through the product. Below is an example of how AirBnB achieves this.
<img alt="" src="http://ift.tt/2oG1Zxy">Left: Before a user focuses. Right: Skip to Content option for users to jump to content directly instead of tabbing through each menu item.
<h3>5. Summarizing Information</h3>
It is tricky to get an ideal experience when a user with accessibility needs is going through a checkout process, or any flow that consists of multiple steps. Use-cases to such a scenario can be —
<ol>
<li>Booking a flight ticket.</li>
<li>Searching after filtering with a bunch of options.</li>
<li>Adding items to a cart and checking them out.</li>
</ol>
<blockquote>It is of primal importance to give the user a summary of information that is being entered before or after they hit the call to action.</blockquote>
This rule holds applicable in UI components such as a date picker, steppers or setup wizard etc. This is particularly tricky because you don’t want redundant information to be visible for users without accessibility needs.
Recommended Solution: When users are tabbing through information, there could be elements that I’d like to call “Ghost elements” that show up only when a user tabs through complex UI components such as date pickers. These ghost elements contain a brief summary of the selected value that the screen reader can read out to users for confirmation.
<img alt="" src="http://ift.tt/2obsjMS">A quick summary of selected values on complex input fields like a date-picker is presented to the user who is tabbing through the interface.
Such an approach is usually critiqued as power users who navigate with keyboard faster will have to tab through twice to get to the next element. This is when the accessibility toggle comes into the picture.
<h3>6. Accessibility Toggle</h3>
For most products, it is a small, yet important fraction, of users who require assistance for a better experience. To not interfere with the experience for the larger fraction of users, there should exist a switch that toggles between accessibility mode and default mode.
The accessibility mode should contain a color scheme that offers high contrast and easy navigation between elements on the page especially when it is in the form of keyboard-only interaction.
<img alt="" src="http://ift.tt/2oGeNnE">
<h3>Closing Thoughts</h3>
Accessibility should be inscribed early in the design process as it gets harder to allocate resources and time for handling it as a standalone project. Every component or pattern designed should be vetted with accessibility as a parameter.
There will be a detailed how-to on methods — to write code for web-accessibility and how to test it — in an article that would follow this.
I am interested in learning more about your process for designing accessible products in comments below.
<img alt="" src="http://ift.tt/2iWF11L">
We have invited <a href="http://ift.tt/1MJSJvF">Adhithya</a> to be part of this series for his work with accessibility at OpenDNS. Making our products accessible is a crucial step for a more inclusive design in our diverse world.
See you in <a href="http://ift.tt/2ohu63C">the next article</a>.
<iframe src="http://ift.tt/2iFGGW9" width="800" height="400" frameborder="0"><a href="http://ift.tt/2h0f00F">http://ift.tt/2h0f00F</a></iframe><img src="http://ift.tt/2obEHwl" width="1" height="1" alt="stat?event=post.clientViewed&amp;referrerSou">
<hr>
<a href="http://ift.tt/2oG9Xqc">Designing Accessible Products</a> was originally published in <a href="https://uxdesign.cc">uxdesign.cc</a> on Medium, where people are continuing the conversation by highlighting and responding to this story.

Designing Accessible Products

Designing Accessible Products

A comprehensive visual guide to making web technology available to a diverse world.

Top Stories