If HTML provides the semantic content of a site, CSS works to provide emphasis on visual
hierarchy and aesthetic elements. While not necessarily informational content, using CSS well
should enhance your ability to make a visual argument in the form of a web site. In addition,
CSS can make or break the accessibility of a site.
The Web is fundamentally designed to work for all people, whatever their hardware, software, language, location,
or ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement,
sight, and cognitive ability.
These guidelines are developed, maintained, and advocated by the WAI (Web Accessibility Initative), a part of
the W3C (World Wide Web Consortium). While they’re not strictly a law, there can be legal reprecussions.
In addition, search engines, agentic frameworks, and other technologies can (and do!) de-privilege sites that
don’t follow the guidelines (to a certain extent).
The guidelines are referred to as the WCAG standard, currently on version 2.2.
In practice, that means somethink like the acronym POUR:
That is, the web should be:
Perceivable
Content is accessible via multiple senses (alt tags, transcripts)
Operable
Content can be used from a variety of devices: not just a mouse.
Understandable
Navigation paths (both menus and URLs) are consistent and well-labled; help messages are well-written and precise.
Robust
The site doesn’t break when used with alternative technologies or in alternative viewports.
Any content structure—or visual relationship made between content—can also be determined programmatically, or be
inferred from text description.
A sensible, logical reading order should be easy to determine for any content, even if it is visually presented in an unusual way.
The order should be made obvious by use of correct semantic elements (e.g., headings, paragraphs), with CSS being used
to create any unusual layout styles, irrespective of the markup.
Instructions for operating controls or understanding content do not rely on a single sense.
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape.
All functionality should be accessible using keyboard controls, unless it cannot be done using the keyboard
However, the spec. insinuates that all functionality should be accessible using keyboard controls — with no exceptions.
If a single character key shortcut exists, then at least one of the following is true: single character key shortcuts can be turned off, remapped or are only active when the relevant user interface component is in focus.
Seizures and Physical Reactions: Do not design content in a way that is known to cause seizures or physical reactions
A mechanism should be provided that allows the user to skip straight to the main content or functionality available on the page, past the repeated features (such as the company logo or navigation).
Each web page should include an informative <title>
The purpose/destination of a link can be determined from the link text, or from its surroundings (e.g. surrounding text)
Heading (e.g., <h2>) and <label> elements clearly describe the purpose of the content and form elements they are supposed to be describing.
The default human language of each web page should be detectable via code (e.g., <html lang = "en">)
Where technical terms, jargon, or idioms/slang are used, definitions should be provided for such phrases/words.
If text is provided that requires a higher reading level that lower secondary education level (typically children around 11-14 years old), provide supplementary explainer material to help people who can’t read it
Make Web pages appear and operate in predictable ways
When a control or other page feature receives focus, it should not change the context in a way that may confuse or disorientate the user
When data is inputted into a control, or a setting is changed, context should not be changed unexpectedly
Navigation menu/control style and positioning should be consistent between different pages or views of a web page
Controls or components that have the same functionality should be identified in the same way across different pages or views
When a user is filling out a form or choosing between options, any error that is detected should be clearly reported to the user, along with the form control that the error relates to.
When a user is filling out a form or choosing between options, any error that is detected should be clearly reported to the user, along with the form control that the error relates to
Clear instructions should be provided when data input is required
When an error is detected and suggestions for correction are known, provide these to the user (e.g., suggesting alternatives when the user is choosing a user name and has selected one that is already taken)
Provide instructions and other appropriate cues in context to aid form completion and submission
Content should be well-formed so it can be parsed successfully by browsers and other user agents such as screen readers.
(i.e., use latest HTML standards, such as semantic tags!)
The name and role of user interface components (e.g., form inputs, buttons, links, etc.) should be programmatically determinable
When scripting custom components, you will need to use ARIA roles and other features to make sure your controls will be interpreted and are able to be used as intended
