Writing semantic HTML makes all other accessible development techniques much easier. It is the foundation of your ability to write code which can be translated and transformed by the user and their chosen software into a format which works for their needs.

• Accessible HTML at Mozilla Developer Network (MDN)
• Semantics built-in at Google's Web Fundamentals
• Why semantic HTML is important, as told by TypeScript or Building websites for Safari Reader Mode and other reading apps by Mandy Michael.
• Web Accessibility Initiative (WAI) tutorial on Page Structure

Activity: recreate a content-heavy page (try a page from Wikipedia or documentation of a framework you use) using semantic HTML. Use the MDN HTML element reference rather than the articles above if you need to find out what element to use.

Accessible designs are out of scope for this learning plan. But we need to know how to implement them using the right techniques.

• We can't rely on colour by James Edwards for SitePoint
• Focusing on focus styles at CSS Tricks
• Accessible styles at Google's Web Fundamentals
• In theory, most front-end web developers know how to make responsive designs already. But if you need a refresher or weren't taught it well, Brad Frost's Responsive Resources has everything you need.

Activity: make sure your content page is repsonsive and add focus styles to any links or buttons. Use a contrast ratio tool to check the page and make fixes if needed. Add body {filter : grayscale(100%);} to the CSS to check if you have relied on colour alone for any visual indicators, and fix any problems.

Images often have some of the most useful information on a page. It's important to make sure that information is conveyed to all users, not just those with good vision.

• WAI has an excellent tutorial about all aspects of image accessibility.
• More detail on the accessibility of SVGs and icon fonts at 24 Accessibility

Activity: find a website with a lot of images in content, like for an art gallery or a band website. Write out the alt text you'd use for each one, and why. Repeat for a web app which uses lots of icons on it's controls, like email or video services.

Dynamic sites and common widgets let users show and hide chunks of content. The method you choose for hiding makes a big difference to how accessible your site is to keyboard and screen reader users.

• How to hide content at The A11y Project

Activity: Make a page with chunks of content, some with links or buttons in them. Experiment with HTML and CSS methods of hiding content. Compare the results in the browser, in dev tools, with a keyboard and with a screen reader.

Site navigation brings together accessibility requirements, so it makes a good practice feature.

• Read the WAI Menus tutorial

Activity: create a flyout or dropdown menu. When you are done, compare it to the examples given by The A11y Project or Heydon Pickering's Inclusive Components. How would you make yours responsive?

There's more to accessible forms than choosing semantic elements. We now have to use the right attributes, and consider how screen reader software behaves differently inside form elements.

• Sensible form design at A List Apart
• Autocomplete attributes for frequently-typed information are now an essential part of most forms.
• Inclusive considerations when styling form controls by Scott O'Hara for 24 Ways

Activity: Follow pages 1 to 4 of the WAI forms tutorial to make a short form using a variety of input types and groups. Make sure they are all labelled correctly, and provide information about required fields and instructions. (Error messaging is the next lesson!)

Giving your users accessible error messages has a number of potential pitfalls to avoid. We want to make it as easy as possible for everyone to recover from any mistakes and finish their task.

• Accessible hints and error messages by Russ Weakley
• How to report errors in forms: 10 design guidelines at Nielsen Norman Group
• Don't rely on browser-default error messages by me for Intopia

Activity: Use pages 4 and 5 of the WAI forms tutorial to add validation and error messages to your form from last week. Test it with a screen reader, in high contrast, and on a small screen.

Quick testing is useful to confirm that the information you want to convey to all users is actually available to all users. It cannot replace a full audit by an accessibility specialist, or usability testing by people with disabilities. But you can check that your work is of good-enough quality to hand over for a proper quality assurance process.

• Quick tests from The A11y Project
• Check that all information is present in the accessibility tree using either Firefox's Accessibility Inspector or Chrome's Accessibility pane in dev tools
• Lea Verou's Contrast Ratio tool or The Paciello Group's Colour Contrast Analyser can be used to check the colours of your site. Don't forget content which is hidden on page load!
• The A11y Project also has very basic instructions for using assistive technology (at the moment, free screen readers).

Activity: perform these tests on the pages you've made during this learning plan. Use the resources linked in this plan (or Stack Overflow) to find solutions to any problems you come across.