The HTML Accessibility review on freeCodeCamp offered a valuable opportunity to revisit concepts from previous lessons and labs, including assistive technologies, auditing tools, and accessibility best practices.
Introduction to Accessibility
The Web Content Accessibility Guidelines (WCAG) are a set of standards designed to make web content more accessible to people with disabilities. They are built around four core principles, known by the acronym POUR: content must be Perceivable, Operable, Understandable, and Robust to ensure it can be accessed and used effectively by a wide range of users.
Assistive Technology for Accessibility
People with disabilities use a variety of tools to access the web. Screen readers and screen magnifiers assist those who are blind or have low vision by reading content aloud or enlarging it, while large text or braille keyboards provide alternative input methods for visually impaired users. Individuals with mobility impairments may use alternative pointing devices, such as joysticks, trackballs, or touchpads, and can also navigate the web using voice recognition software, which allows them to control a computer through spoken commands.
Accessibility Auditing Tools
Common accessibility tools used to audit websites include Google Lighthouse, WAVE, IBM Equal Accessibility Checker, and axe DevTools, all of which help identify and address accessibility issues to ensure a more inclusive web experience.
Accessibility Best Practices
Creating an accessible website involves several key practices. Proper heading levels help assistive technology users navigate content, while tables should use th for headers, td for data, and a caption to clarify purpose. Form inputs should have labels, images should include descriptive alt text, and links should use clear, meaningful text. Audio and video content should provide captions, transcripts, and audio descriptions. The tabindex attribute can control keyboard navigation but should only use 0 or -1, and the accesskey attribute defines keyboard shortcuts, aiding users with mobility impairments while avoiding conflicts with browser or assistive technology shortcuts.
WAI-ARIA, Roles, and Attributes
WAI-ARIA, or Web Accessibility Initiative - Accessible Rich Internet Applications, is a set of attributes that can be added to HTML elements to enhance accessibility by providing assistive technologies with additional information about content purpose and structure. ARIA roles, such as role="tab", role="menu", and role="alert", define the function of elements, helping users of assistive technologies better understand and navigate web content.
ARIA roles fall into six main categories. Document structure roles define a page's layout, helping assistive technologies navigate content. Widget roles specify interactive elements' functionality. Landmark roles label primary sections for quick navigation. Live region roles announce dynamically changing content. Window roles define sub-windows like dialogs, and abstract roles organize the document internally but aren't for developer use. Attributes like aria-label and aria-labelledby assign names, aria-describedby links elements to descriptive content, and aria-hidden hides purely decorative elements from assistive technologies.
When I first joined DEV, sharing my freeCodeCamp learning journey was a big motivator. However, continuing the Learning with freeCodeCamp series has become impractical. After completing the Accessibility review and quiz, only the main HTML quiz remains to finish the HTML section. The following Computer section only has 16 steps, but the final CSS section contains far too many to cover effectively in this series. For that reason, this will be the final post.
If you would like to follow my progress beyond this series, you can check out my freeCodeCamp profile: Richard Pascoe. There, you can track my continued progress, view my activity and see when I earn my Responsive Web Design certification - the first milestone in the Full Stack Developer Curriculum.
Thank you to everyone who has followed this series and for all the encouragement and support I’ve received along the way.
Top comments (7)
That's great Richard!!! Even though there's a lot remaining, always remember there's alot you've accomplished as well!
And as always can't wait to read through your growth ahead! Congratulations and all the best for the quiz!!
Cheers, Aryan! Indeed, got the Accessibility quiz under my belt this afternoon, going to finished the HTML section with the final quiz tomorrow.
As always, appreciate the support!
Great post Richard! I like how you broke down the specific HTML errors. It makes it much easier to understand what to avoid. I'm going to try to be 1% better at accessibility starting with my next commit!
Thanks, Maame. Glad that it resonated with it. And you know something, I'll take that 1% - I'm certainly going to try to be more mindful of accessibility moving forward!
Good overview of the POUR principles. One thing I wish more tutorials covered is how accessibility practices actually improve the developer experience too. Semantic HTML makes your components way easier to test and style, and proper ARIA labels make automated testing more reliable.
axe DevTools is great for catching the obvious stuff. For anything more nuanced I've found manually navigating with just a keyboard for 5 minutes reveals issues no automated tool catches.
Indeed, Ned. I've said elsewhere that the current version of the freeCodeCamp curriculum (Version 10) has made a number of improvements, with accessibility being one of them. I feel I have a far better understanding of the subject now.
Thanks for the axe DevTools feedback, I must try them myself - and soon!
freeCodeCamp v10 putting more emphasis on accessibility is a great sign. the more it's taught as a default skill rather than an afterthought, the better. axe DevTools is solid, the browser extension alone catches a surprising amount of issues without any setup.