Accessibility practical guide

permanent temporary situational accessibility

Recently in many front-end conferences, the accessibility topic appears very often and in some way, it reminds me the endless discussion about how styles should be done using the CSS-preprocessors/CSS or some CSS-Modules solutions etc. Hot topic? So how to make our own sites more accessible?

Why actually should we care about accessibility? I think everyone has their own different answer to this question. And there are a lot of possible ones:

  • we just want to care more about other people (Sara was a great example here for me):
  • we have a need in the accessible websites in out life
  • we are afraid that we will need something to be accessible in the future, and it wouldn’t be
  • we have read Microsoft guide about inclusive design and were moved by this one illustration with understanding how often we are already at least situationally disabled (my case):

permanent temporary situational accessibility

and I think there are many other meaningful and good answers for this question.

If there are so many answers, why then we do not have most of the sites available in the modern web accessible? I think there are as well many answers for this one question (yeah, I am judging by self here):

  • it is boring
  • it requires a lot of time and we do not have time for this as we have 1000+ tasks to do
  • I just do not know how to do my site more accessible etc. etc.

The truth is, that we shouldn’t do a lot to make our site accessible, as:

When I have started working on accessibility in my previous place of work, I have found out for myself, that most of the issues with the accessibilities with the modern web tools are easy to detect (and from time to time slightly harder to fix). So, I collected practical points that include tools link, that will help you easily detect the accessibility issues. Be aware, that this is not a comprehensive list and it just summarizes my own experience with making things accessible. Check this one resource https://www.wuhcag.com/wcag-checklist/ that can help make the full accessibility audit for the website. Also keep in mind that the check should be done not only for the initial state of the page, but include also other page states.

1. Chrome accessibility extension

What type of issue this can catch: 1.1.1 – Non-text Content1.4.3 Contrast (Minimum)1.3.1 – Info and Relationships (partly), 2.4.4 – Link Purpose (In Context)3.1.1 – Language of Page etc.

2. Disable CSS on your web-site

Use this extension for Chrome to disable CSS https://chrome.google.com/webstore/detail/web-developer/bfbameneiokkgbdmiekhjnmfkcnldhhm (check for the Firefox extension http://stackoverflow.com/a/14046754/4213708) and check that your web page displays in the correct meaningful order.

What type of issue this can catch: 1.3.2 Meaningful Sequence

3. Content Check – no references to the control colors in the content

Make sure that there no reference in the text colors of the controls that should be clicked/hovered etc. If the page contains charts: the information conveyed in diagrams and multimedia must be able to be perceived without using color cues, e.g. lines/areas on graphs should not just be differentiated by color, but also by style (dotted, dashed etc.) or labels.

What type of issue this can catch: 1.4.1 – Use of Colour

4. Manual Check – is the text resize properly in the website

Check your website by resizing to 200% in a variety of browsers. Make sure your resized text doesn’t require the user to scroll horizontally.

What type of issue this can catch: 1.4.4 – Resize Text

5. Visual/content check – no images that contain text (exceptions applied)

Visual check that the page doesn’t contain any images, that contain meaningful text.

What type of issue this can catch: 1.4.5 – Images of Text 

6. HTML Parsing

The easiest way is to use extensions for the validation HTML, for example for the Chrome – https://chrome.google.com/webstore/detail/validity/bbicmjjbohdfglopkidebfccilipgeif?hl=en-GB and fix all the tags that are causing the errors. Angular attributes errors can be ignored. Parsing checking also can be made here https://validator.w3.org/

What type of issue this can catch: 4.1.1 – Parsing

7.  Manual check – site accessible for the users, that use keyboard only

Access the page you want to check, using the “Tab” key only try to reach every control that is present on the page. Make sure, that you can visually identify which element focus currently is on (in most case the focus is identified by outline) and all controls are accessible by the keyboard only.

What type of issue this can catch: 2.4.7 – Focus Visible2.1.2 – No Keyboard Trap2.1.1 – Keyboard2.4.3 – Focus Order

Have your easy-to-check points, that can help find/fix accessibility issues? Leave them in the comment below. 🎩🎩🎩

P.S. When I was actually writing this post I have seen this video. I have been deeply moved by the words of Mandy: “I wanted to do more with my life than just to give up”. In our everyday job, we can do more than just create a website – with providing at least partly accessible site – we can magicians for many users.

If you have found a spelling error, please, notify us by selecting that text and pressing Ctrl+Enter.

Olena Sovyn
Front-end developer (London, UK). I ❤ React, Redux, lodash, React Storybook, and functional programming overall. Always open to learn something new

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Spelling error report

The following text will be sent to our editors: