Composer This topic is related to Transact Composer. | Form Builder | v4.3 & Higher This feature is related to v4.3 and higher.
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:
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.
Are we confident to state that they will be WCAG v2 AA compliant for forms created in Composer?
No. We will never be able to certify that. But we can make it as easy as possible to achieve AA.
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 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.