Build Accessibly with Progressive Enhancement: HTML (Video)

Progressive enhancement is the method of developing websites and components in a way that users can view content in every context, whether that’s in an old browser, with a screen reader, or just when they have a slow internet connection. From the perspective of progressive enhancement, content is the most important part of the web; it’s why we build websites to begin with. You can progressively enhance a component by starting with content, then adding HTML, CSS, and JavaScript. In this series of articles, each accompanied by a video, you’ll learn how to build accessible components through this method of development.

Where does Accessibility Fit into Progressive Enhancement?

Accessibility can be implemented at every step of the progressive enhancement process:

HTML (Below)

• Use semantic tags

• Write descriptive links

• Add your ARIA attributes (only when necessary)

CSS

• Use colors that pass the contrast ratio

• Make sure those colors are not the only indication of information

• Add a custom focus style

• Add hover styles

• Add styles to show and hide content (if needed)

JavaScript

• Set up your widget to work without JavaScript

• Use JavaScript to toggle ARIA attribute values

Testing

• Keyboard

• Page zoom

• Screen reader

Accessibility and Project Scope

Making a custom JavaScript widget accessible doesn’t have to take a ton of time and can be done by anyone with the right tools: semantic HTML, accessible design, ARIA Attributes, and responsible naming. That may seem like a lot, but I will show you how to build an accessible multi-select accordion using the accessible, progressive enhancement principles I stated above. By integrating accessibility into every step of the progressive enhancement process, we will be able to make the component’s functionality directly dependent on being accessible. I used CodePen to build out this accordion component and have three CodePens available, each featuring the accordion as it gets enhanced with HTML, CSS, and JavaScript.

Step 1: HTML

When developing the HTML of your component, first make sure to use real content that will be on your site; try not to use fake content like “lorem ipsum.” Once you have your content written out, then you can start writing code!

View the HTML CodePen

Use Semantic Tags

• Use a <section> instead of a <div> to wrap the component or <p> instead of <span> to wrap around text.

• Add definition list tags such as <dl>, definition list, <dt>, definition term, and <dd>, definition details, to the accordion heading and sections. Definition lists provide even more semantic meaning than a regular unordered list because the definition term is always associated with the corresponding details. So then we already have some of that explicit association we are trying to achieve for an accordion without adding styles or JavaScript.

• Use a <button> within each definition term because it will trigger the opening and closing of the content. I’m using a button instead of adding an event listener to a header or a <div> because buttons indicate that something is going to change on the page.

Write Descriptive Links

• Avoid non-descriptive link text such as ‘Learn More’ or ‘Click Here.’ Instead, make sure link and button text describes the actual link. For example, the content I added to my CodePen accordion relates to how I researched and built the component. The first accordion heading is “What resources did you use to build this?” And, the content inside of that accordion section includes links to different articles and the W3C’s ARIA-WAI documentation. All of the buttons and links have descriptive text.

Add ARIA Attributes

• Only add the minimum amount of ARIA attributes needed to make your component or website accessible because no ARIA is better than bad ARIA.

• Add static ARIA attributes such as aria-label, aria-labelledby, and aria-controls if needed, keeping the previous point in mind. Static ARIA attributes don’t change, and they are usually a way to describe an element or content.

• Add dynamic ARIA attributes that will involve JavaScript and indicate the state of the element or content. I add these kind of attributes at this point because the WAI-ARIA documentation lists aria-expanded, an ARIA state, as a required attribute for this type of component. When developing components, it is key to read the documentation and standards on how that component is expected to operate and the aria-attributes it requires.

  • Add aria-expanded to your component because assistive technology needs to know about the state change. Also, make sure to set the default of the ARIA attribute to work without JavaScript. For example, in the accordion CodePen, I set the aria-expanded value as true because we want to be able to see all of the content even when there is no JavaScript.

Now we have the HTML of our component completed! If you were following along with the video and want to look at the code I wrote, you can view the HTML CodePen. Remember, this series will feature four videos paired with articles, one for each section of the progressive enhancement process, HTML, CSS, JavaScript, and Testing. To learn how accessibility fits into adding styles to our component, check The Foundry again soon for the next article and video! And sign up for Sparkbox Newsletters to be sure you don’t miss a thing.