Address accessibility best-practices

[Gumnos]

The current best-practices list doesn't seem to mention anything regarding accessibility so I'm opening this mostly as a generic place-holder. There are a number of accessibility issues that could be addressed based on the type of program. At a minimum, I'd want to see something along the lines of "Accessibility best-practices SHOULD be followed" with suggestions on where to find such accessibility information.

Web tools have one set of best-practices while GUI applications tend to be environment-specific (such as Gnome, KDE, XFCE, Android, iOS, Mac, and Windows ). Most command-line applications are fairly accessible out of the box, while some TUI applications (e.g. ncurses programs) can do certain things to make themselves more accessible (such as alpine's force-arrow-cursor setting).

[david-a-wheeler]

The best practices criteria have focused on practices that tend to improve security directly, or improve quality in a way that would also increase security. So adding accessibility would be a change in scope.

That said, I think this could be a very good idea. Clearly improving accessibility would be an excellent thing. Does anyone else have thoughts? How could we turn this into something specific and actionable?

[Gumnos]

The best practices criteria have focused on practices that tend to improve security directly, or improve quality in a way that would also increase security. So adding accessibility would be a change in scope.

From the criteria

These best practices have been created to:

-    encourage projects to follow best practices,

-    help new projects discover what those practices are, and

-    help users know which projects are following best practices (so users can prefer such projects).

Nothing in here limits the scope to security-focused best-practices. I'd posit that, as long as the scope is "Best Practices", then accessibility SHOULD (or even MUST) be included. Rather, if the focus/scope was merely security or practices that indirectly improve security, then the project should rename to something like "Best Security Practices (and their supporting practices)".

I don't intend to come across as too snarky (okay, I'm kinda snarky by nature, so it's bound to have a little latent snark 😉 ), and I'm glad you're amenable to including accessibility. As for some semi-actionable items to kick around, perhaps a couple of the following to start:

• A GUI or web-based project SHOULD test with at least one screen-reader on the target platform(s) (e.g. NVDA, Jaws, or WindowEyes on Windows; VoiceOver on Mac & iOS; Orca on Linux/BSD; TalkBack on Android). TUI programs MAY work to reduce overdraw to prevent redundant reading by screen-readers.
• Neither color nor sound SHOULD be used as the only way information is conveyed
• Color combinations SHOULD be tested in a high-contrast environment
• If the software uses flashing or animation it SHOULD grant the user control to disable it.
• All applications SHOULD be tested for keyboard-only navigation

I'm sure that's nowhere near a complete list, and there's certainly room for improvement, but it at least gives some ideas to discuss.

[david-a-wheeler]

I think programs that interact directly with users have a different set of requirements than programs which don't. Programs like mobile applications or web applications would have many requirements that would make no sense for a program library. We need to separate those somehow.

Most accessibility info I've found is really in the form of guidance, not hard requirements.

A very nice place to start is the Open Office accessibility work here: https://www.openoffice.org/ui/accessibility/ Open Office isn't a very active project these days, but I remember this as being really good work at the time.

[Gumnos]

Just checking in to see if any progress has been made regarding accessibility best-practice criteria.

[david-a-wheeler]

Not yet. Projects have had surprising difficulty reaching just this initial passing level. That's not to say no one has done it, people certainly have, but we've been focusing on getting project started. Each criterion individually is done by many projects, but when you combine criteria it can be harder for a project to meet all of them.

[david-a-wheeler]

We've added accessibility as a draft requirement in the upcoming passing+1 level, using the material here. I'm sure it needs improvement, but we'll do that as a separate issue.

Thanks so much!!

[Gumnos]

no, thank you!

As an aside, is there a branch or set of commits where I can see these "upcoming passing+1 level" changes?

[jdossett]

You can check out our current working list of proposed higher level criteria at

https://github.com/linuxfoundation/cii-best-practices-badge/blob/master/doc/other.md