How to comply with the accessibility regulations

This list has information for all content creators. This is what we need to do to comply with The Public Sector Bodies (Websites and Mobile Applications) Accessibility Regulations 2018, which is based on the Web Content Accessibility Guidelines (WCAG) 2.1.

There are guidelines for images, video, text, headlines and forms. Plus some additional notes that will be particularly relevant to web developers.

Your web page must have a title that describes its topic or purpose. Headings and labels must also describe a topic or purpose.
All non-text content has a text alternative that serves an equivalent purpose. For instance, all images must have "alt tags". This is a description of the image. If you are adding a number of similar images to a page, it is best practice to use a different description for each image.
Organise your page using headings (h1, h2 etc). And make sure they are properly nested in order (eg h1 followed by h2, h2 followed by h2 or h3, h3 followed by h3 or h4, etc).
The purpose of each link on the page can be determined from the link text alone. Do not use simply 'Click here' or 'Read more'.
Use easy-read alternatives to technically advanced text. Ideally text should be written to be easily readable by all levels of ability (this is Level AAA but we try to keep to this).
Do not rely solely on shape, size, visual location, orientation or sound for understanding or navigation. Eg avoid content such as "click on the triangular button on the right when the music starts".
Provide submit buttons to initiate change of context (eg go to another page, play video) and warn users in advance when opening a new window [opens in new window].
Avoid images of text as these cannot be read by screen readers (logos are OK - with appropriate alt tag).
Information conveyed by colour differences should also be explained in text. For instance, the following three points are highly technical and will need to be discussed with video/audio providers.
Provide a text transcript of video-only or audio-only content. For example, this would be a text transcript of audio-only content; and a text description or audio description of video-only content..
Provide captions for all prerecorded audio/video content. NOTE: captions include subtitles PLUS text to describe important sounds.
Provide a second audio track on all prerecorded video to provide audio description - or a second version of the video with audio description. [NB: for a talking head video with no change in background, a text transcript will suffice]
If an input error is detected automatically, the error is described to the user in text. If suggestions for correction are known, these suggestions are provided to the user (unless it would jeopardise the security or purpose of the content).
Labels or instructions are provided when content requires user input.
For legal commitments or transactions, at least one of these is true: submissions are reversable; entered data is checked for errors and the user is given the chance to correct them; a mechanism is available for reviewing, confirming and correcting information before finalising the submission.
Only play sound if it is activated by a user (unless there is a good reason otherwise). The guidelines state that, if any audio on a web page plays automatically for more than 3 seconds, either a mechanism is available to pause or stop the audio, or a mechanism is available to control audio volume independently from the overall system volume level.
Do not change context (eg go to another page, play video) unless this is activated by the user. Simply giving focus to a component should not change context (eg pop-up windows). We want our users’ journey through our website to be as predictable as possible.
Order content so it makes sense to users of assistive technologies. Focusable components must receive focus in an order that preserves meaning and operability.
The default human language of each Web page can be programmatically determined. If language changes within the text, mark it in the source code so it is recognised by screen readers. Eg if there is a paragraph in French, use code <P lang=”fr”>Il y a un paragraphe en francais.</P>
The minimum contrast ratio for text and images of text is 4.5:1 or, for large text, 3:1. Graphics and interface components and text over graphics also must have a 3:1 contrast ratio against adjacent colours.
Text can be resized up to 200% without loss of content or functionality.
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
Content can be presented without loss of information or functionality, and without requiring scrolling in two dimensions.
A user can change text spacing without loss of content or functionality: line height to at least 1.5 times the font size; spacing following paragraphs to at least 2 times font size; letter spacing (tracking) to at least 0.12 times the font size; word spacing to at least 0.16 times the font size.
Hidden content made visible by pointer hover or keyboard focus is: dismissible without moving hover or focus; hoverable (ie it doesn’t disappear when the pointer is moved over it); and remains visible until it is dismissed or is no longer valid.
All functionality is operable through a keyboard interface and there are no keyboard traps (where a keyboard-only user cannot move focus away form a component).
Single key shortcuts can be turned off or remapped.
A mechanism is available to bypass blocks of content that are repeated on multiple web pages (eg skip to main content button).
More than one way is available to locate a Web page within a set of Web pages except where the Web Page is the result of, or a step in, a process.
The keyboard focus indicator is visible.
Navigational mechanisms that are repeated on multiple Web pages within a set of Web pages occur in the same relative order each time.
Components that have the same functionality within a set of Web pages are identified consistently.
And there’s stuff about parsing (complete start and end tags in markup) and other such developer stuff.