Blueprint by Tiny
Return to Tiny.cloud
Return to Tiny.cloudTry TinyMCE for Free
Search by

Top 12 tips to make your website accessible

Lawanya Baskarran

October 15th, 2019

Written by

Lawanya Baskarran

Category

Tips & How-Tos

The power of the Web is in its universality. Access by everyone regardless of disability is an essential aspect.

Tim Berners-Lee, W3C Director and inventor of the World Wide Web

Building an inclusive website is about providing all users of your site with the same level of user experience. It is important to approach web accessibility as part of your design, from the very beginning of the planning process. This reduces the time, cost, and effort involved in inserting accessible elements into your website at a much later stage in implementation.

So here are 12 tips to help make your website accessible.

BONUS TINY TIP: Note that text editors like our own TinyMCE can go a long way to provide an accessible experience both for your content authors and for the consumers of their content. Read more about how to make your web content accessible with TinyMCE.

1. Use semantic elements

This is one of the best ways to make a website accessible and user-friendly, but also one that is often ignored. Semantic HTML elements (such as <header>, <footer>, <main>) clearly communicate their purpose and the type of content within them. Furthermore, they enable users of screen readers to navigate through content with more ease.

Some of the most common ways in which semantic HTML elements are overlooked are: 

  • Using <div> tags to section a page instead of semantic tags such as <article>, <aside>, <section>, etc.
  • Using a <div> instead of a <button>
  • Using <p> with increased font size instead of using headings
  • Poor usage of header tags (<h1>, <h2>, etc.)

Using header tags in the right context, order, and without skipping levels is vital for search engines to identify what the webpage is about, and also to help screen reader users understand the content structure.

2. Enable content to be accessed through the keyboard alone

In some cases, users may not be able to use a mouse or trackpad, accessing content only through the use of a keyboard or alternative input device such as a head stick. These users rely on the “tab” and “arrow” keys to navigate through the webpage.

  • Ensure that all content can be accessed with the keyboard alone in a logical way that matches the visual structure
  • Provide keyboard shortcuts wherever possible
  • Break up large portions of text
  • Avoid using elements that only activate on mouse hover

3. Provide “alt” text for non-decorative images

For users who are unable to see images, it’s important to provide alternative means to convey the information in them.

  • Add alt text (alternative text) to images so screen reader users can perceive the information relayed by the image.
  • Make sure the alt text is detailed and descriptive.
  • Try to avoid using images of text if possible. But if the image contains text, include it in the alt text.
  • If the image conveys complex information such as graphs or charts, it’s a good idea to include a link to a separate page with a text description of the same.

Exceptions to this rule are background images and images added solely for decorative purposes. In these cases, leave the alt text empty (i.e., alt=””).

Example alt text for images:

<img src="snowy-mountain.jpg" alt="Snow-covered mountain with valley and city at its base">

4. Include descriptive link names

Screen reader users can sometimes skip over content and scan for links. In these cases, phrases like “learn more” or “click here” do not provide any context or information about what the link relates to.

Provide context by using more descriptive link text, like “learn more about how to make web pages accessible” or “click here to register for a free cloud account”. In places where this is not possible, the aria-label attribute can be used to aid screen reader users by adding context.

Note that image links need alt text describing the link; otherwise, screen readers will read the link’s file name. For example:

<a href="accessibility.htm"><img src="read-more.jpg" alt="Click here to read more about accessibility"></a>

5. Use color inclusively

Avoid using only colors to deliver information. The most common color deficiency is the inability to distinguish between red and green. So, for example, using only these colors to indicate errors or correctness in a form field would be unhelpful. However, the use of color is useful to people with learning disabilities.

  • Use both colors and other visual cues to benefit both sets of users.
  • Indicate required fields using the :required CSS pseudo-class combined with accessible error checking (using ARIA attributes such as aria-required, aria-errormessage, aria-live, etc.). 

Additionally, use optimal color contrast between background and text colors to help low vision users. These are the color contrast ratios that meet the WCAG 2.0 standards:

Normal text: below 14pt bold or 18pt normal: AA: 4.5:1 
Large text: 14pt bold or 18pt normal, and above: AA: 3:1

There are plenty of tools around that can help you analyze the contrast between your foreground and background colors. Here’s one example of an online color contrast checker.

6. Design inclusive forms

