Accessibility is easiest to learn component by component, because the same six or seven components carry most of the failures on most sites. This page is those components with a good and a bad version of each, so a developer or designer can compare against what is in their own library. On the worked example the nine templates hold 126 of the 401 issues, and almost all of them are one of the components below repeated across pages.
Navigation, menus and the skip link
Good: a nav landmark, a real list of real links, a dropdown that opens on click and is fully operable by keyboard, and a skip link that is the first focusable thing on the page. Bad: a div soup menu that opens on hover only, and no way past forty links to the content, which is what a keyboard user meets on every single page.
Forms, errors and required fields
Good: a visible label associated with every control, errors in text next to the field and summarised at the top, required marked in the markup rather than only with a red asterisk. Bad: placeholder-as-label, errors shown only in red, and a submit that scrolls somewhere without moving focus. Six forms at two issues each is small in count and is what customers actually complain about.
Images, video and data tables
Good: alt text that says what the image contributes, empty alt on decoration, captions on video, tables with header cells and a caption. Bad: alt text that repeats the file name, a video with automatic captions nobody has corrected, and a layout table with merged cells that reads as noise.
Questions people ask about web accessibility examples
Where do we start with a component library?
With the navigation and the form controls: they appear on every page and carry the most weight.
Are there ready-made accessible components?
Yes, and the ARIA Authoring Practices Guide's patterns are the reference implementations most libraries follow.
How do we stop regressions?
Test the components rather than the pages, in CI. A component fixed once stays fixed everywhere it is used.