Web accessibility is a huge topic, and this page attempts to highlight key development practices which can improve product accessibility and reduce expensive after-the-fact fixes without having to become an accessibility expert.

Please reach out early to the Product Accessibility Team for assistance in designing and evaluating new product UI.

For more on this topic, see the W3C accessibility site.

Use your product entirely via the keyboard. People who are blind, or have mobility issues, cannot effectively use a pointing device, and must operate the page using the keyboard (or input devices that behave like a keyboard).

No cheating, no grabbing the mouse just once as a shortcut or to scroll something into view. If you can't resist, disconnect the mouse or disable your trackpad. If you've never worked this way, some preliminary learning on navigating your operating system and browser without a mouse may be necessary.

On MacOS, you need to enable full keyboard support, otherwise the Tab key won't take you to all interactive controls. Do so via keyboard settings, as shown here:

If you are using Safari you must also enable it in Safari preferences:

Now try to do real world scenarios with your product from beginning to end, and ask these questions:

• Can I get keyboard focus to every interactive control (e.g. buttons, links, and so forth)?
• Can I operate the control ("click it") in a typical way via the keyboard?
• Can I see where keyboard focus is currently located?
• If I can't get focus to a control, is there are alternative way to operate this feature such as the Command Palette?
• Does the focus move in a logical order that matches the visual presentation? Top to bottom / left to right, as appropriate, when using tab key?
• Does keyboard focus get stuck anywhere? Typically a text editing control where tab key is used to indent. How does the keyboard user escape from that?
• Can I read everything? Can I move to scrolling content and view it all with standard keys?
• In all of the above: would I actually want to use the product if this is how I use my computer all the time? Did I have to hit tab key 75 times to reach something I'll need to use frequently, and so on?

Use a <button> for a button, an anchor for a link, headings as headings, and so on. Resist using a <div> for everything and relying on CSS to make it look like something it isn't. Semantic HTML brings a significant amount of automatic screen reader and keyboard support.

For complex concepts that don't have HTML equivalents (tab controls, menus, interactive grids), then use a framework that already does the right things for those components, or be prepared to work around or fix those frameworks (often very expensive).

If you have rolled your own custom controls, then you'll need to learn about ARIA, write keyboard event handlers, and perform a lot of extra testing on multiple browsers and screen readers.

Also, be sure to occasionally validate your HTML. Web browsers deal with poorly structured HTML as best they can when rendering, but bad HTML increases the chances of the browser misrepresenting your page when presenting it to accessibility tools like screen readers.

There are many browser plugsin that can scan a page and identify common accessiblity problems such as insufficient contrast, images without alt-text, misuse of headings and landmarks, and many others.

The Product Accessibility Team uses Axe Dev Tools Pro (paid) when doing audits; recommend that developers install and use the free version. https://www.deque.com/axe/

You could also use the built-in Lighthouse tool (Chrome), but it is just a rebranded (and generally older) copy of Axe Dev Tools, and we recommend using the standalone Axe tool for consistency and cross-browser support.

Full keyboard support and semantic HTML will actually take your product a long way towards being accessible to a much wider range of users. Here are some next-steps.

Moving forward, RStudio aspires to meet Web Content Accessibility Guidelines (WCAG) 2.1 AA level of accessibility compliance. We will eventually perform audits of our products against these guidelines and publish the results on rstudio.com (e.g. as VPATS). We don't expect to achieve 100% compliance, but want to honestly represent where we are at and strive to improve.

I don't recommend this for most people. Leave this to actual screen reader users or people who have devoted a significant amount of time to learning and maintaining screen reader skills. There is a big learning curve and a very high risk of failing to find real issues and flooding team with issues that wouldn't actually be a problem for people who use screen readers all day, every day.

The best thing to do here is identify and document the key scenarios of your product then have a screen reader user attempt to achieve those goals. That will quickly identify the highest-value problems to tackle. Then work your way down the list as time and resources permit.