Create Your First Project
Start adding your projects to your portfolio. Click on "Manage Projects" to get started
Introducing accessibility in public sector project
Accessibility Case for the largest pension group in Germany
Sector
Public and private, pension group
Technology
Websites: one for customers and one for employees
Market
German
Challenge
How to implement accessibility for websites that already exist for years?
Role
Accessibility Auditor, UX and UI Designer
In project
2022-2024
Project description
The project is a modern commercial enterprise and state authority in one. As a public institution within the European Union, project was required to comply with the EN 301 549 standard, which defines accessibility requirements for ICT products and services in accordance with the European Accessibility Act and Directive 2016/2102. Additionally in Germany, the BITV 2.0 (Barrierefreie-Informationstechnik-Verordnung) applies. It mandates, among other things, that the accessibility statement must be updated annually or whenever the system undergoes changes.
In 2022, I was recruited to the project because of its public nature and, consequently, the legal requirement for accessibility compliance. It was a long-standing client of ours, and due to the threat of penalties, the situation in the project was tense and expectations were high.
Workflow for AccessibIlity
Design changes
Changes in components from library and Style Guide
Design review
Library components
and Style Guide audit
Audit
Findings and creating Conformance Claim
Accessibility session
Meeting with all stakeholders: client, auditor, PO, devs etc.
Changes in the code
Implementation of tasks from requirements phase
Creating tasks
Assessing changes impact on website elements
New a11y audit
New Conformance Claim
Audit
Design
Requirements
Development
Testing
Accessibility Maintenance
Choosing a platform
The project has two platforms, operated by two separate teams:
-
Platform 1 - the client portal for contributors to pension schemes and retired individuals
-
Platform 2 - the employer portal for external and internal administrative officers
Given that Platform 1 is aimed directly at customers, we decided that this will be the platform where we would introduce accessibility changes first. Platform 2 was to be changed after the implementation of accessibility in Platform 1.
Accessibility Audit
Date:
29.07.2022
Scope:
WCAG 2.1 A & AA
Time period:
06.06-29.07.2022
Operating system:
Microsoft Windows 10 Pro
Browser:
Chrome
Tools:
NVDA 2021.1, VoiceOver, ARC Toolkit, axe DevTools, Color Contrast Analyser, WAVE
Work on the audit
The audit was conducted as a team: by me and three other colleagues. Each of us had our own pages to audit. We synchronized twice a week to discuss any doubts and check on the progress of the work.
We conducted the audit using a template we created in Excel, where we marked whether a given criterion had been met, provided recommendations for changes, and gave examples of correct implementations.​
Conclusions from the audit
After checking Platform 1's website, we found errors in 19 success criteria from WCAG 2.1. These errors were described in the final report for the client. The report was also handed over to the team: designers, developers, and testers. Thanks to the conclusions from the audit, we were able to create an accessibility Conformance Claim, which was posted on the Platform 1 website. ​
Unfortunately, the client decided not to implement the changes to the website immediately. Work on accessibility was put on hold for a year. I was recruited to the project again in 2023, but this time as a UX/UI Designer with knowledge of accessibility.
​
My task was to change the components in the library and Style Guide to meet accessibility requirements.
Changes in the library and Style Guide
Accessibility Audit
The first step in the design change phase was a library audit. Each element was checked with WCAG 2.1 criteria. The audit resulted in a report that allowed me to know exactly which components I should change.​
Problems with focus state
Focuses in the library were often invisible (sometimes shadow was added) or had insufficient contrast.
Focus highlighting in the “Focused” state (#7CBCE7) was generally too low for buttons and other graphical elements in contrast to the background (#FFFFFF) (and compared to the “Normal” state) (contrast: 2.1:1 – target value at least 3:1).
Working on changes
The audit revealed two main errors in our library: focus status and insufficient contrast.
Examples, before accessibility changes:
Examples, after accessibility changes:
A number of other improvements have also been made: error states have been improved (contrast has been enhanced and an icon has been added), clickable areas have been increased (24x24px), icons have been bolded and the appearance of many elements has been made more consistent.​
Problems with contrast
Elements in the library often lacked sufficient contrast, both for text and non-text elements (many elements had a contrast ratio below 3:1).
Examples, before accessibility changes:
Examples, after accessibility changes:
Completion of changes
All changes made to the library were approved with the client and corrected as necessary. After closing changes in the library, they were applied to the Style Guide, which was later used as a handoff for the team.
Problems during implementation
When the project moved into the implementation phase, we encountered several problems. The two most serious ones concerned the appearance of the website and deficiencies in the library.
Problem 1 - the appearance of the website
At an early stages of implementation, developers expressed serious concerns about the website's appearance. According to most of the development team, the website began to look very “heavy” due to increased contrast. Additionally, there was a concern that the appearance was moving in the direction of old websites from the 2010s. At the same time, the developers were at the beginning of the implementation process, which made the website look even worse — partly composed of new and old components. So it was difficult to say whether the concerns about the website's appearance were justified.
Problem 1 - solution
I was invited to a meeting with the PO and the team to discuss a potential solution to the problem (at that point, the client was not aware of the concerns). The client was going to visit us, so I suggested that during the client's visit, I would present 5 selected and most representative website designs that would be created from the new library. It was true that we had previously only looked at individual elements, but not at the website as a whole.
Problem 1 - final conclusion
During the visit, the client was presented with “Reference Designs” for Platform 1. It turned out that after using only new components, the website looked good. The client accepted the designs, and the developers' doubts were dispelled.
For changes to Platform 2, at the beginning of the process, it was planned to create “Reference Designs” after introducing changes to the library.
Problem 2 - deficiencies in the library
During the implementation of the changes, it turned out that there were many components on the website that had never been added to the library. There were also components that looked completely different on the website or had new functionalities. This was probably due to frequent turnover among designers in the team and the fact that the client often decided on the designs and components added to the website without informing the designers about additional improvements.
Problem 2 - solution
I had regular meetings with the developers, during which we went through new/changed components. In addition, two developers reviewed all components in the library against the components on the website and compiled a list of missing/improved elements.
Problem 2 - final conclusion
We finally reached a point where the library matched the state on the website, but it cost us a lot of unplanned work. In addition, I had to update the Style Guide each time and pass the changes on to the developers and testers.
In the plans for accessibility changes in Platform 2, a review of the library with developers was planned at the stage of implementing changes to the library.
Final designs
* Due to the NDA, company logo has been changed.
Before accessibility changes:
After accessibility changes:
Before accessibility changes:
After accessibility changes:
Final conclusion
Our work on accessibility began with an audit and ended with the introduction of accessibility into the product. At the end of the process, the client's website corrected around 80% of the errors that were detected during the audit. In addition, accessibility was integrated into each sprint cycle so that new functionalities or possible changes were evaluated for compliance with WCAG criteria.​
The implementation of accessibility had a positive impact on project operations
expanded the reach
of digital services
improved the quality
of user interactions
strengthened the company's image as inclusive
Additionally, the client gained greater awareness of the importance of accessibility,
which facilitated collaboration and accelerated decision-making.
After the changes introduced in Platform 1, I also had the opportunity to work on changes in Platform 2, where we drew conclusions and improved the accessibility process (e.g. through regular checks with developers regarding the library or the preparation of “Reference Designs” after changing the library).