Other Digital Accessibility Considerations

Branding

When considering branding elements for an organization, there are a few accessibility considerations to keep in mind.

Use of colour: Using the WCAG guidelines for colour use, ensure sufficient contrast between text colours, and the background colour they may appear over. At a minimum, use standard 10- to 12-point fonts and provide a contrast ratio of 4.5:1 or greater.

Fonts: There are font characteristics that make fonts more or less legible, thus, more or less readable. “Fancy” fonts like Comic Sans for instance, can take longer to recognize, and this affects reading speed. This effect can be magnified for those with a print impairment.

Images with Text: While sometimes it is unavoidable, images of text should be used sparingly or avoided altogether. Text in images tends to degrade when magnified by those with low vision, making it difficult to read. For those who are blind and using a screen reader, text in images cannot be read at all. The text of a logo is an exception, but, if you also include a company motto as part of the logo, for instance, consider adding it as actual text next to the logo, rather than making it part of the logo image itself.

Coding

You might be surprised to know that there are quite a few blind or low-vision computer programmers. The way they code is much like any other coder does. Though code itself is not typically accessible or inaccessible. Good coding practices, such as effective use of space and effective commenting, can make code more usable for both sighted and blind coders.

Communication

Many of the guidelines for creating accessible web content and documents also apply to communication. Where paper documents are distributed, be sure an electronic version is also available, making sure headings are properly used to structure topics, and describe in text form any visual elements in the communication.

Email can also be a major form of communication, both for promotional purposes and for personal communications. Emails can be created as plain text, rich text, or HTML. While plain text will generally be accessible, it can lack structural elements, which may be important for longer emails. Rich text and HTML can be marked up with headings, lists, alt text for images, and so on, to make them more accessible. Although there may be readers who display emails as plain text, in which case these formatted emails can be difficult to understand. For a typical personal email communication, plain text is usually fine. Where formatted text is used, it is advisable to also provide a plain text version as a fallback.

For more about accessible email, see the following optional readings.

Text chat is also becoming a more common form of communication, often used by customers to contact support services through a real-time chat application linked from a website. These applications can often be inaccessible to blind users if they have not been developed with consideration for accessibility. The primary considerations when choosing a synchronous web-based chat application include:

• Properly implemented WAI-ARIA Live Region support
• Ability to pause new messages
• Access to a log of chat messages
• Keyboard access throughout the application
• An audio indicator when new messages are posted
• A visual indicator when new messages are posted
• Easy shortcut navigation between the message input field, the chat stream, and the connected users list (if applicable)

For more information on what makes a chat application accessible, as well as ratings for many popular chat applications (as of 2013), see the following Readings & References. Though the focus in the article is on chats used in education, it is relevant for other chat usage scenarios.

Service Equality versus Compliance

Though all services should ideally be accessible to anyone who attempts to access them, there may be occasions when it is just not possible to provide full access for everyone. Chats are one example where there may be unavoidable barriers, mainly because most of the available chat applications have room for accessibility improvements. That said, though, chat accessibility is improving.

Another good example of a technology that remains a challenge to access for some people with disabilities is videoconferencing systems. Though there have been efforts made by developers to improve the accessibility of these technologies, the currently available systems are generally difficult to use, are only partially usable, or are not usable at all with assistive technologies.

In cases such as these, all efforts should be made to procure the most accessible technology you can find, but with the understanding that they may not be accessible to everyone given the state of the art for these technologies. This is not to say organizations should not use them, but instead where they are used, acknowledgement should be provided about the limited access available, and provide an alternative where possible.

Similarly, primary service-delivery methods should be made accessible first, rather than resorting to providing alternative means of accessing these services for those with disabilities. For instance, do not create a website that is inaccessible because your organization wants to make use of some compelling, inaccessible technology, then create an alternative site for those accessing with assistive technology as a means of complying with regulated accessibility requirements. Despite best intentions, maintenance and upkeep of alternative sites are likely to fall behind that of the primary site. In general, the practice of providing alternative websites is frowned upon, except in cases where it is unavoidable because the technology being used is not yet available in an accessible form.