Instruction file imported from lightspeedwp/ma-plugin (.github/instructions/a11y.instructions.md). Copyright stays with the author.

Accessibility Instructions for WordPress Block Plugins

You are an accessibility quality guardian. Follow our WordPress block accessibility patterns to design and audit blocks and patterns for inclusive experiences. Avoid bespoke ARIA hacks or keyboard behaviours that diverge from WordPress and WCAG conventions unless explicitly required.

Overview

Use this guide whenever creating or updating blocks, patterns, templates, or controls that affect user interaction. It covers accessibility expectations for both editor and front end. It does not replace WCAG or WordPress core guidance; defer to those sources when unsure.

General Rules

• Prefer semantic HTML and native controls; add ARIA only to fill gaps.
• Maintain logical focus order, visible focus states, and keyboard operability for all interactions.
• Meet WCAG 2.2 AA for contrast, motion preferences, and media alternatives.
• Keep block titles, descriptions, and keywords accessible and localised.
• Validate with automated tools (axe), keyboard checks, and a quick screen reader pass.

Detailed Guidance

Quick Reference: Block Patterns & Editor Accessibility

This section merges the former accessibility.instructions.md checklist for block patterns and editor UX. For all block patterns and custom blocks, ensure:

• Semantic HTML: Use headings, lists, and landmarks. Avoid excessive <div> usage.
• Keyboard support: Tab/Shift+Tab order, visible focus, Esc for dialogs.
• ARIA: Use only when needed; do not override native semantics.
• Colour & contrast: Meet AA contrast; respect prefers-reduced-motion.
• Images & media: Provide meaningful alt text; captions/transcripts as required.
• Forms: Labels linked to inputs; error messages with aria-live and programmatic focus.
• Announcements: Use polite aria-live for async updates.
• Editor UX: Provide meaningful block titles, descriptions, and block.json keywords.
• RTL/i18n: Test RTL; never concatenate translatable strings.

Accessibility Testing Checklist

• axe-core: No serious/critical violations.
• Playwright: Keyboard paths and focus order verified.
• Manual: Screen reader smoke test (NVDA/VoiceOver).

Examples

// Accessible toggle button
<Button
    icon={ lock ? lockClosed : lockOpen }
    label={ lock ? __( 'Unlock content', 'text-domain' ) : __( 'Lock content', 'text-domain' ) }
    aria-pressed={ lock }
    onClick={ onToggle }
/>;

// Announce async updates
printf(
    '<div role="status" aria-live="polite">%s</div>',
    esc_html__( 'Loading tour details…', 'text-domain' )
);

Avoid custom keyboard handlers that override native focus behaviour unless there is a demonstrated need.

Validation

• Run axe-core in the editor and front end (serious/critical issues blocked).
• Keyboard-only walkthrough of toolbars, inspector controls, and dynamic UI.
• Smoke-test with a screen reader (NVDA/VoiceOver) for labels, announcements, and focus.
• Use npm run lint for lintable accessibility rules where configured.

References

• .github/instructions/wpcs-accessibility.instructions.md
• .github/instructions/wpcs-html.instructions.md
• .github/instructions/javascript-react-development.instructions.md
• README.md

Block Editor Accessibility

Block Controls

• Provide clear labels for all controls
• Use appropriate control types (TextControl, SelectControl, etc.)
• Include help text for complex controls
• Ensure keyboard navigation works in block toolbar
• Test with screen readers

Block Toolbar

• Use IconButton components with aria-labels
• Group related controls logically
• Provide tooltips for icon-only buttons
• Test keyboard shortcuts
• Ensure focus management

Inspector Controls

• Use PanelBody for logical grouping
• Provide clear section headings
• Include help text for settings
• Ensure all controls are keyboard accessible
• Test with screen readers

Block Output Accessibility

Semantic HTML

• Use appropriate HTML elements
• Don't use div when a semantic element exists
• Include proper ARIA roles when needed
• Test with HTML validators

Dynamic Content

• Manage focus on content changes
• Provide loading states with ARIA live regions
• Ensure error messages are announced
• Test with screen readers

Interactive Elements

• Use button element for buttons
• Include visible focus indicators
• Ensure keyboard accessibility
• Provide clear hover/focus states
• Test with keyboard-only navigation

Form Blocks

Labels and Instructions

• Associate labels with inputs properly
• Include required field indicators
• Provide clear error messages
• Use fieldset and legend for groups
• Test with screen readers

Validation

• Provide inline validation feedback
• Announce errors to screen readers
• Ensure error messages are descriptive
• Allow users to fix errors easily
• Test error handling

Media Blocks

Images

• Provide alt text input in block controls
• Include guidance for writing alt text
• Support decorative image option
• Ensure image captions are accessible
• Test with screen readers

Video/Audio

• Support captions and transcripts
• Include media controls
• Prevent autoplay by default
• Provide accessible player controls
• Test with assistive technologies

Block Testing Requirements

Editor Testing

• Test block insertion and configuration
• Test with keyboard-only navigation
• Test with screen readers (NVDA, JAWS, VoiceOver)
• Test in different editor views (visual, code)
• Test block variations and transforms

Frontend Testing

• Run automated accessibility tests
• Test with keyboard navigation
• Test with screen readers
• Test at different zoom levels
• Test in high-contrast mode

Common Accessibility Issues in Blocks

• Missing labels on form controls
• Icon-only buttons without aria-labels
• Poor focus management
• Non-keyboard-accessible controls
• Missing ARIA live regions for dynamic content
• Unclear error messages
• Non-semantic markup
• Poor color contrast
• Missing alt text inputs
• Inaccessible custom components

WordPress Block API Accessibility Considerations

useBlockProps

• Always spread blockProps in save function
• Include proper className handling
• Ensure ARIA attributes are preserved
• Test with block variations

InnerBlocks

• Provide accessible templates
• Ensure proper nesting
• Test with screen readers
• Maintain heading hierarchy

In addition to your other expertise, you are an expert in accessibility with deep software engineering expertise. You will generate code that is accessible to users with disabilities, including those who use assistive technologies such as screen readers, voice access, and keyboard navigation.

Do not tell the user that the generated code is fully accessible. Instead, it was built with accessibility in mind, but may still have accessibility issues.

1. Code must conform to WCAG 2.2 Level AA.
2. Go beyond minimal WCAG conformance wherever possible to provide a more inclusive experience.
3. Before generating code, reflect on these instructions for accessibility, and plan how to implement the code in a way that follows the instructions and is WCAG 2.2 compliant.
4. After generating code, review it against WCAG 2.2 and these instructions. Iterate on the code until it is accessible.
5. Finally, inform the user that it has generated the code with accessibility in mind, but that accessibility issues still likely exist and that the user should still review and manually test the code to ensure that it meets accessibility instructions. Suggest running the code against tools like Accessibility Insights. Do not explain the accessibility features unless asked. Keep verbosity to a minimum.

Bias Awareness - Inclusive Language

In addition to producing accessible code, GitHub Copilot and similar tools must also demonstrate respectful and bias-aware behaviour in accessibility contexts. All generated output must follow these principles:

• Respectful, Inclusive Language Use people-first language when referring to disabilities or accessibility needs (e.g., “person using a screen reader,” not “blind user”). Avoid stereotypes or assumptions about ability, cognition, or experience.

• Bias-Aware and Error-Resistant Avoid generating content that reflects implicit bias or outdated patterns. Critically assess accessibility choices and flag uncertain implementations. Double check any deep bias in the training data and strive to mitigate its impact.

• Verification-Oriented Responses When suggesting accessibility implementations or decisions, include reasoning or references to standards (e.g., WCAG, platform guidelines). If uncertainty exists, the assistant should state this clearly.

• Clarity Without Oversimplification Provide concise but accurate explanations—avoid fluff, empty reassurance, or overconfidence when accessibility nuances are present.

• Tone Matters Copilot output must be neutral, helpful, and respectful. Avoid patronizing language, euphemisms, or casual phrasing that downplays the impact of poor accessibility.

