Skip to main content

Accessibility Checklist

To ensure inclusive design and development practices, the DUIL team utilizes this accessibility checklist when creating new features. This process supports a positive experience for all users of our products and reinforces our dedication to quality.

  • Download and install Axe Chrome extension to check off this item.
    Download and install NVDA for Windows to check off this item.
    Download and install JAWS for Windows to check off this item.
    macOS ships with VoiceOver which can be enabled through preferences.through preferences.
    Android ships with TalkBack which can be enabled by followingthese instructions.
    High contrast mode uses a limited color palette with contrasting colors to make an interface easier to use.
    Follow these instructions to change the default text size in Chrome.
    Most browsers allow you to zoom in or out using Cmd and +/- keys.
  • Valid HTML helps to provide a consistent, expected experience across all browsers.
    Thishelps assistive technologies,  such as screen readers, to pronounce content correctly.
    Thishelps people using assistive technologies to understand what view they are going to start navigating.
    Landmarks help communicate the layout, and allow direct access to these regions.
    Elements that are inherently focusabledon’t require a tabindex.
    Autofocus HTML attribute should be avoided. Focus into fields programmatically instead where necessary.
    The title attribute hasmultiple issues and should not be used.
    Links should always have a href attribute, even in SPAs. Without this, the link won’t be properly recognized.
    Users of assistive technology expect a button to do an action. If you need to navigate into another view, use a link.
    Do you need to display data in rows and columns? Use table element.
    Correct use of table headers helps users of assistive technology to understand your data.
    A caption should describe what kind of information the table contains.
  • Some people cannot use a mouse, so it’s important that the interface can be navigated with a keyboard.
    Can a person navigating with a keyboard, switch, voice control, or screen reader see where they currently are?
    Can a person move around the page in a predictable way?
    Remove any elements that are not presently meant to be discoverable.
    Users of assistive technology expect a button to behave in a certain way.
    As well as using the “close” button, it should be possible to close a dialog by pressing the Esc key.
  • Use a for/id pairing to guarantee the highest level of browser support.
    Use fieldset to group sections of related inputs, and legend to provide a label for the section.
    Supporting autocomplete allows users to utilise existing text entry features on their device, minimising friction when filling in forms.
    This allows users to clearly understand the difference between the input and the error.
  • Accessible writing ensures your content is understandable for everyone to read. UseReadability Analyzer set to '8th grade level' to check your writing.
    Avoid terms like “click here” and “read more” which do not provide any context for the user.
    The h1 element should be used to communicate the high-level purpose of the page or view.
    The order of heading elements should descend, based on the depth of the content.
    If heading levels need to be skipped for a specific visual style, use CSS classes instead.
    This may also include sections of related content and items displayed in a grid layout.
    A skip link is used to provide direct access to the main content of a page or view.
    People with low vision require increased space between lines to be able to read text.