Use elements the way people expect them to work, don't use common elements in a different way than they are usually used. Components that have the same functionality within a set of pages should be identified consistently. Note: Consistent does not always mean identical.
Though criterion 4.1.1 is now deprecated, all functional IDs must be unique. But if you get a notice or error about a non-functional duplicate ID, you can pretty much ignore that.
The reading order should reflect the order in the code. You can check this, for example, by removing CSS styling and reviewing that the order of the content makes sense. Also, if a Web page can be navigated sequentially and the navigation sequences affect meaning or operation, focusable components receive focus in an order that preserves meaning and operability.
Remove the ability to focus on elements that are not presently meant to be discoverable. This includes things like inactive drop-down menus, off-screen navigations, and modals.
Images must always have an alt attribute. It shouldn't be a required attribute in your CMS because decorative images should have empty alt attributes. An empty/null alt attribute is not the same thing as a missing alt attribute!
Write semantic HTML. Pay attention to tags, make sure you use the correct tags and that you use them properly. Don't forget to check your website with a validator.
Remember that <div> and <span> have no meaning. You can use them for layout purposes if needed, don't use semantic elements incorrectly to theme your web page.
We've probably all seen use cases where an element looks like a button but is a link. This is very common with CTA (Call to action) buttons/links. But remember that the elements are not the same.
A link (<a>) takes the user somewhere, usually to another page. A button (<button>) does things on the page.
And why should you care? The elements can be activated differently on a keyboard. A link is activated with the enter key. A button can be activated with the enter key or the spacebar. Have you checked what happens when you press the spacebar while you focus on a link?
Menus that open with hover are often problematic for people with reduced dexterity. If your hand tremors while you try to open a small hover menu, you might even find that impossible. If you use menus that open on hover, it is recommended to, for example, add the submenu on the parent menu item's page so that people can access the submenu outside of the main menu.
Also for keyboard users, the menu should not automatically open when focused. This is currently ignored by quite a lot of the navigation libraries, so if you plan on using one, remember to check the library's keyboard functionality.
If you create menus that open with a click instead of a hover, the keyboard problem is pretty much automatically fixed. This kind of menu might also be more usable for people with reduced dexterity because the opened menu items won't disappear if your mouse moves away from the items.
I've also seen an interesting implementation of a combined hover-and-click menu. The menu opens on hover but doesn't go away if you hover outside the opened menu element. And you can open the menu element with your keyboard because there is an arrow button next to the parent menu items. But the menu doesn't automatically open on focus. This functionality is on a Finnish accessibility info site called Saavutettavuusvaatimukset (translates to accessibility requirements).
When implementing dialog boxes and similar elements, think about people who use screen magnification, a keyboard, or other assistive technologies. If the content box appears out of sight for a user, the user will most likely not be able to access the content. Keyboard users need to be able to get to the elements.
When a dialog is open, the focus should only move inside the dialog. And after a user closes the dialog, the focus should be returned to the element in which it was when the dialog was opened.
I've yet to test any dialog plugins but I've tried to research them a bit. There are a lot of dialog plugins available, one of which is a11y-dialog. Then there is also Modaal, which claims to be level AA. But I did read in the plugin's issue list that it might not meet all the requirements. Make sure to test the plugin you choose or the code you write properly! There are often WCAG violations in dialogs.
The HTML element <dialog> is not yet widely supported, the element is supposed to be able to handle the user's focus. I hope this is true, then we wouldn't need any libraries or extra features for dialogs.
Remember that if you have an iframe as the first or the last element in a dialog, the focus won't work properly since the iframe captures the focus.
As you might know, we tend to use these pseudo-elements often. Sometimes we add content that is intended for visual media, like custom bullet icons, arrows, or triangles. But what you may not know, screen readers actually read the content that is added to them. There are differences between browsers and screen readers on this functionality, for example, Chrome and Firefox read added characters very differently.
What you can do to prevent your screen reader users from getting confused or annoyed by unnecessary clutter is to add an alternative text for the property. This has been added to the level 3 specification. If you add an empty alternative text, the screen readers will ignore the element. I created a quick demo for this, so check out the pseudo-element demo page with a screen reader.
.item::before { content: "\25BA" / ""; }
The property should be able to be used also for adding an actual alternative text for such content, but I haven't yet seen this supported. But at least for ignoring the content property with a screen reader, it seems to be quite reliable. Safari seems to be the only browser not yet supporting this fully. Make sure you test Safari extra carefully if you use this feature.