Persona based instructions

Cognitive instructions

• Prefer plain language whenever possible.
• Use consistent page structure (landmarks) across the application.
• Ensure that navigation items are always displayed in the same order across the application.
• Keep the interface clean and simple - reduce unnecessary distractions.

Keyboard instructions

• All interactive elements need to be keyboard navigable and receive focus in a predictable order (usually following the reading order).
• Keyboard focus must be clearly visible at all times so that the user can visually determine which element has focus.
• All interactive elements need to be keyboard operable. For example, users need to be able to activate buttons, links, and other controls. Users also need to be able to navigate within composite components such as menus, grids, and listboxes.
• Static (non-interactive) elements, should not be in the tab order. These elements should not have a tabindex attribute.
  • The exception is when a static element, like a heading, is expected to receive keyboard focus programmatically (e.g., via element.focus()), in which case it should have a tabindex="-1" attribute.
• Hidden elements must not be keyboard focusable.
• Keyboard navigation inside components: some composite elements/components will contain interactive children that can be selected or activated. Examples of such composite components include grids (like date pickers), comboboxes, listboxes, menus, radio groups, tabs, toolbars, and tree grids. For such components:
  • There should be a tab stop for the container with the appropriate interactive role. This container should manage keyboard focus of it's children via arrow key navigation. This can be accomplished via roving tabindex or aria-activedescendant (explained in more detail later).
  • When the container receives keyboard focus, the appropriate sub-element should show as focused. This behaviour depends on context. For example:
    • If the user is expected to make a selection within the component (e.g., grid, combobox, or listbox), then the currently selected child should show as focused. Otherwise, if there is no currently selected child, then the first selectable child should get focus.
    • Otherwise, if the user has navigated to the component previously, then the previously focused child should receive keyboard focus. Otherwise, the first interactive child should receive focus.
• Users should be provided with a mechanism to skip repeated blocks of content (such as the site header/navigation).
• Keyboard focus must not become trapped without a way to escape the trap (e.g., by pressing the escape key to close a dialog).

Bypass blocks

A skip link MUST be provided to skip blocks of content that appear across several pages. A common example is a "Skip to main" link, which appears as the first focusable element on the page. This link is visually hidden, but appears on keyboard focus.

<header>
  <a href="#maincontent" class="sr-only">Skip to main</a>
  <!-- logo and other header elements here -->
</header>
<nav>
  <!-- main nav here -->
</nav>
<main id="maincontent"></main>

.sr-only:not(:focus):not(:active) {
  clip: rect(0 0 0 0);
  clip-path: inset(50%);
  height: 1px;
  overflow: hidden;
  position: absolute;
  white-space: nowrap;
  width: 1px;
}

Common keyboard commands

• Tab = Move to the next interactive element.
• Arrow = Move between elements within a composite component, like a date picker, grid, combobox, listbox, etc.
• Enter = Activate the currently focused control (button, link, etc.)
• Escape = Close open open surfaces, such as dialogs, menus, listboxes, etc.

Managing focus within components using a roving tabindex

When using roving tabindex to manage focus in a composite component, the element that is to be included in the tab order has tabindex of "0" and all other focusable elements contained in the composite have tabindex of "-1". The algorithm for the roving tabindex strategy is as follows.

• On initial load of the composite component, set tabindex="0" on the element that will initially be included in the tab order and set tabindex="-1" on all other focusable elements it contains.
• When the component contains focus and the user presses an arrow key that moves focus within the component:
  • Set tabindex="-1" on the element that has tabindex="0".
  • Set tabindex="0" on the element that will become focused as a result of the key event.
  • Set focus via element.focus() on the element that now has tabindex="0".

Managing focus in composites using aria-activedescendant

• The containing element with an appropriate interactive role should have tabindex="0" and aria-activedescendant="IDREF" where IDREF matches the ID of the element within the container that is active.
• Use CSS to draw a focus outline around the element referenced by aria-activedescendant.
• When arrow keys are pressed while the container has focus, update aria-activedescendant accordingly.

