From design to development: support for an inclusive app

Inclusive Design

User Experience

Accessibility

The client

MyGov.be is a project of the FPS BOSA and a European initiative to create a Belgian digital identity wallet.

The MyGov.be mobile app is available to all Belgians and complements the physical identity card.

From the outset, it has been important for the FPS BOSA to develop a mobile application that is usable for all users.

The goal

For FPS BOSA, it is crucial to comply with the European Accessibility Act.

To guarantuee success and archieve compliance, our assignment consisted of three main phases:

Support during the design phase to detect errors early on,
Technical support the development teams to minimise implementation errors,
Testing after the implementation, to validate inclusive solutions and maximise compliance with the EAA.

For FPS BOSA, it is crucial to comply with the European Accessibility Act.

To guarantuee success and archieve compliance, our assignment consisted of three main phases:

Support during the design phase to detect errors early on,
Technical support the development teams to minimise implementation errors,
Testing after the implementation, to validate inclusive solutions and maximise compliance with the EAA.

For FPS BOSA, it is crucial to comply with the European Accessibility Act.

To guarantuee success and archieve compliance, our assignment consisted of three main phases:

Support during the design phase to detect errors early on,
Technical support the development teams to minimise implementation errors,
Testing after the implementation, to validate inclusive solutions and maximise compliance with the EAA.

What we did

Design A11Y expertise
UX & UI support during design phase

Development A11Y expertise
Technical support for developers about accessibility needs

Implemenation testing
Validation testing of the new implementations

Our approach

1) Support during the design phase

Detecting adjustments early on is cheaper

Many accessibility issues can arise during the design phase. This is the ideal time to address any problems.
Experience and research have shown us that it makes economic sense to offer support during this phase.

This image shows that the cost in time increases the further you are into the project.

If issues can be resolved during the design phase, this is much more efficient than at a later stage, such as during testing.

Graph shows proportional relationship between cost of modifications and time

Bron case study

Ways of providing design support

We provide support during the design phase in two main ways:

A) Annotations with additional information

Many components require additional information in order to be inclusive. This can range from describing the correct focus order in the designs to the correct alt text for an image.

By providing the necessary annotations in the design files (Figma, Axure, Penpot, etc.), we ensure that the information is correctly transferred to the developers.

This makes it clear to them whether an image needs alt text or no alt text at all but should be used for decorative purposes.

B) Checking the style guide and user journeys

During design support, we also check the style guide. This means that we check all color combinations for contrast, verify that the correct responsive designs are provided, and check the size of the touch targets and icons.

In addition, we also check the user journeys. Here, we check whether the most important tasks are feasible for people with disabilities. This check is done for all disabilities: motor-impaired users, impaired vision, deafness, etc.

2) Support during development phase

Since teams often lack in-depth knowledge of accessibility, we also support developers during the development process.

Many aspects of accessible solutions are context-dependent. That is why developers often have questions during implementation.

During the MyGov.be project, our consultant worked closely with the development team. Together, they sought the best solution in a pragmatic way.

To ensure that everything runs in a structured manner, it is possible to log issues in the form of tickets.

The image shows an example of a ticket.

The following items can be described in such a ticket:

User story: as a blind user, I cannot perceive colors
Link to the Product Backlog Item (PBI)
Current situation: brief description of the current error
Expected situation: brief description of what it should be
Acceptance criteria: when is it fulfilled and can the problem be considered ‘solved’
Image: to visualize the example

2) Support during development phase

Since teams often lack in-depth knowledge of accessibility, we also support developers during the development process.

Many aspects of accessible solutions are context-dependent. That is why developers often have questions during implementation.

During the MyGov.be project, our consultant worked closely with the development team. Together, they sought the best solution in a pragmatic way.

To ensure that everything runs in a structured manner, it is possible to log issues in the form of tickets.

The image shows an example of a ticket.

The following items can be described in such a ticket:

User story: as a blind user, I cannot perceive colors
Link to the Product Backlog Item (PBI)
Current situation: brief description of the current error
Expected situation: brief description of what it should be
Acceptance criteria: when is it fulfilled and can the problem be considered ‘solved’
Image: to visualize the example

3) Testing the quality of the implementation

As in any proper agile team, implementations must be tested after implementation.
This guarantees the quality of the solution.

How else can you know if the implementation works?

At MyGov.be, we checked each ticket again to ensure correct implementation.
If the implementation did not have the desired result, we pragmatically sought an alternative with the stakeholders.

Do you have questions about usability support, accessibility expertise, the EAA, or inclusive design?
Feel free to contact us without any obligation.

3) Testing the quality of the implementation

As in any proper agile team, implementations must be tested after implementation.
This guarantees the quality of the solution.

How else can you know if the implementation works?

At MyGov.be, we checked each ticket again to ensure correct implementation.
If the implementation did not have the desired result, we pragmatically sought an alternative with the stakeholders.

Do you have questions about usability support, accessibility expertise, the EAA, or inclusive design?
Feel free to contact us without any obligation.