This document is supposed to explain basics about accessibility issues and give guidelines for contributions to OTRS.
What is Accessibility?¶
Accessibility is a general term used to describe the degree to which a product, device, service or environment is accessible by as many people as possible. Accessibility can be viewed as the ability to access and possible benefit of some system or entity. Accessibility is often used to focus on people with disabilities and their right of access to entities, often through use of assistive technology.
In the context of web development, accessibility has a focus on enabling people with impairments full access to web interfaces. For example, this group of people can include partially visually impaired or completely blind people. While the former can still partially use the GUI, the latter have to completely rely on assistive technologies such as software which reads the screen to them (screen readers).
Why is it important for OTRS?¶
To enable impaired users access to OTRS systems is a valid goal in itself. It shows respect.
Furthermore, fulfilling accessibility standards is becoming increasingly important in the public sector (government institutions) and large companies, which both belong to the target markets of OTRS.
How can I successfully work on accessibility issues even if I am not disabled?¶
This is very simple. Pretend to be blind.
- Don’t use the mouse.
- Don’t look at the screen.
Then try to use OTRS with the help of a screen reader and your keyboard only. This should give you an idea of how it will feel for a blind person.
Ok, but I don’t have a screen reader!¶
While commercial screen readers such as JAWS (perhaps the best known one) can be extremely expensive, there are open source screen readers which you can install and use:
Now you don’t have an excuse any more. ;)
This section is included for reference only, you do not have to study the standards themselves to be able to work on accessibility issues in OTRS. We’ll try to extract the relevant guidelines in this document.
Web Content Accessibility Guidelines (WCAG)¶
This W3C standard gives general guidelines for how to create accessible web pages.
WCAG has different levels of accessibility support. We currently plan to support level A, as AA and AAA deal with matters that seem not relevant for OTRS.
Accessible Rich Internet Applications (WAI-ARIA) 1.0¶
This standard deals with the special issues arising from the shift away from static content to dynamic web applications. It deals with questions like how a user can be notified of changes in the user interface resulting from AJAX requests, for example.
Provide alternatives for non-text content¶
Goal: All non-text content that is presented to the user has a text alternative that serves the equivalent purpose. (WCAG 1.1.1)
It is very important to understand that screen readers can only present textual information and available metadata to the user. To give you an example, whenever a screen reader sees
<a href="#" class="CloseLink"></a>, it can only read link to the user, but not the target of this link. With a slight improvement, it would be accessible:
<a href="#" class="CloseLink" title="Close this widget"></a>. In this case the user would hear link close this widget, voila!
It is important to always formulate the text in a most speaking way. Just imagine it is the only information that you have. Will it help you? Can you understand its purpose just by hearing it?
Please follow these rules when working on OTRS:
- Rule: Wherever possible, use speaking texts and formulate in real, understandable and precise sentences. Close this widget is much better than Close, because the latter is redundant.
- Rule: Links always must have either text content that is spoken by the screen reader (
<a href="#" >Delete this entry</a>), or a
<a href="#" title="Close this widget"></a>).
- Rule: Images must always have an alternative text that can be read to the user (
<img src="house.png" alt="Image of a house" />).
Make interaction possible¶
Goal: Allow the user to perform all interactions just by using the keyboard.
onclick event listener, but it should be (or contain) an
a tag to make it clear to the screen reader that this element can cause interaction.
- Rule: For interactions, always use elements that can receive focus, such as
- Rule: Make sure that the user can always identify the nature of the interaction (see rules about non-textual content and labelling of form elements).
Goal: Make dynamic changes known to the user.
Rule: Always use the validation framework
OTRS.Validatefor form validation.
This will make sure that the error tooltips are being read by the screen reader. That way the blind user a) knows the item which has an error and b) get a text describing the error.
Rule: Use the function
OTRS.UI.Accessibility.AudibleAlert()to notify the user about other important UI changes.
Rule: Use the
OTRS.UI.Dialogframework to create modal dialogs. These are already optimized for accessibility.
General screen reader optimizations¶
Goal: Help screen readers with their work.
Rule: Each page must identify its own main language so that the screen reader can choose the right speech synthesis engine.