Seven easy-to-implement guidelines to design a more accessible web.

Digital refers to the practice of building digital content and applications that can be used by a wide range of people, including individuals who have visual, motor, auditory, speech, or cognitive disabilities.

There’s a myth that making a website accessible is difficult and expensive, but it doesn’t have to. a product from scratch that meets the requirements for accessibility doesn’t add extra features or content; therefore there shouldn’t be additional cost and effort.

Fixing a site that is already inaccessible may require some effort, though. When I used to work at Carbon Health, we checked the accessibility of our site using the AXE Chrome Extension. We found 28 violations that we needed to solve on the home page alone. It sounded complicated, but we discovered that these problems were not that to correct; it was just a matter of investing time and research to solve them. We were able to get to zero errors in a couple of days.

I want to share with you some of the simple steps we took so you can also make your sites more accessible. These principles focus on web and mobile accessibility.

But before we get started, let’s talk about why that’s important.

Why designing for accessibility?

As designers, we have the power and responsibility to make sure that everyone has access to what we create regardless of ability, context, or situation. The great thing about making our work accessible is that it brings a better experience to everyone.

There are over 56 million people in the United States (nearly 1 in 5) and over 1 billion people worldwide who have a disability. In 2017, there were 814 website accessibility lawsuits filed in federal and state courts. These two pieces of data alone should convince us of the importance of designing for accessibility.

There is also a strong business case for accessibility: studies show that accessible websites have better search results, they reach a bigger audience, they’re SEO friendly, have faster download times, they encourage good coding practices, and they always have better usability.

These seven guidelines are relatively easy to implement and can help your products get closer to meet level AA of the Web Content Accessibility Guidelines (WCAG 2.0), and work on the most commonly used assistive technologies — including screen readers, screen magnifiers, and speech recognition tools.

1. Add enough color contrast.

Buttons with good color contrast are easier to read for Guadalupe.

Color contrast is an often overlooked web accessibility problem. People who have low vision could find it difficult to read text from a background color if it has low contrast. In a fact sheet on visual impairment and blindness, the World Health Organization (WHO) estimates that there are 217 million who have moderate to severe vision impairment. So, it is critical to consider the sufficient contrast between text and backgrounds.

According to the W3C, the contrast ratio between text and its background should be at least 4.5 to 1 (conformance level AA.) The ratios become more forgiving with larger and heavier fonts since they’re easier to read at lower contrast. If your type is at least 18 px or 14 px bold, the minimum contrast ratio drops to 3 to 1.

Some tools will help you check this quickly. If you use a Mac, I recommend getting the Contrast app, with this tool you can instantly check contrast using a color picker. If you want to get a more detailed score, I recommend entering your color values onto the WebAIM color contrast checker. This tool will calculate the score for both regular and larger text sizes in different conformance levels (A, AA, AAA.) You can change the color values and see the results in real time.

Source: WCAG Visual Contrast

2. Don’t use color alone to make critical information understandable.

René gets happy when graphs are colorblind friendly!

When you’re communicating something important, showing an action, or prompting a response, don’t use color as the only visual cue. People with low visual acuity or color blindness will have a hard time understanding your content.

Try to use an indicator other than color such as text labels or patterns. When showing errors on the screen, don’t rely on colored text alone, add an icon or include a title to the message. Consider adding a visual cue such as font weight or underline text style to linked text in a paragraph, so the links stand out.

Elements with more complex information like charts and graphs can be especially hard to read when you only use color to distinguish the data. Use other visual aspects to communicate information like shape, labels, and size. You can also try incorporating patterns into your fills to make the differences more apparent. A great example of this guideline is Trello’s colorblind mode. When turned on, labels become more accessible by adding texture.

A good trick is to print your graph in black and white and see if you can still understand everything in it. You can also use an app like Color Oracle, which shows you in real time what people with common color vision impairments see. These tips help you make sure that the information in your site is color-agnostic.

Source: WCAG Visual Contrast Without Color

3. Design usable focus states.

Focus states are easy to navigate with Tyler’s prosthetic hand.

Have you noticed the blue outlines that sometimes show up around links, inputs, and buttons? These outlines are called focus indicators. Browsers, by default, use a CSS pseudo class to show these outlines on elements when they’re selected. You might find these default focus indicators not very pretty and be tempted just to hide them. However, if you get rid of this default style, be sure to replace it with something else.

Focus indicators help people know which element has the keyboard focus and help them understand where they are when navigating your site. These are used by people who are blind and require screen readers, individuals with limited mobility, individuals who have suffered injuries like carpal tunnel, and power users who prefer this type of navigation. Oh, and some of us use the keyboard as their primary way of navigating the web!

The elements that should be focusable are links, form fields, widgets, buttons, and menu items. They need to have a focus indicator that makes them look different from the elements around them.

You can design focus indicators that fit the style of your site and goes well with your brand. Create a state that is highly visible, with good contrast, so it stands out from the rest of the content.

Source: W3C Focus Visible

4. Use labels or instructions with form fields and inputs.

Mr. López keeps trying to turn a placeholder text into a label.

Using placeholder text as labels are one of the biggest mistakes when designing a form. We might be tempted to go with this trend when real estate is limited or want to make our design more simple and modern—don’t. Placeholder text is usually gray and has low contrast, so it’s hard to read. If you are like me, you usually forget what you’re even writing, so it’s hard to know what the fields are about once the label is gone.

