Accessibility is about building products for everyone
Society is changing for the better. People with different needs are increasingly given equal possibilities to live a life close to what is regarded as “normal”. This page is meant to help increase our understanding of accessibility, what it is and how the new EU laws of Accessible web applications affect product development in Visma.
Inclusive Design Toolkit
WCAG is built around four core principles:
so people can see or hear the content
so people get clear and simple language
so people can use it by typing or by voice
so people can use different assistive technologies
The Guidelines are described as follows:
“Web Content Accessibility Guidelines (WCAG) 2.1 defines how to make Web content more accessible to people with disabilities. Accessibility involves a wide range of disabilities, including visual, auditory, physical, speech, cognitive, language, learning, and neurological disabilities. Although these guidelines cover a wide range of issues, they are not able to address the needs of people with all types, degrees, and combinations of disability.
These guidelines also make Web content more usable by older individuals with changing abilities due to aging and often improve usability for users in general.”
It is important to remember, that not all disabilities are visible or permanent. For example, a person with a hand injury still needs to do their work even though their hand might be in a cast. It might sound obvious – but people with disabilities have the same needs as non-disabled people. So why don’t we build systems that can be used regardless of ability?
Visma Accessibility Maturity Model
Visma is one of the largest software companies. Our products are used by millions of people. We contribute to an important change for the individual and for the organisations these people are working for – for the society.
We can give people with disabilities the possibility to start a business of their own, to be able to apply for a job as everyone else, to be able to continue their work even though they have a temporary disability.
As one of the leading software companies in Europe, Visma is in prime position to be the change leader for accessibility friendly workplaces. Together, we can contribute to the important change and we can lead that change.
As a large company we want to support all of our teams in this change. To help us with this, we have developed the Visma Accessibility Index. It consists of four levels, all with different requirements and different support for accessibility. Starting on the bottom, we have the Bronze level with basic support, all the way up to Platinum with full support for WCAG AAA.
Bronze – The basic level
- Visual presentation have sufficient contrast and quality, non-text content is understandable even without being able to see it visually.
- It is easy to understand and interact with the system, no changes occur that the user would not expect. The user interface and its contents are consistent.
- Forms and other input are clear and helpful.
Silver – Stepping up
- The user interface is responsive, it is easy to navigate and use using only a keyboard.
- Navigation is logical and clear. Input errors are prevented as far as possible, and the user can access relevant help and instructions if needed.
- The code is following most of the best practices within front-end coding, such as using correct element markup and labelling. There are no timed, flashing, or unexpected elements or events.
Gold – Target level (AA Compliance)
- The support for audio and video content is sufficient with captions and have alternatives to pre-recorded content.
- The code is of excellent quality and contains no major errors.
- The user can control how text is presented visually.
- Touch or motion based interactions are given alternatives.
Platinum – Best in class
- Extended support for audio and video content, including live content.
- User can choose themselves how to interact, using keyboard or similar devices, mouse or other.
- The user has complete control over animations and other changing elements, as well as visual presentation.
A tip from us it to tackle Accessibility as early as possible and to take a proactive approach. There’s no such thing as perfect timing, and accessibility is no different, but starting now is always better than waiting, because waiting until accessibility is a problem is always more expensive, more disruptive, and more time-consuming than it needs to be.
- Get familiar to the different levels in Visma Accessibility maturity model.
- Select where to start – if your product is big the first scope might be a module that is public or commonly used, then continue with the rest of the product.
- Find your baseline and do the Visma Accessibility self-assessment.
- Identify your target level. For most Visma products, we believe that the target should be Gold level. When reaching Gold level you will be compliant to (AA level) according to WCAG guidelines.
- Create a plan on how to reach your target level. Create Jira cases to know where you have your gaps.
Accessibility and Nordic Cool
By using the Nordic Cool color palette and the NC4 Web library you meet some of the accessibility requirements “for free”. We have created a page to help you understand which requirements are met by using these resources and what you need to think about yourself when you develop your product.
The graphic style is an important part, and following Visma UX Guidelines will provide good support for accessibility. But accessibility is more than the looks, the content and interactions – using good code standards and supporting users work regardless of input device or ability, requires you to learn how to code it and to test it.
For example, buttons should be coded using “button” instead of “DIV” (or any other tag) in order to have good accessibility. It will still look good. To further answer your question, we offer an overview of what is covered by the Nordic Cool design language and Web library and what you need to consider yourself. Find the overview here.
You have to prioritize – frequent target groups, frequently used pages or modules. Do not forget the admin users that use the tool on a daily basis. A good place to start is to read this https://www.w3.org/WAI/planning/interim-repairs/
Bronze level requirements that are affecting core elements in a web application, since Visma is offering “office applications” a big number of users benefit from reaching Bronze level, so some “detailed” AAA-requirements are found here.
Silver level is likely to benefit many internal and “external” users, and Gold level is fully AA compliant.
Platinum is for applications using much video/audio or targeting a wide audience or audience that need high accessibility support, containing only AAA requirements.
WCAG is designed as a one size fits all, however when the Visma Accessibility Maturity Index was created, we took into consideration the context of our main users. An example is 3.1.4 Abbreviations, which requires unusual abbreviations to be explained – a clear and concise language is already a key design goal for all Visma products, and all products should avoid jargon or confusing language as much as possible.
More and more customers in the private sector are discovering the advantages of accessibility. It is not unlikely that within a few years, providing accessible websites and digital tools will be as obvious as having a wheelchair ramp or automatic doors.
Norway while not a part of the EU, has similar laws which also include the private sector.
Before the workshop define what product/service/ module that will be your target before you start doing the self assessment. Many teams are responsible for several products/services that are a part of the offering to our customers. We recommend that you do one assessment for each product/service/module. To save you some time we also suggest you to run automatic tests before the workshop. Here you find information about suggested tools that can help you to automate parts of the requirements.
Create the Accessibility selfassment in Confluence. During the workshop let someone share their screen during the meeting, someone else checks each requirement and takes notes. If you identify requirements that you need to fix in your product create Jira tickets to track progress.
Below is a list of WCAG requirements that may be partly evaluated by using the Wave plugin:
1.1.1 Non-text Content (Level A)
1.2.1 Prerecorded Audio-only and Video-only (Level A)
1.2.2 Captions (Prerecorded) (Level A)
1.2.3 Audio Description or Media Alternative (Prerecorded) (Level A)
1.2.5 Audio Description (Prerecorded) (Level AA)
1.3.1 Info and Relationships (Level A)
1.3.2 Meaningful Sequence (Level A)
1.4.2 Audio Control (Level A)
1.4.3 Contrast (Minimum) (Level AA)
2.1.1 Keyboard (Level A)
2.1.2 No Keyboard Trap (Level A)
2.2.1 Timing Adjustable (Level A)
2.2.2 Pause, Stop, Hide (Level A)
2.4.1 Bypass Blocks (Level A)
2.4.2 Page Titled (Level A)
2.4.3 Focus Order (Level A)
2.4.4 Link Purpose (In Context) (Level A)
2.4.6 Headings and Labels (Level AA)
2.5.3 Label in Name (Level A)
3.1.1 Language of Page (Level A)
3.1.2 Language of Parts (Level AA)
3.2.2 On Input (Level A)
3.3.1 Error Identification (Level A)
3.3.2 Labels or Instructions (Level A)
4.1.2 Name, Role, Value (Level A)
4.1.3 Status Messages (Level AA)
Full documentation and details about how the Wave plugin can be found here: https://wave.webaim.org/api/docs
What happens after you contact us?
If you have any questions or experience regarding accessibility please feel free to join us on Slack #sig-accessibility.