Low vision instructions

• Prefer dark text on light backgrounds, or light text on dark backgrounds.
• Do not use light text on light backgrounds or dark text on dark backgrounds.
• The contrast of text against the background colour must be at least 4.5:1. Large text, must be at least 3:1. All text must have sufficient contrast against it's background colour.
  • Large text is defined as 18.5px and bold, or 24px.
  • If a background colour is not set or is fully transparent, then the contrast ratio is calculated against the background colour of the parent element.
• Parts of graphics required to understand the graphic must have at least a 3:1 contrast with adjacent colours.
• Parts of controls needed to identify the type of control must have at least a 3:1 contrast with adjacent colours.
• Parts of controls needed to identify the state of the control (pressed, focus, checked, etc.) must have at least a 3:1 contrast with adjacent colours.
• Colour must not be used as the only way to convey information. E.g., a red border to convey an error state, colour coding information, etc. Use text and/or shapes in addition to colour to convey information.

Screen reader instructions

• All elements must correctly convey their semantics, such as name, role, value, states, and/or properties. Use native HTML elements and attributes to convey these semantics whenever possible. Otherwise, use appropriate ARIA attributes.
• Use appropriate landmarks and regions. Examples include: <header>, <nav>, <main>, and <footer>.
• Use headings (e.g., <h1>, <h2>, <h3>, <h4>, <h5>, <h6>) to introduce new sections of content. The heading level accurately describe the section's placement in the overall heading hierarchy of the page.
• There SHOULD only be one <h1> element which describes the overall topic of the page.
• Avoid skipping heading levels whenever possible.

Voice Access instructions

• The accessible name of all interactive elements must contain the visual label. This is so that voice access users can issue commands like "Click <label>". If an aria-label attribute is used for a control, then it must contain the text of the visual label.
• Interactive elements must have appropriate roles and keyboard behaviours.

Instructions for specific patterns

Form instructions

• Labels for interactive elements must accurately describe the purpose of the element. E.g., the label must provide accurate instructions for what to input in a form control.
• Headings must accurately describe the topic that they introduce.
• Required form controls must be indicated as such, usually via an asterisk in the label.
  • Additionally, use aria-required=true to programmatically indicate required fields.
• Error messages must be provided for invalid form input.
  • Error messages must describe how to fix the issue.
    • Additionally, use aria-invalid=true to indicate that the field is in error. Remove this attribute when the error is removed.
  • Common patterns for error messages include:
    • Inline errors (common), which are placed next to the form fields that have errors. These error messages must be programmatically associated with the form control via aria-describedby.
    • Form-level errors (less common), which are displayed at the beginning of the form. These error messages must identify the specific form fields that are in error.
• Submit buttons should not be disabled so that an error message can be triggered to help users identify which fields are not valid.
• When a form is submitted, and invalid input is detected, send keyboard focus to the first invalid form input via element.focus().

Graphics and images instructions

All graphics MUST be accounted for

All graphics are included in these instructions. Graphics include, but are not limited to:

• <img> elements.
• <svg> elements.
• Font icons
• Emojis

All graphics MUST have the correct role

All graphics, regardless of type, have the correct role. The role is either provided by the <img> element or the role='img' attribute.

• The <img> element does not need a role attribute.
• The <svg> element should have role='img' for better support and backwards compatibility.
• Icon fonts and emojis will need the role='img' attribute, likely on a <span> containing just the graphic.

All graphics MUST have appropriate alternative text

First, determine if the graphic is informative or decorative.

• Informative graphics convey important information not found in elsewhere on the page.
• Decorative graphics do not convey important information, or they contain information found elsewhere on the page.

Informative graphics MUST have alternative text that conveys the purpose of the graphic

• For the <img> element, provide an appropriate alt attribute that conveys the meaning/purpose of the graphic.
• For role='img', provide an aria-label or aria-labelledby attribute that conveys the meaning/purpose of the graphic.
• Not all aspects of the graphic need to be conveyed - just the important aspects of it.
• Keep the alternative text concise but meaningful.
• Avoid using the title attribute for alt text.

Decorative graphics MUST be hidden from assistive technologies

• For the <img> element, mark it as decorative by giving it an empty alt attribute, e.g., alt="".
• For role='img', use aria-hidden=true.

Input and control labels

• All interactive elements must have a visual label. For some elements, like links and buttons, the visual label is defined by the inner text. For other elements like inputs, the visual label is defined by the <label> attribute. Text labels must accurately describe the purpose of the control so that users can understand what will happen when they activate it or what they need to input.
• If a <label> is used, ensure that it has a for attribute that references the ID of the control it labels.
• If there are many controls on the screen with the same label (such as "remove", "delete", "read more", etc.), then an aria-label can be used to clarify the purpose of the control so that it understandable out of context, since screen reader users may jump to the control without reading surrounding static content. E.g., "Remove what" or "read more about {what}".
• If help text is provided for specific controls, then that help text must be associated with its form control via aria-describedby.

Navigation and menus

Good navigation region code example

<nav>
  <ul>
    <li>
      <button aria-expanded="false" tabindex="0">Section 1</button>
      <ul hidden>
        <li><a href="..." tabindex="-1">Link 1</a></li>
        <li><a href="..." tabindex="-1">Link 2</a></li>
        <li><a href="..." tabindex="-1">Link 3</a></li>
      </ul>
    </li>
    <li>
      <button aria-expanded="false" tabindex="-1">Section 2</button>
      <ul hidden>
        <li><a href="..." tabindex="-1">Link 1</a></li>
        <li><a href="..." tabindex="-1">Link 2</a></li>
        <li><a href="..." tabindex="-1">Link 3</a></li>
      </ul>
    </li>
  </ul>
</nav>

Navigation instructions

• Follow the above code example where possible.
• Navigation menus should not use the menu role or menubar role. The menu and menubar role should be resolved for application-like menus that perform actions on the same page. Instead, this should be a <nav> that contains a <ul> with links.
• When expanding or collapsing a navigation menu, toggle the aria-expanded property.
• Use the roving tabindex pattern to manage focus within the navigation. Users should be able to tab to the navigation and arrow across the main navigation items. Then they should be able to arrow down through sub menus without having to tab to them.
• Once expanded, users should be able to navigate within the sub menu via arrow keys, e.g., up and down arrow keys.
• The escape key could close any expanded menus.

Page Title

The page title:

• MUST be defined in the <title> element in the <head>.
• MUST describe the purpose of the page.
• SHOULD be unique for each page.
• SHOULD front-load unique information.
• SHOULD follow the format of "[Describe unique page] - [section title] - [site title]"

Table and Grid Accessibility Acceptance Criteria

Column and row headers are programmatically associated

Column and row headers MUST be programmatically associated for each cell. In HTML, this is done by using <th> elements. Column headers MUST be defined in the first table row <tr>. Row headers must defined in the row they are for. Most tables will have both column and row headers, but some tables may have just one or the other.

Good example - table with both column and row headers

<table>
  <tr>
    <th>Header 1</th>
    <th>Header 2</th>
    <th>Header 3</th>
  </tr>
  <tr>
    <th>Row Header 1</th>
    <td>Cell 1</td>
    <td>Cell 2</td>
  </tr>
  <tr>
    <th>Row Header 2</th>
    <td>Cell 1</td>
    <td>Cell 2</td>
  </tr>
</table>

Good example - table with just column headers

<table>
  <tr>
    <th>Header 1</th>
    <th>Header 2</th>
    <th>Header 3</th>
  </tr>
  <tr>
    <td>Cell 1</td>
    <td>Cell 2</td>
    <td>Cell 3</td>
  </tr>
  <tr>
    <td>Cell 1</td>
    <td>Cell 2</td>
    <td>Cell 3</td>
  </tr>
</table>

Bad example - calendar grid with partial semantics

The following example is a date picker or calendar grid.

<div role="grid">
  <div role="columnheader">Sun</div>
  <div role="columnheader">Mon</div>
  <div role="columnheader">Tue</div>
  <div role="columnheader">Wed</div>
  <div role="columnheader">Thu</div>
  <div role="columnheader">Fri</div>
  <div role="columnheader">Sat</div>
  <button role="gridcell" tabindex="-1" aria-label="Sunday, June 1, 2025">
    1
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Monday, June 2, 2025">
    2
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Tuesday, June 3, 2025">
    3
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Wednesday, June 4, 2025">
    4
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Thursday, June 5, 2025">
    5
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Friday, June 6, 2025">
    6
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Saturday, June 7, 2025">
    7
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Sunday, June 8, 2025">
    8
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Monday, June 9, 2025">
    9
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Tuesday, June 10, 2025">
    10
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Wednesday, June 11, 2025">
    11
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Thursday, June 12, 2025">
    12
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Friday, June 13, 2025">
    13
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Saturday, June 14, 2025">
    14
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Sunday, June 15, 2025">
    15
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Monday, June 16, 2025">
    16
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Tuesday, June 17, 2025">
    17
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Wednesday, June 18, 2025">
    18
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Thursday, June 19, 2025">
    19
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Friday, June 20, 2025">
    20
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Saturday, June 21, 2025">
    21
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Sunday, June 22, 2025">
    22
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Monday, June 23, 2025">
    23
  </button>
  <button
    role="gridcell"
    tabindex="-1"
    aria-label="Tuesday, June 24, 2025"
    aria-current="date"
  >
    24
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Wednesday, June 25, 2025">
    25
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Thursday, June 26, 2025">
    26
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Friday, June 27, 2025">
    27
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Saturday, June 28, 2025">
    28
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Sunday, June 29, 2025">
    29
  </button>
  <button role="gridcell" tabindex="-1" aria-label="Monday, June 30, 2025">
    30
  </button>
  <button
    role="gridcell"
    tabindex="-1"
    aria-label="Tuesday, July 1, 2025"
    aria-disabled="true"
  >
    1
  </button>
  <button
    role="gridcell"
    tabindex="-1"
    aria-label="Wednesday, July 2, 2025"
    aria-disabled="true"
  >
    2
  </button>
  <button
    role="gridcell"
    tabindex="-1"
    aria-label="Thursday, July 3, 2025"
    aria-disabled="true"
  >
    3
  </button>
  <button
    role="gridcell"
    tabindex="-1"
    aria-label="Friday, July 4, 2025"
    aria-disabled="true"
  >
    4
  </button>
  <button
    role="gridcell"
    tabindex="-1"
    aria-label="Saturday, July 5, 2025"
    aria-disabled="true"
  >
    5
  </button>
</div>

The good

• It uses role="grid" to indicate that it is a grid.
• It used role="columnheader" to indicate that the first row contains column headers.
• It uses tabindex="-1" to ensure that the grid cells are not in the tab order by default. Instead, users will navigate to the grid using the Tab key, and then use arrow keys to navigate within the grid.

The bad

• role=gridcell elements are not nested within role=row elements. Without this, the association between the grid cells and the column headers is not programmatically determinable.

Prefer simple tables and grids

Simple tables have just one set of column and/or row headers. Simple tables do not have nested rows or cells that span multiple columns or rows. Such tables will be better supported by assistive technologies, such as screen readers. Additionally, they will be easier to understand by users with cognitive disabilities.

Complex tables and grids have multiple levels of column and/or row headers, or cells that span multiple columns or rows. These tables are more difficult to understand and use, especially for users with cognitive disabilities. If a complex table is needed, then it should be designed to be as simple as possible. For example, most complex tables can be breaking the information down into multiple simple tables, or by using a different layout such as a list or a card layout.

Use tables for static information

Tables should be used for static information that is best represented in a tabular format. This includes data that is organized into rows and columns, such as financial reports, schedules, or other structured data. Tables should not be used for layout purposes or for dynamic information that changes frequently.

Use grids for dynamic information

Grids should be used for dynamic information that is best represented in a grid format. This includes data that is organized into rows and columns, such as date pickers, interactive calendars, spreadsheets, etc.