The most important design principle: Be inclusive

I’ve made some previous posts about design systems, which are all the rage in 2017. We are still working through the creation of one at my organization. One of the core parts of design systems are principles.

These principles ideally shape the future of design for an organization. The most important thing that I keep coming back to when thinking about how to create interfaces is to be inclusive.

Be inclusive

This is the most important design principle you can have as an organization. Convincing people that it is important can take a lot of work and often times you will be fighting an existing culture that says “If it works on my computer then its good.” A lot of people don’t stop to consider all the other ways people can be accessing their site/content.

What does that mean?

If your creative team is well versed in inclusive design principles, then it’s easy: Hand over design authority to your creative team. Are you reaching as many people as you can? If your superiors look at your creative team as tools that will do what they say and create what they want then it is incredibly difficult to design inclusively.

The problem with this approach is that often times the stakeholders who are “driving the bus” so to speak, are not well versed in performance, accessibility, and usability — all three of these areas are vital to being inclusive.


It’s nice that the site works on your high speed, wired internet connection, but how does it perform with spotty WiFi or on 3G speeds? Are you able to access the site in these situations?


I think this is what a lot of people think of when talking about being inclusive. Is your site designed and developed in a way that takes into account WCAG 2.0 (the de-facto standard for accessibility guidelines)? Complying with these guidelines helps everyone, not just those with disabilities. Microsoft has done a phenomenal job at explaining that disabilities are not personal health conditions, but rather mismatched human interactions.


Usability is closely related to performance and accessibility. If the site isn’t performant and accessible then it isn’t usable. On top of that, ensure your site is following agreed upon UI patterns to ensure a consistent experience across your site.

This is not a complete or exhaustive list by any means but it seems to me that keeping these three areas in mind will go a long way in ensuring that your site is inclusive.

How to do a basic accessibility audit on your site

Here are some tools and methods for running an accessibility audit on your site. This can be a little bit easier if you already have a design system or component library in place, but it isn’t necessary to gain some insights into how your site can be more accessible.

The way I usually do it is I first run some automated accessibility checkers, then I do some manual testing. I’ll unpack what this means below.

Note: most of this information is a summary of the W3C’s WCAG site, which is the authority on recommendations regarding web content accessibility. The content on that site can be a little dense so hopefully this provides a good summary and jumping off points.

Free automated accessibility checkers

One thing that is important to remember when using automated tools is that they are not perfect. Just because your site “passes” an automated check doesn’t mean that it is accessible. Also if your site has errors, that doesn’t necessarily mean that it is inaccessible.

Web accessibility evaluation tools can not determine the accessibility of Web sites; they can only assist in doing so.

That being said, it is still quite valuable to run automated checkers on your sites because they can assist in catching errors before manual testing takes place.

One of the more popular automated checkers is WAVE by WebAim. This site allows you to enter a URL and then get a live preview of your site with highlighted accessibility issues in there. It certainly isn’t perfect because it can report some false positives, but it’s a great way to catch obvious issues and contrast errors.

Image of accessibility audit on my site through WAVE.
WAVE’s accessibility audit

Further reading

Manual testing

Here is where the “real” accessibility testing comes in. I say “real” because these methods are actually emulating how users with disabilities actually use your site. Manual testing also can help find gaps in your automated testing.

Keyboard navigation

A basic principle of WCAG 2.0 recommendations is that your site should be operable using nothing more than a keyboard. Give it a shot. Run through your site using your keyboard by pressing tab. Many users with limited motor control rely on keyboard navigation to navigate web sites.

  • Can you access all the links in a logical order?
  • Does advanced functionality like carousels work with keyboard controls?

Reading up on the tabindex attribute can provide enough know-how to make your site way more accessible.

Using voiceover or screen readers

I’m on a Mac so it was quite eye-opening for me to browse sites using the built in Voiceover functionality that comes with all Macs. Using Voiceover shed some light on accessibility principles that I never really understood properly.

For example, we all know the basic rule-of-thumb that alt text is good to use on images. But when using Voiceover, alt text can actually hinder understanding of certain elements such as images with text over them.

Consider this simple image block:

Image block example with text overlay

This image block has alt text of “Student at computer,” which most accessibility novices would assume is a good thing. However, Voiceover reads this element as “Link, Online MBA ranks highest in state student at computer.” This is less than ideal because it is actually less meaningful than if it had alt=””. In situations like this, screen readers tack on alt text to the text that is in the element. By using alt=”” in these situations you can be sure that screen readers will obtain the true meaning of the element.

This is a great example of something that can only be caught using manual testing.

In closing

This was a very brief overview of some tools, resources, and techniques to test your site against WCAG 2.0 accessibility recommendations.

To take it to the next level, there is no substitute for reading the WCAG 2.0 site and browsing through the quick reference provided by the W3C on how to meet the recommendations.

Happy auditing!