People who use screen readers usually navigate through a form using the Tab key to jump through the form controls. The <label> elements are read for each form control. Any non-label text, as placeholder text, is usually skipped over.

Always help people understand what they should do and write in a form. It’s best if labels don’t go away, even when the person is filling an input; people should never lose context with what they’re writing. When designers hide descriptions or directions in their forms, they’re sacrificing usability in favor of simplicity.

This practice doesn’t mean that you have to clutter your design with unnecessary information, just make sure to provide essential cues. Too much instructional text can be just as much of a problem as too little. The goal is to confirm that the individual has enough information to complete their tasks without friction.

Source: WebAIM Creating Accessible Forms

5. Write useful alternative text for your images and other non-text content.

Robin found a new friend in a picture.

People with low vision often make use of screen readers to “hear” the web. These tools convert text to speech so that the person can hear the words on a site.

There are two ways that you can present alternative text.

  • Within the <alt> attribute of the image element.
  • Within context or surroundings of the image itself.

Try to describe what’s happening in the image, and how it matters to the story, rather than just saying something like “picture,” context is everything.

If the image is purely decorative or if it creates redundancy because the surrounding context already explains the content. Then adding an empty <alt> attribute will make screen readers skip it. If you don’t write any alt text, some screen readers will read the file name to the individual. That’s the worst experience you can provide.

Google is working on an image captioning AI that can describe photos with 94% accuracy. This model is open sourced and still in research — hopefully, we’ll start seeing it used in different products. In the meantime, we should manually provide text that describes the meaning and function of the images in our content.

Source: W3C Using Alt Attributes

6. Use correct markup on your content.

Headings mark where the content starts — they’re tags given to text to define its style and purpose. Headings also establish the hierarchy of the content of the page.

Titles with big font sizes help a reader understand the order of the content better. Likewise, screen readers also use heading tags to read content. This way, people with low-vision get an overview of the page by reading each heading in a hierarchal flow.

It’s important to use proper structural elements when you develop a site. HTML elements communicate to the browser what kind of content they contain and how the browser should render or treat that content. The components and structure of a page are what arranges an accessibility tree. This tree is what powers screen readers which are used by people who are blind so they can “listen” to a page.

Not using markup correctly affects accessibility. Don’t use HTML tags for a style effect only. Screen readers navigate web pages by heading structure (true headers, not just text that is styled big and bold) hierarchically. The people that use your site can listen to a list of all of the headings, jump the content by types of titles, or navigate directly to top-level headings <h1>.

Source: WebAIM Semantic Structure

7. Support keyboard navigation.

Keyboard accessibility is one of the most critical aspects of web accessibility. People with motor disabilities, blind people that rely on screen readers, people that don’t have precise muscle control, and even power users are dependent on a keyboard to navigate content.

If you’re like me, you’ll typically use the Tab key on your keyboard to navigate through interactive elements on a web page: links, buttons, or input fields. The focus state that we discussed before provides a visual indicator of the component that is currently selected.

As you navigate through a page, the order of the interactive elements is essential, and the navigation must be logical and intuitive. The tab order should follow the visual flow of the page: left to right, top to bottom — header, main navigation, content buttons and inputs, and finally the footer.

A good practice is testing your site only using a keyboard. Use the Tab key to move through links and forms. Test using the Enter key to select an element. Verify that all the interactive components are predictable and in order. If you can navigate through all your site without a mouse, you’re in a good spot!

Last, but not least. Be careful with the size of your navigation — this includes the number of links and the length of the text. Tabbing through long menus may be demanding for people with motor disabilities. And listening to lengthy links can be cumbersome for people that use screen readers—try to be concise. Providing ARIA landmarks or HTML5 structural elements like <main> or <nav> will make navigation easier.

Source: W3C Keyboard

Beyond these guidelines.

These seven guidelines are a great start, and if you want to do more to make your product more accessible, I encourage you to

  • Get an Accessibility Audit. Use an audit service to find out if your product works with assistive technologies and meets WCAG 2.0 level AA. Use the audit results to fix problems and do another test.
  • Appoint an Auditor. You can appoint someone in your company to do recurrent accessibility audits. This could be someone in your QA team. If you don’t have someone with the experience, you can hire an external supplier.
  • Make accessibility part of your design research. When doing research verify if your assumptions concerning accessibility were right and if there are any potential opportunities to improve. Recruiting people with disabilities requires a bit more work. Don’t hesitate to contact associations, and communities—people are willing to help.

Conclusion.

That’s it. Seven guidelines that will help you make your web design get closer to meet level AA of the Web Content Accessibility Guidelines.

Designing for accessibility is something that I’m still trying to improve. I’m working on practicing what I preach. I used to think that it was too hard and not that important. I was mistaken. I invite you to consider these guidelines as part of your process and continue the conversation on why accessibility matters.

As designers, it is our responsibility to champion accessibility. With it, we make technology usable to all people regardless of their abilities, economic situation, age, education, or geographic location.

Design responsibly. Thank you.





Source link https://uxdesign.cc/designing-for-accessibility-is-not-that-hard-c04cc4779d94?source=rss—-138adf9c44c—4

LEAVE A REPLY

Please enter your comment!
Please enter your name here