Menu

Accessibility

Visma Accessibility
Maturity Model

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.

Visma Accessibility Maturity Index

Accessibility anchor

What is Accessibility?

The Web Content Accessibility Guidelines (WCAG) have been around since 1999. In short, WCAG is a standard intended to make the web more accessible. It is internationally used by governments and businesses and is part of the EU accessibility directive. Adhering the WCAG standards is also included in VCDM. This means that all of us need to learn about this area and contribute.

Inclusive Design toolkit anchor

Inclusive Design Toolkit

Accessibility - Touch

Touch
Accessibility - See

See
Accessibility - Hear

Hear
Accessibility - Speak

Speak
Accessibility - Cognitive

Cognitive
Permanent
Accessibility - One arm

One arm
Accessibility - Blind

Blind
Accessibility - Deaf

Deaf
Accessibility - Non-verbal

Non-verbal
Accessibility - ADHD

ADHD
Temporary
Accessibility - Arm injury

Arm injury
Accessibility - Cataract

Cataract
Accessibility - Ear infection

Ear infection
Accessibility - Laryngitis

Laryngitis
Accessibility - Burnout/depresion

Burnout/depression
Situational
Accessibility - New parent

New parent
Accessibility - Distracted driver

Distracted driver
Accessibility - Bartender

Bartender
Accessibility - Heavy accent

Heavy accent
Accessibility - Noisy office

Noisy office

WCAG core principles anchor

WCAG is built around four core principles:

Accessibility - Perceivable

Perceivable
so people can see or hear the content

Accessibility - Understandable

Understandable
so people get clear and simple language

Accessibility - Operable

Operable
so people can use it by typing or by voice

Accessibility - Robust

Robust
so people can use different assistive technologies

WCAG guidelines anchor

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?

Maturity model anchor

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 level anchor
Bronze level

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 level anchor
Silver level

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 level anchor
Gold level

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 level anchor
Platinum level

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.

Get started anchor

Get started

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.

 

  1. Get familiar to the different levels in Visma Accessibility maturity model.
  2. 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.
  3. Find your baseline and do the Visma Accessibility self-assessment.
  4. 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.
  5. Create a plan on how to reach your target level. Create Jira cases to know where you have your gaps.

 

Create your self-assessment

Nordic Cool color palette

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.

 

Go to the page

FAQ anchor

FAQ

These are some commonly asked questions from teams in Visma. If you think that some of your questions should be answered here as well, please let us know.

We are using Nordic Cool, isn’t that enough to be compliant?

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.

This will take a very long time to evaluate – how can we plan this project?
Yes, and one single person is unlikely to be able to make the evaluation by themselves. Accessibility is a joint effort by management, designers, and developers – everyone needs to contribute with their own skills.

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/

How did you define the levels?
The levels are based on WGAC guidelines and we have tried to simplify and group them into different levels.

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.

Why are there AAA requirements on the lower levels?
The WCAG levels are based on complexity to implement, how many users are affected, and severity (eg. if it is not met, would people be prevented from using a web site altogether).

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.

What kind of customers want us to be compliant to WCAG?
According to the EU web accessibility directive, all “public” organisations need to provide accessible services which means that these customers will be increasingly asking for accessible tools from us.

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.

Customers need us to respond how we adhere to WCAG, help!
An accessibility statement can (and should) be provided to all customers either by linking to it directly from the product, or somewhere else where it’s easy to find. You can read more about creating an accessibility statement here: https://www.w3.org/WAI/planning/statements/

Should we make the assessment for the whole application or parts?
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 one part of your product, targeting the biggest user group.

How to make the assessment in practice?
Set aside 1-2 hours for a workshop with the key roles in your team (PO/SO, PM, BA, QA, UX, Content writer, Frontend Developer/Developer).

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.

What does “Not applicable” mean?
Some applications might not use video or streamed content for example.

We have done the self assessment. How do we know which level we are on?
The self assessment in Confluence is divided into sections (bronze, silver, gold and platinum) and if you are compliant to all requirements within a section you are compliant to the highest level. If all checkboxes marked as YES in Bronze, Silver and Gold congratulations you are on Gold level and compliant to AA standard according to WCAG. In the future we aim for presenting the Accessibility maturity level in the Index application in the same way as you find information from Security, Architecture and VCDM.

Can you automate the assessment?
Many of the guidelines cannot be interpreted by automatic tests, like “logic” tab order, good navigation or “natural language”. Automatic tests cannot judge if an error message is helping the user correct the error. In addition, automated tools might give false positives. An example is alt text which can be automatically checked that it exists, but the actual meaning of the alt text needs to be sufficiently describing the image. However, it is good to start off by running your product through an automated tool to catch some major issues. Here are some of the tools and resources that we recommend.

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 about CAPTCHA?
CAPTCHA is a controversial topic from an accessibility perspective. For some applications, using CAPTCHA or other similar technologies for authenticating might be unavoidable. Try to assess whether it is really necessary to use CAPTCHA.

 
Contact us at
#sig-accessibility

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.

General questions related to the self-assessment contact Susanna Lindkvist. If you have specific questions regarding Nordic Cool and Accessibility contact ux@visma.com.

This site saves certain data to enhance the user experience. By using ux.visma.com you approve this. More info

This site uses cookies, which collect information about how you interact with the site. In combination with the information you provide, we create a profile so that we can show relevant content just for you.

By accepting, you allow us to collect and process your personal data as described.

Close