Tutorial on good accessibility practices and implementations

[zeebok]

Problem

I am reading 8.0 release blog post again and the section on the accessibility updates for those whom are blind or hard of sight made me realize that I am not totally familiar of what the best practices are or even what all of the possible accessibility features in GTK I could make use of when making/updating an app.

Proposal

It would be really great if the HIG and code docs had some sections on how to best support a11y in principle and implemention

Prior Art (Optional)

No response

[danirabbit]

Yeah we should definitely cover at least:

Keyboard navigation:

• Make sure not to turn off focus ability for activatable widgets. I see people a lot turning off focus for buttons which means they can't be accessed at all via keyboard.
• default activatable widgets in a view. So if you press enter in a text view it activates the correct action in a form for example

Screen reader A11y:

• mnemonic widgets. Associates a widget with its label so that for example if you focus a Gtk.Switch the screen reader reads its label
• accessible roles. If you for example have an activatable list row that opens a link you can set the accessible role as "link" instead of "row". If you have a sidebar with a list box that's acting as navigation the rows should have an accessible role of "tab"
• accessible titles. If you have a focusable widget that doesn't have a label you should still give it a title.
• accessible descriptions. If you have a widget that has both a title and description text like a switch or a view or a list row this will make the screen reader read the text like title → widget → description
• image buttons need a tooltip. The screen reader will read this as the button label

[zeebok]

I assume if a dev uses the elementary SDK other hard-of-sight helpers (color blind filters, high contrast, fonts, etc) are automatically applied to the app?