Usability & Accessibility

   Composer This topic is related to Transact Composer.  |   Form Builder |  v4.3 & Higher   This feature is related to v4.3 and higher.

General Statement

The W3C defines Accessibility as "Web accessibility means that people with disabilities can use the Web. More specifically, Web accessibility means that people with disabilities can perceive, understand, navigate, and interact with the Web... ". For more information, see http://www.w3.org/WAI/intro/accessibility.php/

Accessibility is challenging. Users with vision impairment, who depend on Screen Reader applications that read aloud the contents of a web page, have to be accommodated. Forms also must cater for partial visual impairment (such as color blindness or poor acuity), cognitive impairment, motor and auditory disabilities.

Composer does a number of things to assist compliance:

  • Composer generates many of the HTML tags that are required for correct accessibility. For example, all images are generated with an ALT tag so that blind users can have the image read out to them.
  • Composer test forms are verified by a number of accessibility test tools to ensure that the HTML Composer generates passes these tools' criteria.
  • Composer's use of stylesheets means that if your first form is accessible, then all subsequent forms are much more likely to be accessible.

However, while Composer tries to do as much as possible, it cannot absolutely verify that your forms are accessible. For example, while Composer will generate an ALT tag for your images, it cannot verify that the tag's text is actually a good description of the image.

Composer will apply consistent colors and styles, but it cannot verify the the contrast of your foreground text against your background color meets the criteria W3C criteria. For more information, see the full WCAG guidelines athttp://www.w3.org/TR/WCAG/

To summarize, the accessibility of your forms is ultimately your responsibility.

Our latest portals are largely WCAG compliant, but be aware that individual forms may not be. Some customizations can defeat WCAG compliance.

There is a misconception that the use of JavaScript in a web page makes the page inaccessible. This is completely incorrect. This comes from a perception many years ago, that certain operations in JavaScript confuse screen readers. However, modern screen readers handle JavaScript well, and in fact some JavaScript can make your forms easier for all users, including the disabled. The appropriate use of JavaScript is more of a positive for the disabled users — for example, hiding a section that isn't relevant means that the unsighted user will not have to tab through many irrelevant fields.

Temenos will aim to achieve 100% WCAG v2 AA compliance in TotalValidator, and 100% compliance in SiteMorse.
While we do pass automated tests, we also understand that there is a difference between passing tests and being truly accessible. Any additional or specific Accessibility requirements are not necessarily in scope but will be dealt with on a case by case basis.

FAQs

Question:

Are we confident to state that they will be WCAG v2 AA compliant for forms created in Composer?

Short Answer:

No. We will never be able to certify that. But we can make it as easy as possible to achieve AA.

Long answer:

Passing automated tests doesn't guarantee compliance (although it's a good start). Automated tests tell you when you've done something wrong, but they don't tell you when you've failed to do something right. We are in the process of doing further human expert tests on sample forms to improve our compliance.
Ask two different "experts" to certify a form, you can very often get two different answers – there is a level of subjectivity in interpreting WCAG. It also depends on the browser, and the screen reader.

Composer is just a tool. It helps you to build forms that work well, but it also allows you to do what you want. You could easily do things in your form, either intentionally or unintentionally, because of the way you build it, or the JavaScript you hand-craft, that breaks accessibility. We can NEVER certify that your forms will be accessible just because our tool starts from a good place. For example, you may put light grey text on a dark grey background and fail contrast requirements. Or name an image inappropriately. It's a bit like asking Microsoft to certify that all documents you produce will be spelled correctly just because Word has a spell checker.

Ultimately, meeting the needs of people with disabilities is about trying to do the right thing. Organizations will be attacked if they appear not to care. Being concerned, but making some mistakes, and learning from them is defensible. Picking the right tool is a good start. Doing some accessibility testing as part of your development process would further support your good intentions.
Ultimately, the only way you can be 100% sure that the forms you build are accessible is to get an accessibility expert to test them.

Tab Order

Tab Order is the order in which your cursor will navigate from one field to another when you press the Tab key. This is particularly important for users who touch-type, who want to avoid taking their hands off the keyboard and onto the mouse in order to move to the next field; and also for visually or physically impaired users, who favor the keyboard over the mouse.

In Composer, you don't have to set the tab order - Composer sets the tab order for you. There is nothing for you to do, and nothing for you to maintain. If you insert a new field, it will simply be added in the correct tab order relative to the fields around it.
If you need to explicitly control the order of tabbing, you can achieve some control by wrapping your fields in blocks. Tabbing will always occur from field to field within a block before moving to fields in subsequent blocks.