Accessibility subsite in Design documentation

[jancborchardt]

Accessibility

We track all issues and enhancements regarding accessibility with the feature: accessibility label. They are also all part of the design label.

The posters on dos and don'ts on designing for accessibility are a great summary. Print out the PDF and hang them up. :)

Screenreader accessibility

• Images should always have an alt attribute describing their function, like alt="App menu" (don’t forget the translations). If the image is purely for decoration, use alt="". See more tips for alt text.
• Form fields should always have a corresponding label.
• To make sure everything works well with a screenreader, best test it yourself: NVDA for Windows, VoiceOver for macOS, Universal Access in GNOME, TalkBack for Android or VoiceOver for iOS
• If you regularly use a screen reader and there are any problems, don’t hesitate to open an issue :)

Keyboard navigation

• It should be easy to visually determine the element with keyboard focus. To test, simply use Tab ↹ and make sure all elements are highlighted. Whenever you use :hover in your CSS, also include :focus and :active.
• All elements that can be interacted with via a mouse click should also be possible to interact with via pressing Enter ↵.
• Also see: Quick Test: Navigate using just your keyboard

Contrast and legibility

• Make sure the text color to background passes WCAG AA recommendation (ideally AAA). You can check it using the WebAIM color contrast checker
• Also see: Quick Test: Check contrast with your mobile device

Comprehension

• Write in simple and understandable language.
• Don’t use technical jargon which needs prior knowledge. (Like 404 Error, or Couldn’t set variable X) You can do that in the console to help debugging, but don’t show it in the interface.
• Check your written text using comprehension check tools.

Testing tools

We use various tools for testing like:

• WAVE browser extensions
• aXe browser extensions
• Firefox accessibility inspector
• Lighthouse for audits of performance, accessibility, and more
• Web Accessibility Checklist

Recommended reading

• The Accessibility Project
• Mozilla Developer Network docs on accessibility
• WebAIM articles and resources

@nextcloud/accessibility @nextcloud/designers @MarcoZehe @tyrylu @skjnldsv @kevgathuku @juliushaertl what are additional points we should list? :) I’m wondering how much general accessibility info we should list or rather link to.

[tyrylu]

Good question. I have noticed, at least in my daily web usage, that correctly used ARIA roles can also help a lot and can make some on first look too complex interactions perfectly usable.
I think that the existence of ARIA should at least be mentioned.

[jancborchardt]

@tyrylu yes of course! :) I wanted to add ARIA too, but a quick glance at the MDN docs only had a site with the role names without explanation. Do you know a good site to link?

[tyrylu]

Unfortunately, i looked, but did not find anything terribly useful as well.

[juliusknorr]

I would probably link to https://www.w3.org/WAI/tutorials/ which gives a nice overview about the techniques related to the use in web applications. For ARIA maybe just use https://www.w3.org/TR/html-aria/

[kevgathuku]

For ARIA, I found this to be a good introduction:
https://developers.google.com/web/fundamentals/accessibility/semantics-aria/

Also the WAI-ARIA Authoring Practices seems to be a good starting point
It's full of examples and here's the page's purpose:

It provides guidance on the appropriate application of WAI-ARIA, describes recommended WAI-ARIA usage patterns, and explains concepts behind them.

[skjnldsv]

@MariusBluem can you help on this documentation? :)
You're the big doc master! ;)

[MariusBluem]

@skjnldsv Let me read some background info ... I‘ll start soon :)

[jancborchardt]

The WAI-ARIA page on MDN is also pretty nice: https://developer.mozilla.org/en-US/docs/Learn/Accessibility/WAI-ARIA_basics