Now that you know how to create the structure of a site, we will focus on interactions. We touched on this in the previous part of the course when looking at the navigation menu.
In this part, we will focus on:
Forms (as well as their validation)
Modal dialogs
Carousels
CSS techniques
Tools dedicated to accessibility
You will be able to use your new knowledge of ARIA to make accessible interactions. Let’s get started!
Discover the Importance of Feedback for Accessibility
Create Accessible Interactions
As you may have seen in the course Make Your Web Content Accessible, there are many types of interactions. For example:
Navigation menus that open and close.
Modal dialogs that open when a button is clicked.
Error indicators that appear when a form is filled out incorrectly.
In the above cases, you need to consider the different audiences that will need to use your website. For example, you will have to:
Include visual feedback (i.e., when a form field is in focus).
Manage ARIA attributes to provide additional information about elements.
Identify roles using ARIA attributes.
Support different modes of interactions for controls (using both the keyboard and mouse).
Of course, part of the work will be done by the designer and the project manager. That said, it will be up to you, as the developer, to translate their expectations into code. 😉
Handle Complexity Through Collaboration
To manage this complexity, you will need to collaborate with:
Your designer, since they will provide you with the wireframes and mockups.
Your project manager, since they will be able to think about the implementation of an accessibility plan.
When creating mockups and wireframes, designers will often annotate the visual design to provide more information about the intended behavior. It isn’t specific to accessibility, but in recent years has become more common for this purpose.
Accessibility annotation allows you to describe the expected states and tags/attributes for each element of your site: the buttons, forms, images, etc.
Below are the ARIA attributes linked to each interaction (don’t worry, you already know some of them 😉 ) before tackling the techniques you will need to use.
Inform the User About Interactions Using ARIA
In Part 1, you saw that you could use ARIA attributes to describe the function of elements. These attributes can also describe the state of elements.
In the chapter "Help Users Navigate on Your Site," we looked at a dropdown menu. ARIA attributes defined the navigation region’s role, the presence of pop-up content, and whether the element was open or closed.
In the following chapters, you’ll see how you can use ARIA for other types of interactions as well.
The Technologies You Will Need
As you may already know, HTML is not a programming language but a “structuring” language. When you want to open a modal dialog or dropdown menu, you’ll need to use JavaScript.
Similarly, although HTML can validate natively when you create a form, you’ll validate using programming languages: JavaScript and a backend language, such as PHP.
Programming languages allow you to modify HTML attributes and tags. When the state of elements on your site changes, you can convey this information to the HTML side. It will allow assistive technology users to understand interactions as they happen.
Let’s Recap!
HTML is there to structure your pages. However, it won’t allow you to implement interactions.
HTML and ARIA indicate the state of interactions to assistive technology users. For example, if a dropdown menu or modal dialog appears on the screen.
Try to think of your interactions as far upstream as possible. First, it’s the designer’s work (who creates the mockups) and then the project manager (who translates it into a feature).
In this chapter, we reviewed how to manage interactions on your site. Next, let’s look at specific examples as you learn about forms and accessibility.