This guidelines were created on the base of the WCAG 2.1 and will be following the four principles stated by the WCAG (Perceivable, Operable, Understandable & Robust). The WCAG principles are divided into three A levels (A, AA, AAA) and in this guidelines we are covering mainly A level, while in some parts AA level.

With this guide we aim to provide easy to understand context for designers and how to include accessibility(A11y) aspects while designing or reviewing already finished designs. For all the categories we will show examples, how the design can look without A11y applied and how it changes once you include Accessibility to it. You will also find a list of useful plugins and tools to help you with checking certain A11y features. At the end, you will get a A11y checklist template, which you can duplicate and reuse in you design files to help you track your A11y status.

About WCAG

The Web Content Accessibility Guidelines, or WCAG in short, are the world’s most comprehensive and robust guidelines for making your website accessible to disabled individuals.

WCAG is developed by the World Wide Web Consortium (W3C)—yes, the people who invented the Internet.
An international community that comprises member organizations, staff, and the public, W3C concentrates its efforts to standardize the Web, developing protocols and guidelines that ensure the long-term growth of the Internet for all.

The emphasis here is indeed on ALL, including those with impairments of all sorts and types.
WCAG is the ultimate standard for web accessibility guidelines, providing a single shared standard that meets the needs of individuals, organizations, and governments internationally.

It is important to note that WCAG is not codified into law, as the integration between disability non-discriminatory legislation and Web accessibility is still a process in the making.

Nonetheless, governments across the globe have endorsed the WCAG standard in various forms, court rulings included, which places WCAG as the primary and safest standard for Web owners, developers, and designers.
In short, WCAG compliance is the assured path toward compatibility with the law and accessibility for the disabled.

The 4 WCAG principles

WCAG is organized around the four following principles, which are the absolute fundamentals of accessibility provision on the Web.

1. Perceivable

   If the disabled are to gain equal access to the Web, all information and user interface components must be perceived by at least one or more of their senses.

2. Operable

   People with disabilities must be able to operate the website, provided with operable interface and navigation components.

3. Understandable

   If those with impairments don’t understand what your website is offering, then it is inaccessible to them. Users must understand the information as well as the operation of interface components.

4. Robust

   When the content is robust, users have more options, and a wide range of disability issues can be answered. Those with disabilities must be able to access the content as technologies advance.

Perceivable

All content on the page/screen must be presented in a way users can perceive it.

Include text alternatives

Actionable Elements must have an appropriate ID name. While images need to be provided with a brief description of what there is on the image. That way users who use screen readers are able to understand the meaning and intent behind the read elements.

Decorative elements do not require a text alternative.

Include audio & video captions/transcripts

For audio & video content there needs to be a provided set of transcripts or captions. That way users with hearing and vision difficulties can access the content through reading or listening the text alternatve with screen readers. Communicate this to content providers and include an access point in your design where users can get to those transcripts or content descriptions.

Avoid image dependency

Avoid placing important information inside an image. Images can be stretched, the right Color contrast may not be met, content inside can become blurred or pixelated, all which makes it harder for users to perceive it.

Include audio playing controls

Avoid using automatic audio playing as the sound may interfere with users who use screen readers. Make sure your design includes volume and play/pause controls.

Respect small text ⁠–⁠ 4.5:1 color contrast ratio

Small text (defined below) needs to pass the 4.5:1 color contrast ratio in order to achieve maximum readability.

• Bold text = 13pt and below
• Regular text = 17pt and below

Respect large text ⁠–⁠ 3:1 color contrast ratio

Large text (defined below) needs to pass the 3:1 color contrast ratio in order to achieve maximum readability.

• Bold text = 14pt and up
• Regular text = 18pt and up

Respect non-text elements contrast ratio

For every actionable or critical element you need to make sure there is enough contrast for it to be easily distinguishable. For elements 16px and above follow the rule of 3:1, and for elements below 16px follow the rule of 4:5:1.

Avoid color dependency

Don’t rely solely on color to convey information. For different lighting conditions and for visually impaired or color blind users it will be harder to perceive different colors on the screen.

Add visual cues that help users distinguish the difference between elements they are looking at. (e.g. underline for links, active tabs with a dot or a line indicator or different stroke and fill options etc.)

Operable

Users must be able to operate and navigate through the content of your digital product without obstacles.

Skip repetitive content blocks

Have an option to skip repetitive content that repeats itself on every page/screen, so that the users with disabilities who use screen readers will be able to click on it and bypass the repetitive blocks to get to the main content more easily.

Allow users to exit a situation

Enable users to easily get out of a situation (for example a window) with providing a clear closing option.

Link or button purpose is understood

Avoid ambiguous links or buttons that don’t convey much meaning. Instead, be more descriptive so that the purpose of the button or a link could be understood by the text alone.

Ensure touch-target area is big enough

When designing buttons or any clickable element, make sure that the touch target area is visible enough for users to be able to understand the element is clickable. Aim to have at least 48px of width and 48px of height. Even if you are creating smaller elements, such as icons, the touch target area should be 48x48px. Ensure clickable elements are separated by 8px of space or more.

