Making Shiny apps accessible for all humans

rmarkdown
shiny

#1

Are there any packages, resources or best practices for increasing the accessibility of Shiny apps in particular?

I mean 'accessibility' in terms of removing barriers for users with low vision, are deaf, have physical or motor disabitlities, use screen readers, etc.

This is related to an accessibility workshop for digital services at Sprint 18, a recent UK government event.


#2

As an overview on how I got into area of web design is that I'm currently working on a project where we are using shiny as a qualitative assessment tool to measure the attitudes towards unwanted side effects in interventional trials.

The Front End Checklist was a great starting point for learning about front end and for web accessibility. There are many aspects of web accessible design and I'll try to provide a glimpse into this area by highlighting: the Web Content Accessibility Guidelines (WCAG), Color, and Fonts.

Web Content Accessibility Guidelines

In the front end checklist, the accessible section provides some fantastic tips and resources for ensuring pages are Web Content Accessibility Guidelines (WCAG) compliant. There are different levels of criteria. If I read it correctly, the highest level (WCAG 2AAA) is typically used for goverment level projects whereas WCAG-2AA is considered as the "default".

There are several sites that run compliance checks, but I'm always weary of uploading projects to a server. The koa11y app is a nice offline alternative. This app plays nicely with shiny apps. Simply fire up your shiny app, copy address (e.g., 127.0.0.1:...) into the app, and then run the report. Errors are split into three categories (errors, warnings, and issues). Each problem provides a summary of the error, a print out of the code, and may provide some information on what/how to fix. The nice thing about the report is that it tells you when colors are too close together and returns the color value that would meet WCAG criteria (which brings me to the next section).

Color

colorbrewer.org is a popular site for choosing color blind safe palettes for your graphics. The RColorBrewer package makes interacting with palettes much easier than manually typing color values. The one drawback is that the available color palettes are limited and this may not meet your project's needs if you have organizational design/branding guidelines to follow. The coolors.co/app is a good alternative as it has an endless library of color schemes and many filters for type of color blindness (e.g., protanopia, deuteranopia, etc.). And yes, an iOS app is available (for when your morning commute isn't nerdy enough).

While writing this reply, I remembered this tweet on the colorspace package.

I haven't used it yet, but it seems promising!

Fonts

myfonts.com might be a good option for finding an appropriate font. The downside is that loading another external dependency and this will hurt startup time and potentially disrupt the layout as the content renders. Native fonts are always are good option mozilla.org/.../font-family.

Other Resources

The site dev.to and css-tricks.com are good resources for learning about current developments in the web dev world. There you will find specific techniques for web accessibility and case examples. I'm having trouble finding the post, but there was an entire post on setting the perfect line height.

I hope that provides a starting point. I'll add more information and links as I look through my bookmarks.

PS: Thanks for sharing the links for the accessibility workshop. I've been looking for the design guides for days!

Sources


#3

Many thanks @dcruvolo, you've provided a lot of ideas there. :+1:

I didn't know about the Front End Checklist and koa11y seems an excellent way to assess accessibility issues.

Color seems to be overlooked often, but seems relatively simple to fix. Writing in plain English is another example. From my perspective, the UK government's website has a useful blog about writing in plain English and some guidance for writing for our web audience.


#4

A few more thoughts -

I came across the A11Y project (https://a11yproject.com/) today. This is well-curated site on web accessibility. There are many how to guides, checklists, tools, etc. The resources page is an amazing list for software, books, blogs, courses and much more. I would start here.

Wording is the hardest part (I focused on design in the first reply). Having people outside my research area review content helped a lot. Running a focus group might help work out unforeseen issues.

The NHS Digital Apps Library (https://apps.beta.nhs.uk/) was a good resource during the building phase (I had links between a University and NHS trust). This might help to give you an idea on design and wording (even if your project doesn't focus on clinical research or practice). Each app is graded to make sure...

"It meets NHS quality standards for clinical effectiveness, safety, usability and accessibility, and has evidence to support its use."

Each app has a few screenshots and a short description on how it works. Some have live demos or video demonstrations.

Hope that helps!


#5

Ah great, I'll be pointing colleagues to the A11Y site. I don't know where you're based, but there's an a11ylondon group organised by Alistair Duggin, who gave the talk that inspired my post.

Thanks for all your tips :clap: