Solid Structure: Built to Standards

HTML, CSS, and JavaScript together provide a stable platform for accessible web content and application development, when these technologies are used following standards. Following standards ensures that assistive technologies and browsers together have the best chance of rendering content in an accessible and meaningful way.

• Use HTML, CSS, and JavaScript according to specifications. Use HTML’s native markup to identify structure and meaning for content. Use CSS for controlling visual display, including at different screen resolutions and on different environments, such as when the page is printed. Use JavaScript to control interactivity when HTML cannot do this on its own. Valid markup doesn't on its own ensure accessibility, but it's important to minimize validation issues by checking code using a validation tool.
• Use other web technologies with care, and when appropriate. Other web technologies and document formats, such as Flash and PDF, have varying degrees of support for accessibility, and varying levels of difficulty in providing accessible documents. If you must use an alternative format, ensure you provide all available accessibility features.
• Test code on a range of assistive technology and browser combinations. As browsers have slight differences in the way they support HTML and CSS features, so do assistive technologies, especially screen readers. As a result, the user experience may vary slightly depending on the interactivity provided and how it was created. As a baseline, test content and functionality using commonly used platforms, for example:
  • On Windows, JAWS with Edge or with Firefox, and NVDA with Firefox
  • On macOS, VoiceOver with Safari

Testing

Check the HTML with a validation tool.

• Are all elements tagged and nested properly?
• Are required attributes provided for an element when used?
• Are id attributes given unique values?

Screen readers read page content in a linear order, which is defined by the order that content appears in the source code (the Document Object Model) at a given time. Sometimes, when visual positioning is used to change the linear order for display purposes, the logical order is lost when read by a screen reader. This can affect both blind screen-reader users and sighted people with reading difficulties who are listening to content being read.

Make sure that content is announced in a logical order. Use CSS to position content, rather than layout tables. Be aware of the potential effects on reading flow when using CSS to position content in a location that’s significantly different from where it appears in the content order. Use a DOM inspection tool to check the rendered code order, especially when the content is dynamically updated (see Tools).

Testing

Visually examine the content order of the page, then listen to the page as it’s read by a screen reader. Does the page’s content order make sense when read aloud?

Semantic markup for page content provides structure when pages are accessed using assistive technologies or when the pages’ styling is changed for readability purposes. Screen readers can also use structural markup as navigation features, such as by allowing for heading-based, list or table navigation or by allowing users to navigate between content areas such as main page content, navigation menus, or page footer.

When semantic markup is not used and the page’s semantic structure is implied only visually, such as by making text larger and bolder to look like a heading, the page’s semantic meaning is lost.

• Identify section headings and heading hierarchy using markup. Use HTML heading elements (h1 through to h6) to identify headings. Make sure that the heading hierarchy is logical. Section headings should succinctly describe the content that follows them, and heading elements should never be empty.
• Identify page sections and landmarks. Use semantic HTML5 elements to identify the start of page content areas such as the top header area, main content, navigation bars, footer, and search areas.
• Identify lists using markup. Use unordered list markup (ul) for lists where there is no logical order implied, including navigation lists and menus. Use CSS to customize or suppress bullet points. Use ordered lists (ol) for numbered lists. Use description lists (dl) for lists that are key/value pairs.
• Mark up data tables using table markup. Use the th element to identify column and/or row headers. Avoid making complex tables, with cells spanning rows or columns. Do not nest tables inside other tables.

Testing

• For each visual heading, is the heading identified in markup? If so, is the heading given a suitable heading level?
• For all contents of a page, is the content within an appropriate landmark element (header, nav, main, etc.)?
• For each data table on a page, are the rows and columns contained in table markup? Are row and column headers identified using th elements? If a caption is provided, is it within the table using a caption element?
• For each list of items on a page, including any navigation lists, is the list coded using HTML list elements? Are the list’s bullet points styled using CSS rather than images of bullets in markup?

Forms allow users to enter data by typing or selecting from a set of options. When forms are not designed with accessibility in mind, people with disabilities are likely to have difficulty or even find it impossible to enter data without errors. Forms need to be designed so that the purpose of each control is clear.

• Provide an accessible label for every control. Preferably, give each control a visible text label that explains its purpose. This is best done with an HTML label element that’s programmatically associated with the control using for and id attributes, respectively.
  • For a text input field, its accessible label is a short description of the data the field collects.
  • For a control that is a group of options, such as a drop-down menu (select element) or list of radio buttons or checkboxes, the group should have a label that describes the relationship of the options. Each label should have a short description that indicates the value associated with each option.
• Make sure the label remains visible when the control has focus. Wherever possible, avoid relying on placeholder text to label an input field. There are several usability issues relating to placeholder text because it disappears when the user starts to type into the field. It's much better to have an external label that remains visible at all times. If space is limited, such as when designing responsively for small screens, media queries can change how label text is displayed.
• Provide additional input instructions when they are needed. Some controls may collect data that has constraints (such as upper or lower limits) or restricted formats. Preferably, use controls that only allow selections within those constraints. If this is not possible, provide additional text that describes the constraints in plain language.
• Provide additional information (autocomplete attribute) to help people better understand and recognize the intention of input forms. People who have difficulty completing forms requesting personal data -- for example, those with cognitive or mobility impairments -- will benefit, because it will save time and eliminate typing or spelling errors. Most browsers today recognize well-labeled input fields corresponding to name and address. If the user allows the browser to autofill and store personal information in the settings, the browser will suggest values to complete the fields. This makes entering data faster and more accurate by eliminating typing errors.

Testing

For each form control:

• If the control is a text input field, is there a visible text label that describes what should be entered into the field?
• If the control is a group of selectable options, such as a dropdown menu or list of radio buttons or checkboxes, are both of these true?
  • There is a visible, meaningful label describing the collection of options.
  • Each option has a visible, meaningful label that conveys the value of the options.
• If there is no visible label for a control, are both of these true?
  • There are sufficient visual clues to explain the function of the control.
  • There is label text that is programmatically associated with the control, and the label is read aloud by a screen reader when it encounters the control.
• If users need additional information to interact with the control, is that information provided accessibly?
• Has the autocomplete attribute been used to identify inputs for commonly requested personal information, to assist users in understanding and recognizing them?