Focus state & order

Define focus states for your actionable elements and align with developers on the right focus order. Users who navigate with keyboards, voice-overs or any support assistive technology, need to have elements pointed out as it helps them understand where they are within the page/screen.

Default focused states are provided by different browsers, as well as on mobile platforms when screen reader feature is active. However, default focus states are not always obvious or they may not function well with your design.

Extend time-dependent functionalities

Ideally, don’t have content or any performance on websites or apps that is time-dependent. But if there’s a need to have one (e.g. security tokens), it is important that users see and are aware of the time remaining and that they have an option to extend the time in order to perform.

Include option to turn off automatic updates

If you have content that moves or updates automatically, users need to have an option to pause, hide or stop this automatic movements from happening.

Reduce blinking and flashing elements

void using flashing elements that may provoke seizures or physical reactions. If you are using flashing elements, then make sure the flash rate is 3 times per second or less. Ensure that flashing objects cover only a small area. If you can, opt for a static content instead a moving, blinking or a flashing one.

Understandable

All content on the page/screen must be readable and understandable to users.

Include a page title

Ensure all pages and screens have a title that accurately represents the content of the page/screen user is viewing.

Structure & element order

When designing, think of the intended order of the elements. Align with developers what should be the correct order of the items, so that when users who use screen readers are able to understand the right order and context of the read elements.

Grouping sections

When designing, aim to have distinctive groups of items, where each group has its own heading. If the group doesn’t have a visual heading, align with developers on what are the different sections of your design, or mark it in your design file. That way, when using screen readers, users can understand all the different groups and sections of the designed page/screen more easily and decide which section to skip if needed.

Language selection

If content of your product has option to support multiple langauges, then make sure language selection is presented upfront, before user can continue interacting with the product.

Do not change context without user confirmation

Context of the page/screen shouldn’t be changed without user confirming it in some way. Before any change happens, there needs to be a clear question and an option user can choose from. If there is not a question in ask, then user needs to have a clear confirmation action, before any context changes.

Clearly identify errors

Clearly indicate where and what type of error took place. Focus the element in question, provide an error text next to it and describe what the issue is.

Provide labels and cues to avoid mistakes

Avoid user mistakes by adding simple instructions or cues so users understand what is asked of them. Also, don’t avoid using labels, as they help users to clearly understand which form are they filling out.

Simplify content

Use simple sentences and communicate in a conversational tone, friendly and polite. Don’t confuse users with too much information and complicated words or descriptions. By using simple sentence formulation content is understood faster and more easily.

Use visual support for complex information

Use images, colors and shapes as a support to visually help users digest complex graphs or blocks of information. But do not rely solely on it.

Don’t rely solely on sensory characteristics

Don’t rely only on shape, color, size, visual location, orientation, or sound of an element for users to understand its intent, as visually impaired users will not be able to understand or perceive it. Use clear instructions or labels that provide meaning to users.

Support scalable UI

Be aware that users can increase or decrease font sizes on their browsers or devices. This may impact readability of elements. Make sure your UI can adapt to these changes. Consider designing your elements for scenarios where font size is increased by its maximum and decreased to its minimum.

The Art of Choosing Typefaces in UI Design

Robust

Allow content to be interpreted by a wide variety of assistive technologies or different devices.

Avoid being platform-specific

Users who use assistive technologies may not be able to tap or click to perform a function. Communicate your action in a way it can cover a wider range of usage.

Useful Plugins and Tools

Here is an overview of useful plugins to help you in reviewing or noting down certain A11y features.

A11y Color Contrast

It works only for text components.

Checks the color contrast ratio of all visible text in a frame, and it provides feedback on wheteher it meets WCAG’s AA and/or AAA level compliance.

Color sliders allow users to adjust the colors and understand how the corresponding contrast ratio changes in real-time.

Currently only supports single, 100% solid fills.

A11y Focus Orderer

Bulk add, remove, reorder, and update your annotations.

Keep all focus-order annotations in a single layer group that can be toggled on / off.

Load existing focus-order annotation layers from previous sessions to resume editing.

Focus order embedded in metadata.

Create multiple annotation sets that can be named, and styled with a different color.

Able – Friction free accessibility

Compares the contrast between two layers you select.

Simulates different types of color blindness on your selected layers in the preview.

Copy the contrast ratio and scores and paste them into your color style descriptions as documentation.

Adee

You can test color contrast and apply changes.

Simulate 8 color blind simulations and generate them.

Test touch target sizes to make sure they meet the various device standards and share test results with your team.

Stark

Offers contrast checking and smart color suggestions.

You can preview your screens in different types of color blindness.

You can create annotations for focus order.

Color Blind

Allows you to view your designs in the 8 different types of color vision deficiencies.

Accessibility Scanner

Suggests improvements such as enlarging small touch targets, increasing contrast, and providing content descriptions so that your app can be more easily used by individuals with accessibility needs.

