Gain insights into web accessibility fundamentals, terminology, and best practices. Learn about WCAG, identify and fix accessibility issues, and create inclusive websites for all users.

Introduction to Accessibility for the Web.png

Accessibility means everyone should have equal access to the internet regardless of physical or mental disabilities or differences. As developers, you must create websites that are easily understood and navigated by everyone. While the concept of accessibility might initially feel intimidating, developers of all experience levels can create accessible products. Users are at the heart of everything developers build—and all users should have equal access to what you create as a developer.

In this course, you’ll learn the basic terminology, high-level concepts, and standard practices you need to start creating accessible websites and applications. You’ll look at the Web Content Accessibility Guidelines, learn how to catch (and correct) common accessibility mistakes, and become a more considerate and empathetic developer.

By the end of this course, you’ll have the knowledge you need to create accessible UIs, write accessible code, and adapt inaccessible web experiences into accessible ones.

A Beginner’s Guide to Web Accessibility

Semantic elements have embedded information about the name, description, role, state, and interaction options for content.

Semantic HTML is easy for other developers to skim through and understand. 

Semantic HTML elements have been specifically designed to work well with keyboard navigation. 

Using the correct semantic elements can boost the SEO of our website.

**(Select all that apply.)** What are the benefits of using semantic HTML?

(Select all that apply.) What are the benefits of using semantic HTML?

From the visible text, such as the content in a `<button>` tag

From the associated `aria-labelledby` attribute

**(Select all that apply.)** Where does the accessibility tree source the name of an element from?

(Select all that apply.) Where does the accessibility tree source the name of an element from?

**(True or False)** Buttons and links are basically the same and can be used interchangeably in our code. 

(True or False) Buttons and links are basically the same and can be used interchangeably in our code.

**(True or False)** Buttons are best used for navigation, both internal and external to the website or application.

(True or False) Buttons are best used for navigation, both internal and external to the website or application.

Which aspect of the POUR accessibility approach does building predictable and intuitive user interfaces fall under? 

Which aspect of the POUR accessibility approach does building predictable and intuitive user interfaces fall under?

In the bookmarks interface of the browser, when they bookmark a page 

In the menu options, when they right-click on the web page. 

**(Select all that apply.)** Where do users see the page title?

(Select all that apply.) Where do users see the page title?

Remove any questions that aren’t absolutely necessary

Add a timer to encourage users to complete the form quickly 

Put related questions into groups to help break the content into more digestible chunks

**(Select all that apply.)** How can you make a long form more accessible?  

(Select all that apply.) How can you make a long form more accessible?

Hover-triggered content is inaccessible by default.

Hover-triggered content is accessible by default.

The accessibility of hover-triggered content depends on the web browser.

Hover-triggered content is always partially accessible.

How accessible is hover-triggered content?

How accessible is hover-triggered content?

Hover or focus-triggered content must be permanently visible.

Hover or focus-triggered content must be dismissible without moving the mouse or changing the keyboard focus.

Hover or focus-triggered content is allowed to cover the entire screen.

WCAG criteria recommends increasing the complexity of hover or focus-triggered content.

What does WCAG criteria require regarding hover or focus-triggered content?

What does WCAG criteria require regarding hover or focus-triggered content?

Yes, it’s a recommended practice to add WAI-ARIA attributes to every element.

No, WAI-ARIA attributes should only be added to specific elements where needed for accessibility.

Only add WAI-ARIA attributes to images on the page.

Add WAI-ARIA attributes to all text elements but not to other types of elements.

Should you add WAI-ARIA attributes to every element on the page?

Should you add WAI-ARIA attributes to every element on the page?

Test your knowledge of accessible HTML practices. 

Before We Begin

Getting Started

Accessible User Interfaces

Accessible HTML

Navigation without a Mouse

Alternate Presentations of Information

Challenge: Find and Solve Common Accessibility Mistakes

Wrap Up

Quiz: Accessible HTML