Many companies list “Accessibility” or “ADA-compliant” in their RFPs (Request for Proposals) for intranets and other portal-type solutions. Is SharePoint Online ADA-compliant? Does it meet all accessibility standards and requirements?

Although SharePoint Online is constantly improving its accessibility features, not everything is covered. Just looking through Microsoft’s conformance reports for SharePoint Online is enough to make your head spin. Search for “SharePoint Online” on Microsoft’s  Accessibility Conformance Reports site to see for yourself.

Accessibility is a complex and multifaceted issue and how deep down the rabbit hole a company wants to venture depends on the company. The best way to ensure that your accessibility needs are being met is to test the various use cases you are interested in – preferably with a variety of users who need the features.

SharePoint accessibility challenges

We recently teamed up with Helen Keller Services to build their intranet and test accessibility use cases, particularly for keyboard-only and screen reader users. Here are just some of the challenges we came across:

Custom Hub and Site Menus

SharePoint’s Hub and Site menus are not implemented in a way that is intuitive for keyboard-only users. Tab ↹ is used to navigate the page elements, but once a Hub or Site menu is selected, the user must switch to the arrow keys to navigate.

Page Headings

By default, the page title in SharePoint Online is aria-level 2, the same level used by the title text for web parts on the page. This can cause confusion for users with screen readers as it is difficult to discern the page heading from the sub-headings. Also, some web parts do not implement the aria-level element, which leads to further confusion.

Permalink Aria-Labels

For some link types, SharePoint will use the text “Permalink for” at the beginning of aria-labels. It can become cumbersome for users with screen readers as the reader will keep repeating “Permalink for” as it navigates through the page.

People Web Part

When using a screen reader and keyboard, navigating over people shown in the People web part, the aria-labels instruct users to “Press enter to open details for this person,” which does not work. The correct procedure is to press the down arrow ↓, and then enter to view details.

Page Anchors

To improve site performance, SharePoint will sometimes not load content on a page until the user scrolls down far enough to see the content. Some elements on the page will have anchor links (href elements starting with “#”), which screen readers will announce at the top of the page to allow users to know what content is available. This can cause confusion as users are not informed of content that has not yet loaded, and therefore they will not know it exists unless they tab through the page.

Document Library Web Part

When using a screen reader, the Document Library web part does not distinguish between files and folders. This leaves the user guessing as to what they are selecting.

In many cases, we were able to use SPFx to obtain the desired behaviors, while in other cases, the issue was dealt with business process modifications. Without detailed testing, many of these issues would have been overlooked and have negatively impacted the user experience.

Resources to help you improve SharePoint accessibility

Accessibility is a big and important topic! Here are some helpful links to you learn more:

Thanks to our readers for sharing that last link – lots of useful information!

And a big THANK YOU to Helen Keller Services for the opportunity to work together to build their accessible intranet experience!

Looking to build your intranet and ensure accessibility?  Let’s talk!