Accessibility Inspector – Xcode

You can ran Accessibility Inspector in xCode (Apple’s integrated development environment for macOS), which is used to develop software for macOS, iOS, iPadOS, watchOS, and tvOS.

The Accessibility Inspector enables you to identify parts of your app that are not accessible. It detects: small touch target areas, contrast ratio issues, non-accessible elements, and more.

Go to Xcode’s top menu, Open Developer Tools, Accessibility Inspector. Select the simulator and start inspecting, auditing or modifying system’s settings in your app.

Align with your iOS development and QA team for using Xcode app

Wave

WAVE® is a suite of evaluation tools that helps authors make their web content more accessible to individuals with disabilities.

Can identify many accessibility and Web Content Accessibility Guideline (WCAG) errors.

Test out your website by entering a web page address (URL).

Accessibility Review

Even when something may seem as a common sense to you, you will be surprised of how many things you overlook during your design phase. And when it comes to A11y principles, most probably your product will not pass the basic A level of accessiblity. In order to help you and your team know how you stand, it is important to conduct accessibility reviews.

When should you do an Accessiblity review?

To create an app or a website that is accessible and suitable for everyone, it’s crucial to keep accessibility in mind from the earliest stages of design and development. If accessibility concerns are addressed at some later stages, it is significantly more difficult to fix them. But, it is advisable to periodically review product’s accessibility, to catch possible issues that occured during development phase.

• Best way to start is when you first start designing your product. While you are designing you can simultaneously check and keep in mind all the principles and guidelines.

• Align with other members of your team or use annotations in your design file to communicate certain A11y levels that require syncing with the rest of the team.

• For certain parts, that can only be reviewed after the product is implemented, you will have to align with QA and development team for testing it out. Usually, QA should be responsiblefor reviewing voice-overs, touch target areas, font scaling etc.

• If you didn’t design your product by following the A11y principles, then you will need to ask your project managers to provide you time on the project for doing this review. It will probably take 2-3 days for you to review your designs. However, that depends on the scale of the product.

• Probably the best time to include this it is when you are in the phase of offering suggestions and improvements to your product.

• Lastly, if you start getting complaints that your product can not be used in certain conditions, that will be your red alarm for start reviewing and implementing A11y principles.

How to conduct an Accessibility review?

• Go over our 4 chapters to learn about Perceivable, Operable, Understandable and Robust principles.

• For each category guideline see an example in order to understand its purpose.

• Plan out the review strategically and however you find it easier for you.

• Strategic ways to divide the review: per platforms, per A11y categories, per app’s main navigation and hierarchy.

• You can perform the review on your design file or the implemented product.

• Use plugins & tools to check specific A11y points.

• Use the checklist template to note down the A11y status of your designs. (P.S. It will be a useful type of documenation for project managers and product owners too).

• Don’t feel overwhelmed. Review the parts that are in your domain and power to do so. The product you are helping to create should be a mutual responsibility between the whole project team. So, covering A11y should be a shared responsibility between the client, content provider, development team, product owner, project manager, software tester, product strategist, data analyst and you, the designer.

• Align with QA (software testers) on performing certain parts of the review. QA should test out the implemented product and check how the app or site is usable with voice-over, touch target areas, dynamic font scalling etc.

• Educate and include your content providers in building a more accessible product. You will need their help for video & audio transcripts, content (alt text) descriptions, wording and overall communication inside your product.

A11y as a shared responsibility

As we mentioned, being A11y compliant should be a responsibility between the whole project team. But, this only works if the whole team is aligned on the A11y issue. There will be syncs and alignments required.

• Content providers, which are usually “the client”, need to be aware of their responsibilites: providing you with content descriptions and transcripts for any video/audio type of content.

• Copywriters, UX designers or any dedicated team member who is shaping the product’s communication must be aware of the Understandable principle and use wording and product’s communication in alignment with those guidelines.

• QA team needs to include A11y points when testing out the product implementation.

• Development team will be handling correct label ID implementation, correct order of elements, touch-target areas etc.

• Designers should be aware of all the A11y principles listed in this guide, but not all of them will be in their domain to address. Therefore, alignment with the rest of the project team will be required on certain parts.

• Project managers & product owners need to plan out A11y as a part of the acceptance criteria, and include A11y reviews as a part of the product’s timeline.

• Data analysts should provide the project team with information on how the app is being used.

• If A11y is included in the earliest stages of the product design and development it will not require any signifcant scheduling.

What after the review?

• Share your findings with the project team. (Use the checklist template).

• Let your product owner create an Accessbility epic and user stories, based on the provided documenation.

• Product owner should create separate user stories for design-related and development-related issues.

• After improvements are implemented, QA should test it out by following A11y accessbility criteria.

Conclusion

Website accessibility is more important than ever. In order to provide equal opportunities and experiences for people with disabilities, it is critical to make your website accessible for all. That way, your relationships with your consumers grow far beyond a computer screen.

Starting from Scratch