Back to Blog

Web Accessibility: tips & tools


Accessibility is an important and often forgotten element of building websites and digital products. While W3C’s Web Accessibility Initiative lays out specific standards to follow, it’s surprising how many of those steps are left out in websites and products we use everyday. As the industry continues to make progress in creating a more inclusive web, we should all internalize these standards and own them in our day-to-day work. In this series, members of our project management, development, and design teams share honest reflections and tips on how we can champion accessibility.

In our last article, we explored the struggles of inaccessible websites. It is our hope that through sharing insights and tips, we can bring accessibility best practices to our communities. The following development tips are in accordance with the WCAG 2.0 guidelines, and address some of the most common roadblocks. Note: This list of tips is not the silver bullet in making all things accessible on your website, but the necessary first steps in getting things underway.


Ensure there are text alternatives for any non-text content to convey the same meaning as one would visually.

Ways to check

  • Using a browser’s developer tools, inspect image elements to ensure an appropriate alt attribute is declared.
  • Navigate to the image with a screen reader to verify appropriate descriptive text is announced.

Compliancy first steps

  • Provide a concise description within the alt attribute which will present the same content and function of the non-text content.
  • Do not be redundant or provide the same text information within the context of the image. I.e. The alternative text for an image does not need the “a picture of …” within the description as the screen reader will already present that the current non-text content is an image. If the image is contained within a within a link with visible text that would serve to describe the image then alt= “” is an appropriate value for alternative text:
<button type=“button”>
<img src= “save-icon.png” alt=“”>
  • Functional images (i.e. an image link) should describe its function in the alternative text along with the content if there is no visual text describing the functional image:
<a href= “”>
<img src= “fts-logo.png” alt= “Fresh Tilled Soil: home”>
  • ALT tags are generally recommended to be no more than 130 characters. Exceptions to this rule, if the non-text content is a chart, map, or screen capture that holds content information.

Provide semantic information structure

Ways to check

  • Navigate through the content with a screen reader and determine if the relationships between the heading structure and elements are accurate. I.e. Do the preceding headings give a proper concise description of the following element content?
  • Turn off the CSS, and solely focus on the HTML, determine if the information presented is laid out in a structure that makes sense without visual cues.
  • Use the WAVE tool to evaluate the website’s accessibility violations such as heading markup errors.

Compliancy first steps

  • Ensure to have appropriate landmarks (i.e. banner, header, main, footer), so that users who rely on Assistive Technology (AT) such as screen readers can easily navigate to those certain areas of the page.
  • Make sure to provide adequate labeling and attributes for elements, instead of relying solely on visual. I.e. use the required attribute with appropriate styling to ensure all users know that a form input is required.
  • For unordered and ordered lists, ensure to have the appropriate semantic tags. I.e. Unordered lists must use asterisks, dashes, or bullet characters, while for ordered lists use numerical or alphabetical tags in ascending sequential order.

Establish proper headings and labels markup

Ways to check

  • Inspect the HTML code with a developer tool to check if the heading structure has a proper hierarchy in the markup.
  • Check to see that each heading has the appropriate relationship with the content element. Does the heading provide concise info and a clear idea of upcoming content?
  • If a form is present, navigate to it with a screen reader and determine if the labels give clear purpose for the following input fields. If you only heard the labels for the form fields, will it be enough?

How to be compliant

  • The H1 should typically be reserved for the page title, H2 for major headings, H3 for major subheadings, and H4 for minor subheadings. Once that is determined, make sure to keep that structure throughout the project. Here is a resource on accessible headings.
  • Do not use the headings tag for the sake of setting certain font sizes, that is the purpose of the CSS. Use the H tags to mark document headings
  • Make sure to have the headings identify its section of the content accordingly.
  • Ensure that the label is clear and specific with the component’s purpose within the Web content. I.e. A form asking the name of a user – first and last name. Thus, the first field should be labeled “First name”, the second is labeled “Last name”.

Provide accessible web forms

Ways to check

  • Use the screen reader and navigate through the form and determine if you are able to fill out the form using just the audible cues.
  • Check that there is prompt text next to each item of input in the form.
  • Using the keyboard only, determine if you are able navigate through the form and complete it without a mouse or touchpad.
  • Compare how you are structuring your form with forms being structured by Mozilla with accessibility in mind.

How to be compliant

  • Design and structure forms so they are logical and easy to use. They should be clear, intuitive and organized in a holistic manner.
  • Provide clear instructions about what information is needed to complete. If there are any required form fields, be sure to indicate them using appropriate labeling or attributes.
  • It is important that every single field has a label. Providing an associated label means that inputs will be announced properly:
<input type="text">

will be announced as “text input” while

<label for="name">
<input type="text" id="name">

will be announced as name: edit text

  • Labels should be positioned in an intuitive manner, so that low vision users are able to easily associate checkboxes, radio buttons, and other forms controls with their labels.
    I.e. A label for a checkbox should not be positioned all the way to the left of a page when the checkboxes are set on the right.
  • Use the fieldset and legend elements to group form fields that relate to each other within the form e.g. radio button groups.
  • Use this form tutorial by W3 to have a structured plan in form accessibility.
  • Check out WebAIM’s techniques in setting the appropriate and accessible text inputs, checkboxes, buttons, and other form controls.

For more resources, please check out some of our past blog posts and podcasts on accessibility:

Author Jimi Choi

More posts from this author

Sign up to receive updates from our blog

What we do Expertise

From concept to design, we'll partner with your team to deliver amazing product and website experiences.

Recent Projects Work

See the results of our most recent digital product and website engagements.