devinprater / ui-ux-accessibility

A repository for standardized documentation on accessibility, originally for people who are blind, of digital interfaces and experiences.

UI/UX Accessibility

This repository is for the documenting of UI and UX accessibility patterns that can be used by developers, testers, and auditors for determining the accessibility of an operating system desktop or “shell”, programs running atop a desktop, web pages, or other frontend experience.

Contents

• UEFI Systems
• Operating Systems
• Desktop Environments
• Applications
• Webpages
• Documents

Contributing and Contacting

This repository will not reach its full potential without contributions from other people with disabilities, programmers, and other invested people. So, you can either fork the repository, make changes, and send pull requests, ask to be added as a contributor (if you plan on contributing heavily), or send requested changes via e-mail or other communication channels. Just please send the changes through a channel that supports long, multi-line messages.

My contact info is below:

Email

[email protected]

Twitter

@devinprater

Mastodon

[email protected]

ui-ux-accessibility's Issues

Suggestion for new category/resource

I don't have the bandwidth to create a full PR for this right now, but one useful suggestion:

@mwcampbell recently began work on AccessKit, a library/toolkit for integrating UI toolkits with platform-specific accessibility APIs. So, in theory, developers can integrate their bespoke hand-drawn UIs, or non-standard third-party UI toolkits, with platform-native APIs just about everywhere.

Not sure where this would belong. It isn't quite an application, desktop environment, etc. Thoughts? And it's still early days, but seems like a good addition to a list like this one.

Best practices for command line applications?

There is a paper called Accessibility of Command Line Interfaces. The conclusions I took from it are:

• Add an option to output tabular data as HTML tables or comma separated values (CSV).
• Add an option to output long output as HTML, with headings and other semantic elements where appropriate.
• Describe how the output is structured so that users have the ability to use utilities like grep to only get what they need.
• When a command runs for a long time without outputting anything, output status messages. But no progress bars or spinners.
• Don't use ASCII-art.
• Ensure that an HTML version of all documentation is available. man pages do not work.

Questions

• Are the conclusions correct?
• How often should status messages appear?
• Can I erase the last status message to print the new one at the same place or is it better to just print a new line?
• When I make a pull request, should I put it in “Application Accessibility” or in its own file?