Principles of accessibility

The following comes from the W3.org website, it explains the four principles of accessibility that the Web Contact Accessibility Guidelines (WCAG) and Success Criteria are organised around:

1. Perceivable - Information and user interface components must be presentable to users in ways they can perceive.

This means that users must be able to perceive the information being presented (it can't be invisible to all of their senses)

2. Operable - User interface components and navigation must be operable.

This means that users must be able to operate the interface (the interface cannot require interaction that a user cannot perform)

3. Understandable - Information and the operation of user interface must be understandable.

This means that users must be able to understand the information as well as the operation of the user interface (the content or operation cannot be beyond their understanding)

4. Robust - Content must be robust enough that it can be interpreted reliably by a wide variety of user agents, including assistive technologies.

This means that users must be able to access the content as technologies advance (as technologies and user agents evolve, the content should remain accessible)

If any of these are not true, users with disabilities will not be able to use the Web.

See www.w3.org/WAI/WCAG21/Understanding/intro for the entire article.

Inclusive product design

Before you even create your first wireframe, there needs be consideration to what is being offered to our customers. We advocate for clear customer communication with everything from our product and service offerings, fees and rates to terms and conditions. Ensuring clarity and simplicity in delivering product and service information is integral for communicating value, especially given the complexity of financial products and services and their impact on peoples' lives.

Inclusive content writing

Writing in a clear, simple way promotes equal access to information, creating a society where no one is left behind. As a guide, our content needs to be understood by a 13 year old to cater for people who have a basic understanding of legal and financial language and who use English as a second language, as well as those with an intellectual or learning disability. Some common things to consider when writing for a diverse audience include:

• spelling acronyms in full when they’re first mentioned.
• writing link copy that provides context instead of using ‘click here’.
• avoid using terms that assumes the way a person interacts with something, for example, ‘walk’, ‘simply’, ‘see’ or ‘watch’. For more information on writing simply and inclusively, check out the Writing for Digital Guidelines.

Accessible interfaces

When designing and coding for accessibility, it's often the case of function over form to ensure components meet WCAG standards while still retaining a layer of branded attributes and market appeal.

Consideration for assistive technologies for digital goes beyond screen readers, we also design for those with motor skill challenges, cognitive challenges and impaired sight to name a few.

Colour contrast, line weights, hit targets and spacing are all considered when designing the visual aspects of the components, while making sure the integrity of each brand in the Westpac Group is protected.

Accessibility testing

This is the aspect of accessibility that seems to have the most awareness, where the code is tested before delivery of the product or service. If you've got all other aspects of your inclusive design right, then this is the next most important part of the process. Ensuring that the code is accessible is what allows users to consume your content using the assistive technologies they depend on, like screen readers.

This is one of the driving forces behind the GEL Design System, it is a systematic framework for building accessible and inclusive products and services.

All components have been thoroughly tested for accessibility and comply with WGAC 2.1 AA. Each component has been tested in isolation, so when teams are building new products using these components, it is still a requirement to test the built product or service before going live. However, if it has been assembled using components from the Design System, you'll already be ahead.

We have close, established relationships with industry leading accessibility experts and continue to push boundaries to deliver ever-accessible components and patterns. The following describes how our components were tested:

Testing approach

Every component has been tested and passed relevant WCAG 2.1 Level A and AA Success Criteria for mobile and desktop views. The testing was conducted across 7 combinations of assistive technology and web browsers based on the most commonly used assistive technology and web browser combinations on PC, Mac, iOS and Android including:

• JAWS 17 and JAWS 2019 with Internet Explorer 11 on Windows
• NVDA (latest) with Firefox (latest) on Windows
• VoiceOver with Safari on OSX
• VoiceOver with Safari on iOS (latest)
• TalkBack with Chrome on Android (latest)
• Dragon NaturallySpeaking with Internet Explorer 11 on Windows

Any WCAG conformance issues, assistive technology issues found were workshopped and addressed using best practice approaches and recommendations for creating a more inclusive experience.

Deprecated components

Unfortunately a few of the components from the previous version of the Design System no longer made the grade in the new WCAG 2.1 AA world. So they had to be deprecated or significantly adjusted, this is what has changed:

• Removed the functionality to dismiss a popover by clicking anywhere else on the page. We still have the Popover with toggle functionality. To continue to comply with accessibility requirements Popovers need to be dismissed by either clicking on the trigger that launched them or by selecting a close button.
• Labels were removed from Switches (Switches without labels are still available). The labels, On/Off were removed as they posed an accessibility issue for screen readers. In code, a switch is just a checkbox, a checkbox doesn't have a label that describes if it is checked or not. Re-engineering the switch to include that label was not worth the complexity required.
• Tooltips proved to have accessibility issues as well as not working effectively across responsive applications. As they were not very widely used (if at all) they were removed.