Accessibility has become a growing influence on design and UX today. Apps operate on more devices that are not a tablet or phone. This impacts services that physically-impaired and visually-impaired consumers use, as well as expands the application of assistive tech aids. 

Markup code elements in apps and websites influences the quality of accessibility features for physically- and visually-impaired users. When markup is planned with user experience in mind, accessibility needs can be addressed alongside analytics tags.

Here is an overview of how to best organize accessibility features and analytics so your website or app can provide the best digital experiences for everyone.

Where to Begin With Analytics and Accessibility

The reason analytics makes a great compliment to accessibility is because analytic and accessibility features can simultaneously be checked in a quality assurance (QA) evaluation of a page layout. Functions that appear in an app or website — links, buttons, etc. — can be examined for where analytic tags should fire as well as making sure you build in accessibility features.

The best place for understanding all the accessibility needs is the Web Content Accessibility Guidelines (WCAG). The WCAG is a set of design standards issued by the World Wide Web Consortium (W3C), the same collection of individuals and organizations that develops common web standards for HTML, CSS and other code in which developers use.

So, for a starting point, you can check for a page markup to contain Accessible Rich Internet Application (ARIA) labels. ARIA labels are attributes that describe HTML elements that are an image or icon to screen readers. They operate like alt tags, providing alternative text attributes so that search engines can gain a further contextual recognition for a query. 

The main difference is that a screen reader replaces the search engine's role. A screen reader is a software that renders text and images as audio speech or Braille for devices and software that people with visual impairments use. 

Thus, ARIA labels offer semantic attributes that a screen reader to scan. Screen readers read back the message to the user, confirming the webpage selection the user wanted. 

In this example from the Mozilla site, ARIA labels are added to a progress bar. These labels allow the user to know how a website process is taking.


Related Article: Web Accessibility Serves Everyone: Here's How to Get Started

ARIA Label Verification Complements Analytics Tags

ARIA label verification is a perfect complement for analytics tag verification since both will involve the same link or button.

ARIA guidelines are specified as separate instructions as part of the WCAG. A QA for a website page can ensure a button triggers, the right analytics measurement and the right ARIA label calls out a confirmation button for visually-impaired users.

Reviewing website or app markup leads into layout decisions where physical location and functionality are a concern. Take the size of a page button, for example. On-screen buttons are a touch target — they are what you contact in an app or click on a page. Having touch targets that are too small can be difficult for physically-impaired users to confirm a purchase or submit an online form. WCAG indicates 44 X 44 CSS pixels is a good rule thumb for a minimum button size.

Learning Opportunities

Another user interface detail to consider is how easily gestures can be completed. Because disabled users are not able to use a mouse, page functions should be operated through logical keyboard strokes. In our button example, you will want to know if the number of buttons can be streamlined so that gestures are not too numerous for physically impaired users.

Related Article: Building Accessible Digital Experiences Is About Doing the Right Thing

Using Analytics for Effective Accessibility Experiences

One way to organize how to implement accessibility featuring is using analytic reporting to determine what pages should be inspected first in a QA. Some pages in a sprawling website receive more traffic than others, be it from advertising or content that naturally attracts a given customer segment.

These high-traffic areas may be the best starting point in bringing accessibility features to a large website or app where a customer with assistance devices will likely arrive. Of course, a website will be completely updated, but it is vital to ensure the page relative to conducting a business transaction reflect accessibility concerns first.

In addition to page views, marketers should consider the session time taken on a page. No assumptions should be made on how long a page task or function should take. Session times measured in analytics can be compared against page content to determine if the average session times make sense for the task needed (An aside: Bounce rate can be a helpful comparison metric to sense if people are exiting a page too soon, but that metric has been eliminated from some of the latest analytics services). Developers must watch for automated page actions that changes page content too quickly for users to respond.

There are many more accessibility considerations, such as text size, color and font. A checklist helps. The A11y Project offers a checklist. Vetting analytics tagging tasks for a given page can be incorporated into accessibility checklists so that development needs are kept organized.

Gather the Most Useful Accessibility Tools

When developing a checklist, marketers should examine the tools that users with disabilities typically access. The most popular screen reader programs are JAWS for Windows, a third-party software for computers running Microsoft Windows and VoiceOver, a built-in visual accessibility feature of the Apple Mac OS. These programs come with training support material to help user learn how to configure the software.

Marketers can then help their developer teams through gathering the open-source tools that can implement accessibility features that interact with those tools. For example, Microsoft introduced Accessibility Insights, a suite of tools that allows developers and designers to incorporate accessibility features into their apps and websites. The suite includes Accessibility Insights Web, a browser extension for Edge and Google Chrome that highlights accessibility issues and make correction recommendations for a page that appears in the browser. Accessibility insights users can also download an accessibility kit for Window-based web apps and for Android apps.

Another accessibility verification suite is Axe, an accessibility search engine offered as a Chrome extension and as Axe React, a Nodejs package manager designed for React.JS web apps. The Axe browser extension scans a given webpage and returns a lists of accessibility issues discovered. Axe react incorporates similar functionality within app pages.

Given the broad application of software with many devices, accessibility has become a must-do essential in choosing design and functions for the customer experience. Combining an accessibility testing with analytics implementation will help marketers create the best customer experience for everyone.