Online forms can be daunting for all of us, even with full use of vision and motor abilities. Designing accessible forms can significantly improve user experience. Some points to remember when implementing forms are:

  • Clearly indicate the field with focus and make it stand out from the background.
  • Tabbing using the keyboard should allow for logical navigation through all the form fields as well as the “Submit” button at the end.
  • Avoid using positive tab indices to set the tab order. This will interfere with the natural tab flow. Instead, use “0” to include an element in the tab order (that would not usually be focusable) or “-1” to remove an element from it.
  • Provide a clear relationship between labels and their corresponding fields. Screen readers will sometimes guess labels if they are not properly associated with fields, and this can produce undesirable results.
  • Avoid using only placeholders as labels, especially in autocomplete forms. Placeholders are hidden from screen readers and are not good for color contrast either.
  • Make sure aria-labels match the visual labels on buttons.
  • Provide alternatives to inaccessible content such as date pickers, such as a text field where the date can be entered manually.
  • Avoid using captcha. If needed, use text-based captcha.
  • Provide the ability to extend the time limits to complete forms.
  • Include a confirmation page that allows users to go back and edit the form if required.

7. Make text accessible

Tables should only be used to provide tabular content. Using tables to structure a page can be confusing for screen reader users. Instead, consider using CSS flex or grid for page layout.

Elderly and low vision users often zoom in on content for reading. Therefore, it is essential to allow for readable content when zoomed up to 200%.

Here are a few more points to make the text on your web pages more readable:

  • Use text instead of symbols – symbols can have ambiguous meanings 
  • Make link text look significantly different from plain text 
  • Expand abbreviations 
  • Avoid justified text 
  • Use the “lang” attribute to define the language of the elements in the webpage

8. Use ARIA roles and attributes where necessary

Web Accessibility Initiative – Accessible Rich Internet Applications (WAI-ARIA), published by the World Wide Web Consortium (W3C), is a comprehensive set of technical specifications for adding accessibility information to HTML elements. These can be incredibly powerful for adding details to help screen reader users interact with elements, or to hide information that does not provide value to them.

For instance, ARIA “roles” define what an element is or does, “properties” are used to give them extra meaning or semantics, and “states” are special properties that define the current conditions of elements, such as aria-disabled=”true”, which specifies to a screen reader that a form input is currently disabled.

However, it’s important to note that ARIA roles should only be used to make native elements accessible, not to replace them. For example, it is better to use the <nav> element that already indicates that the content within it is for navigation purposes than to use the ARIA navigation role.

9. Make dynamic content accessible

Modern websites often include content that changes dynamically, for example, task percentages, status updates, and personalized content. Dynamic content also includes audiovisual elements, such as sound, video, animation, and graphical images.

Screen readers usually ignore dynamic content, but it is vital that these elements are inclusive, and that all users’ needs are considered when used.

ARIA attributes are particularly useful to make these elements accessible. And here are some additional ideas:

  • Include closed or open captions to video content, and text transcripts for audio content.
  • Add accessible controls to videos. Avoid auto-playing content.
  • Provide text descriptions and a way to control image sliders or carousels.
  • Add a way to stop moving text.
  • Avoid auto-submitting forms or making significant changes to context within the page.
  • Minimize content that changes on focus or hover.
  • Alert users to any changes in the webpage content.
  • Allow status messages to stay open until dismissed. 
  • Avoid adding script that moves focus to itself.

10. Don’t use CSS to present critical information

Screen readers do not read any CSS, and CSS-only images are hidden in high contrast mode. So, it’s best not to provide essential information through CSS.

11. Reduce flickering

Flashing content will trigger epilepsy in photosensitive users. It is advisable not to include any flashing content that flickers more than three times in any one second period.

12. Test for accessibility using the right tools

Make screen reader testing a priority and a natural part of the testing ecosystem. This will help identify inaccessible elements early in the process.

Additionally, it helps to have a WCAG specification or accessibility checklist to refer to during development.

There are a variety of free and paid resources that help produce accessible content and detect inaccessible elements in your webpages. These tools include color contrast checkers and browser extensions like the Axe tool, that comb the web page for accessibility bugs. 

If you are using a CMS (Content Management System), choose accessible themes, and check that the CMS and its text editor have been designed with accessibility in mind.

What next?

While you’re here, find out how to make your web content accessible with TinyMCE and try the live demo of our Accessibility Checker plugin.

Accessibility
byLawanya Baskarran

Software Developer at Tiny. Accessibility engineer, committed to providing developers and content creators with the means to apply web content accessibility requirements with minimal effort.

Related Articles

  • Depiction of three ways to try TinyMCE
    Tips & How-Tos

    3 ways to try TinyMCE (with live examples)

    by Ben Long in Tips & How-Tos

Build beautiful content for the web with Tiny.

The rich text editing platform that helped launch Atlassian, Medium, Evernote and more.

Begin my FREE 30 day trial
Tiny Editor