Accessibility/inclusivity

[aral]

Let’s discuss #49 here as it is not simply about adding some text to the Human Interface Guidelines.

elementary OS must embrace accessibility and inclusivity as a core tenet if it is to have any meaning. Given that in real-terms that means a huge amount of time investment in learning and implementation across nearly every facet of the project, we should have a chat about it here to see if the will exists to do take this on to begin with.

It will mean, for example:

• Deciding on Accessibility best practices.
• Documenting those best practices in the Human Interface Guidelines.
• Implementing those best practices in internal frameworks like Granite.
• Implementing those best practices in OS components like the task switcher, etc.
• Implementing those best practices in the apps that ship in the operating system.
• Encouraging third-party developers to implement accessibility as part of their development process and eventually including it as a requirement in the app review process (so that in accessibly applications are not accepted as curated applications)
• Investing in ensuring that the Screen Reader and other assistive technologies are first-class citizens of the operating system (e.g., launching the Orca preferences is an entirely hidden gesture at the moment as far as I can see and the preferences window doesn’t integrate with the look and feel of the OS, making it look neglected).

Thoughts?

[dar5hak]

Tagging @annaecookux and @techdev5521 for their valuable inputs. Their talks offered a lot of insight into this matter.

[techdev5521]

Thanks @dar5hak !

[techdev5521]

@aral You're preaching to the proverbial choir -- I whole heartedly agree with you. Any solution must be a full stack solution complete with automated check (ex: this button doesn't have a screen reader label.)

While I agree with you, I haven't the experience with desktop application development to point to successful examples or suggest existing best practices. However, my two cents at this point includes:

Start from the user experience -- not the technology. Any experience should begin with a user interaction first and have a technology to support that later. If we go the other way its far too easy to limit outselves to existing tools and force the user to work the way software does. To help with this user experience first thinking, consider the following scenarios for every workflow:

• How does this work with your monitor turned off? (No vision.)
• How does this work with your monitor twice as far away? (Low vision.)
• How does this work with no mouse? (Limited mobility.)
• How does this work in a coffee shop? (No/limited sound.)

Make it easy for uninhibited developers. Developers are largely uninhibited people without the lived experience to know how to make a11y experiences better because they don't need them. Because of this, the software solutions should allow for easy reminders for how to do so. This could potetially include:

• In-editor or compile time warnings when a11y related properties are not found like with web languages.
• Documentation with examples including a11y related properties.

I'm sure there's more to consider here and I would love to be part of the conversation. Looking forward to others feedback.

[rdebeasi]

+1 to including accessibility standards in the Human Interface Guidelines.

It sounds like the team does embrace accessibility and inclusivity. From Accessibility Features Are Just Features:

We will continue to reorganize and refine settings and preferences, consider accessibility in our standard experience, and do our best to design a computing experience that is usable by all.

That said, there's still a lot of work to be done. "Curb cuts" like the ones described in that post are versatile and useful, but they don't solve every problem. Sometimes the user needs an automatic door, or an elevator, or braille signage. It sounds like that's where elementary OS falls short today: there hasn't been much focus on the experience for folks who use screen readers and similar assistive technologies.

The good news is that the GTK team recently modernized their accessibility API, borrowing ideas from the W3C accessibility standards and laying the foundation for automated accessibility testing. See Accessibility in GTK 4. Wouldn't it be cool if Houston included automated accessibility tests?

I look at the problem in terms of questions like these:

• How might we celebrate the progress that's been made so far?
• How might we focus on assistive technologies as the "next level" of accessibility efforts?
• How might we make it easy for application developers to follow accessibility standards?

I'm not a GTK developer myself, but I've done accessibility work on the web. Let me know if I can help! 😄