Meaningful Markup

Use meaningful HTML markup to indicate structure and relationships

Meaningful (semantic) HTML markup uses elements that describe the structure and purpose of content, not just how it looks. This helps everyone understand and navigate a page more easily, and it is essential for people who use screen readers and other assistive technologies.

Under the CSU Accessible Technology Initiative (ATI) and the ADA Title II web and mobile accessibility rule, 缅北禁地 web content must conform to WCAG 2.1 Level AA, which includes requirements for conveying information and relationships in markup.

Quick checklist

  • Use HTML elements that reflect the purpose of the content (for example, headings, lists, tables, links, buttons, forms).
  • Do not rely on visual formatting alone (such as bold, font size, or indentation) to convey structure.
  • Use tables only for data, not for page layout.
  • Ensure forms have properly associated labels, groups, and error messages.
  • Use ARIA roles and attributes only when native HTML cannot provide the needed semantics.

Structure pages with semantic elements

Use semantic HTML elements to reflect the logical structure of the page:

  • Headings: Use <h1>–<h6> to identify sections and subsections (see the Headings page for details).
  • Sections and landmarks: Use elements such as <header>, <main>, <nav>, <section>, <article>, and <footer> where appropriate so assistive technologies can identify page regions.
  • Lists: Use <ul> for unordered lists, <ol> for ordered lists, and <li> for list items instead of using line breaks or symbols to fake lists.
  • Quotes: Use <blockquote> for quoted blocks of text and <q> for short inline quotations.

Use the right element for the job

Use elements that match the meaning of the content, not just the desired appearance.

  • Use <strong> or <em> to indicate importance or emphasis instead of relying on <b> or <i> solely for styling.
  • Use <a href="..."> for links that navigate to another page or location, with clear, descriptive link text (for example, “Web Accessibility overview” instead of “click here”).
  • Use <button> for actions that submit a form, open a dialog, or perform a command.
  • Avoid using generic containers such as <div> and <span> as interactive elements unless you add proper semantics and keyboard support.

Tables for data, not for layout

HTML tables are intended to present data with meaningful relationships between rows and columns. Using tables for layout makes it harder for screen reader users to understand the page.

  • Use tables only when you are displaying tabular data.
  • Include a <caption> that describes the purpose of the table.
  • Use <th> elements for header cells and scope="col" or scope="row" to indicate whether they label columns or rows.
  • For complex tables, use headers and id attributes to associate data cells with their headers.
  • Do not use tables to control layout or positioning on the page.

Forms, labels, and groups

Forms must use semantic markup so that users of assistive technology can understand each field and its purpose.

  • Use <label> elements associated with form controls using the for attribute (for example, <label for="email">Email address</label> and <input id="email">).
  • Group related form controls (for example, sets of radio buttons) using <fieldset> and <legend>.
  • Provide clear error messages and associate them with the relevant fields.
  • Use appropriate input types (for example, type="email", type="tel") to help with both accessibility and usability.

Language and text alternatives

Markup should also convey language and text alternatives clearly:

  • Set the primary document language in the HTML (lang attribute) so screen readers can use the correct pronunciation rules.
  • Use lang attributes on phrases or sections that are in a different language from the main page.
  • Provide text alternatives for non-text content (images, icons, media) as described on the Alternate Text and Captions and Transcripts pages.

Using ARIA appropriately

Accessible Rich Internet Applications (ARIA) roles and attributes can enhance semantics, but they should be used carefully.

  • Prefer native HTML elements and semantics whenever possible; they are more reliable and require less customization.
  • Use ARIA roles (such as role="dialog" or role="alert") only when necessary to describe custom widgets or behaviors.
  • Avoid using ARIA to override native semantics (for example, adding roles that conflict with existing element roles).
  • Remember: “No ARIA is better than bad ARIA.”

Related WCAG 2.1 criteria

  • 1.3.1 Info and Relationships (Level A): Information, structure, and relationships conveyed through presentation can be programmatically determined or are available in text.
  • 1.3.2 Meaningful Sequence (Level A): When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined.
  • 4.1.1 Parsing (Level A): Content is implemented in a way that user agents can parse and interpret.
  • 4.1.2 Name, Role, Value (Level A): User interface components have appropriate names, roles, states, and values exposed to assistive technologies.

Before you publish

  • Review the page outline (headings and landmarks) to ensure it reflects the logical structure of the content.
  • Check that lists, tables, and forms use the correct HTML elements and are not simulated with visual formatting alone.
  • Verify that interactive elements (links, buttons, form controls) use appropriate HTML and are not generic <div> or <span> elements.
  • Test with a screen reader or accessibility checker to confirm that structure and relationships are announced correctly.

Last updated: December 2025