An inside look at the specifics of how we addressed and are working towards resolving web accessibility issues on our web portals.
BACKGROUND
Microsoft has committed to making all its products, applications, sites accessible to all users including people with disabilities. In recent times the company has made significant progress in accessibility; from building Windows 10 with improved assistive technologies to adding new accessibility features to Microsoft Edge. You might have had also heard about Xbox’s adaptive controller features, designed to primarily meet the needs of gamers with limited mobility. In this context, I was involved in driving the accessibility aspect of our web portals. Below I am sharing my experience of designing the process to address accessibility issues throughout our sites across all product lines we own.
WHAT IS ACCESSIBILITY?
More than 1 billion people live with some sort of disability worldwide, that pertains to more than 14% of the world population. By 2020, 22% of the world’s population will be over 60 years and each one of us may encounter situational disabilities at some point throughout our everyday lives. Accessibility, in a nutshell, is about making the world accessible to as many people as possible; ensuring that there are no barriers for people to perceive, operate, understand or consume the information. Be it the services or products, or everyday appliances, applications, websites and so forth. It is part of the law in some countries to address accessibility issues. Also, it is believed that the estimated annual buying power for people with disabilities is 3 trillion dollars. So addressing accessibility doesn’t just makes sense from the humanitarian level but it also adds to your bottom line.
WHAT IS WEB ACCESSIBILITY?
As per the w3c site: web accessibility simply means designing and developing websites, tools, and technologies in such a way that people with disabilities can use them. So, people can: perceive, understand, navigate, and interact with the web and also contribute to the web.
Web accessibility encompasses all disabilities that affect access to the web, including auditory, cognitive, neurological, physical, speech, visual.
One important thing to note here is; accessibility overlaps with other best practices as well such as mobile web design, device independence, multi-modal interaction, usability, design for older users, and search engine optimization (SEO). Accessible websites can have better search results, reduced maintenance costs, increased audience reach.
PRE-EVALUATION
Source
In order to evaluate the site, we needed to understand the evaluation process first, below I have tried my best to summarize the web accessibility guidelines, its various conformance levels, and normative or non-normative conformances that are parts of the overall evaluation process.
Given below is a brief explanation of all those aspects:
The Web Content Accessibility Guidelines (WCAG) published by the Web Accessibility Initiative (WAI) of the World Wide Web Consortium (W3C) has four principles. For my own understanding, the acronym of these four principles is POUR. When we started the work, we were following WCAG 2.0; that was published in 2008 (superseded WCAG 1.0). As per WCAG 2.0 website needs to follow the below four principles:
- P stands for Perceivable – Information and user interface components must be presentable to users in ways they can perceive.
This means that users must be able to perceive the information being presented (it can’t be invisible to all of their senses). - O stands for Operable – User interface components and navigation must be operable.
This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform) - U stands for Understandable – Information and the operation of user interface must be understandable.
This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding). - R stands for Robust – Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.
This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible).
WCAG 2.0 lists 12 guidelines altogether. Given below are each guideline per principle:
Perceivable:
Guideline 1.1: Provide text alternatives for any non-text content so that it can be changed into other forms people need, such as large print, braille, speech, symbols or simpler language.
For instance: add alt text for images, add discernible link description or purpose.
Guideline 1.2: Time-based Media: Provide alternatives for time-based media.
Guideline 1.3: Adaptable: Create content that can be presented in different ways (for example simpler layout) without losing information or structure.
Guideline 1.4: Distinguishable: Make it easier for users to see and hear content including separating foreground-background.
Operable:
Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard.
Guideline 2.2: Enough Time: Provide users enough time to read and use the content.
Guideline 2.3: Seizures: Do not design content in a way that is known to cause seizures.
Guideline 2.4: Navigable: Provide ways to help users navigate, find content, and determine where they are.
Understandable:
Guideline 3.1: Readable: Make text content readable and understandable.
Guideline 3.2: Predictable: Make web pages appear and operate in predictable ways.
Guideline 3.3: Input Assistance: Help users avoid and correct mistakes.
Robust:
Guideline 4.1: Compatible: Maximize compatibility with current and future user agents, including assistive technologies.
Understanding Levels of Conformance
What is conformance?
Conformance means meeting the accessibility requirement as per a given success criterion. WCAG 2.0 guidelines have three levels of conformance:
- Level A: This is the most minimum level of conformance. The easiest and the most basic requirement
- Level AA: Mid-level. For a web page to be level AA compliant, a web page has to be meet both levels A and AA requirements
- Level AAA: This is the most difficult level. In order for a site to be triple-A compliant, a site has to meet all compliance levels
In Microsoft’s case; at the beginning, they introduced their own accessibility standards as per WCAG 2.0 Level AA. At the most minimum level, all products, applications, websites must meet both Level A and Level AA of WCAG 2.0 that folks at Microsoft collectively called Microsoft Accessibility Standards (MAS) to help Microsoft teams to adapt and implement accessibility into their ecosystem. Over the course of time, MAS has been updated to include WCAG 2.1 guidelines as well.
What is normative or non-normative?
Normative: Any guideline that must be met in order for a site to be compliant. Required for conformance.
Non-normative or informative: Any guideline that doesn’t need to be met. Not required for conformance.
EVALUATION
There are several automated tools publicly available to check accessibility issues on your site. However, they are not 100%. Human testers are required to ensure that a site is fully accessible. Having said that, to kick things off we utilized quite a number of automated tools to give us a foundation to start with. They are given below:
- Keros for web/Keros for Chrome: This is Microsoft’s internal tool. Only available to internal Microsoft employees. This was a great tool to kick things off with. We had two accessibility projects running simultaneously. One dealt with the overall site experience, another was page specific. Not only did Keros help us to give a peek at some of the common issues around accessibility on our site but it was also able to scan each page and keep a digital record of all the issues that needed to be fixed. Each scan could be a scenario based scan with the ability to add comments. Not all features were used heavily, nonetheless was still useful when needed. The very first prototype of Keros was developed for Chrome, Microsoft recently released a version that can be run on Edge as well.
- Webaim: Webaim was more expansive compared to Keros. Webaim shows a wide variety of issues such as heading error, aria-label, roles errors, that Keros may not capture. But having said that, most of the automated tools capture only 20-30% of the overall issue. For the most comprehensive testing, human involvement is a must.
- Webaim Color Contrast Checker: This is Webaim’s extension for color. We used this extensively to check color combinations across the site.
PROCESS BRIEF
The best way to build a site is to embrace accessibility right from the beginning. As mentioned above, accessibility overlaps with other best practices such as usability. In our case, however, we didn’t have the luxury to rebuild the site due to the limitation of the budget. We had to take it one step at a time and address as many issues as possible for compliance. As a site owner and maintainer, it was our responsibility to keep the site running and also continue working on fixing the accessibility issues. Our responsibilities lied in understanding the issues, knowing the areas that needed to be worked on, the rules that needed to be applied, different pieces of information that came in through and how those related together.
The analysis took a huge chunk of time. Post-analysis; we drew business requirements that paved the way for technical requirements. In terms of design, we based it around our original design sketch, improving the existing design. After the requirements were submitted to the IT department, developers started the process. We took each step with one sprint at a time. Each sprint lasted for 3-4 weeks. Any requirements that the dev team weren’t able to address would be part of the backlog. Prior to the end of the sprint, user acceptance testing was another responsibility we had to fulfill. Each non-technical testers tested the user journey based on various test scenarios. Post-deployment, there would be proper testing by the official accessibility testers who once again go through various scenarios to determine if our web portals were good enough to achieve the initial MAS standard.
RELEASE
We followed the agile method where all team members worked concurrently and deployed at the end of each sprint. Anything that couldn’t be fixed would be part of the backlog. The very first release dealt with fixing the color contrast issue. We decided to go with color changes first and foremost because it was the easiest changes of all. It was a matter of making CSS updates, where we didn’t have to engage with interactive elements. By simply updating the foreground color against the background color – we were making our sites accessible to all users with the color vision issue.
In three different sprints, we made the following changes in terms of the overall site experience:
- Fixed the color contrast issues (when the foreground text color and background color doesn’t have enough contrast to make the text distinguishable enough) of all the affected areas by providing enough contrast between content and background for both normal and large texts.
- Made all clickable elements visually distinguishable on mouse hover and keyboard focus by customizing the visual focus indicator for various elements across all web portals, with an intention to make the site navigable via the keyboard as well as mouse.
- Ensured that keyboard navigation was logical in order. There was no hidden cursor.
- Ensured the site content is visible in high contrast mode.
LEARNINGS
One of the biggest learnings for all of us in the team has been looking at every web page from the standpoint of accessibility. Whenever we are creating or updating a web page, it has made us aware of the responsibilities we have towards all users. Whether a user is abled or disabled, it is our duty to make web content accessible to everyone. When we post content, we don’t just post anymore, we actively maintain the quality of the HTML code, we ensure that links have a descriptive purpose, the images have correct alternative text. These may seem like simple things, but have a huge effect on how users perceive, understand, and interact with our content.
During this process, we realized there were a considerable number of mistakes we were making across our web portals such as, not following the heading rules to structure lengthy pages, incorrectly coding the tables. Some of the most commons errors we were making are given below:
Headings:
In terms of the page or homepage level, one of the biggest errors we were making was breaking the heading rule. Text that does not act as a heading visually or structurally should not be marked as a heading. Screen readers ignore font size or font weight of the text, hence, a user with visual impairments cannot tell if a heading is a heading unless there is a proper heading element association.
Recommended: H1 for the page title, H2 for major headings and H3 for major subheadings.
The most important heading has the rank 1 (<h1>), least important heading rank 6 (<h6>).
Skipping heading ranks can be confusing and should be avoided where possible. For instance, from <h2> you cannot jump to <h4>. It has to be in proper order.
Incorrect way:
<h1>Introduction to Web Accessibility</h1>
<h4>Add text here…</h4>
<h6>Background</h6>
<h4>Add text here…</h4>
<h2>Evaluation</h2>
<h4>Add text here…</h4>
Correct way:
<h1>Introduction to Web Accessibility</h1>
<p>Add text here….</p>
<h2>Background</h2>
<p>Add text here…</p>
<h2>Evaluation</h2>
<p>Add text here.</p>
Links:
With every link, it is pertinent that we describe the purpose of the link. We had a lot of pages that said ‘Click here to learn more’ and the ‘here’ was hyperlinked. This is a no-no from an accessibility standpoint. Instead, you can hyperlink the entire context such as: Learn more about web accessibility. You can also add an additional description to your link through Title attribute.
Invalid Empty Tags
Turns out empty tags can confuse screen readers. When we cleaned the overall markup errors of a page, we also ensured to get rid of empty tags.
Empty tags: <p></p>
Non-empty tags: <p>Hello there!</p>
My intention with this blog post is to give you a glimpse of the overall process. This has all been a great learning experience for the whole team, full of trial and error. Although I have tried to outline as many details as possible in terms of the actual steps we took. Most of it is still presented in a very generic format. I’m sure there are things that I have missed out. I’m sure there were gaps in the process. Nonetheless, just a few months ago, we were at a zero position and fast forward today we have made significant progress on our site.
Accessibility related technology is improving every day. Even WCAG guidelines are updated to reflect better methods. At some point, this post may become obsolete but will do all I can to continue to update. If you have any questions about the process or about web accessibility please don’t hesitate to drop a comment. I’ll do my best to answer your questions.
