Business analysis for non-typical users. I wish I had known this before!

Posted by Adelina Cojocaru on Jan 08, 2025
One of my greatest digital IT project-driven learnings of the last year was ensuring accessibility (a11y[1]) inside web applications. This driven-by-fate exposure revealed an inspirational world with immediate end-user value, interesting insights, and exposure to assets to support managing such requirements. Please note that this is the subjective story of my journey, and through the paragraphs below, I intend to present the experience and lessons learned in the process.
[1] ”a11y” is a numeronym for “accessibility”, with 11 representing the count of letters between the letters a and y. Other numeronyms you may be familiar with include i18n (internationalisation), P2P (peer to peer), WWII (World War 2), etc.

The context. Why a11y?

As I currently live and work in Romania, I decided to address the problem only within the EU and include links to the other states’ expectations in the additional resources section. 

In 2023, 27% of the EU population over the age of 16 had some form of disability. Eurostat estimates that that equals 101 million people or one in four adults in the European Union (EU). The ugly truth? Even if you are now at the top of your health, the older you get, the more likely it is to have an impairment. (Source: https://www.consilium.europa.eu/en/infographics/disability-eu-facts-figures/ )

Concluding the need for accessible digital products and services, on October 26, 2016, the European Parliament and the Council published Directive (EU) 2016/2102, starting the improvement journey with public sector bodies’ websites and mobile applications. This directive stated that a set of principles and techniques should be considered when designing, constructing, maintaining, and updating websites and mobile applications to support their use by persons with disabilities.

On 17th of April 2019, the European Accessibility Act (EAA) (Directive 2019/882) complemented existing regulations with additional steps towards accessibility for digital products and services, including the private sector of EU countries. (Source: https://ec.europa.eu/social/main.jsp?catId=1202&intPageId=5581&langId=en). With each member state being responsible for EAA enforcement (meaning they can appoint the body in charge of enforcement and decide penalties), the next milestone was set for the 28th of June 2025, when consumers shall be able to report non-compliance and file complaints before national courts or authorities if services or products do not respect the rules.  Every web/mobile application already available or planned to be live by June 2025 must address a11y requirements.  Progress reports are expected to be published by the EU in December 2024.

Considering all the above, my previous client included in the backlog a “must” high-level requirement of ensuring accessibility for the new application we were building starting in early 2023. The acceptance criteria were expressed through compliance with WCAG standards (Web Content Accessibility Guidelines). From a timeline perspective, the delivery was expected by the end of 2024 and from a tactical approach, the project prioritised this to be addressed later rather than sooner in the product development roadmap, focusing on building core functionalities first and altering the user interface later for compliance reasons due to several reasons, including a critical dependency on client’s UI components evolution from an accessibility perspective. 

Learning to swim by jumping into the waters

In my professional journey, this was the first assignment where I got hands-on with the accessibility thread. Taking a breath, I looked for best practices, others’ past experiences, and options to proceed. The perfectly imperfect reality looked like this:

  • Current skills: 1%. Some existing knowledge was gained through foundational badges during the pandemic. A growth mindset and attitude are in place.
  • Requirement ready-for-development deadline: not favourable
  • Supporting assets:
    • A client who had already in place a strategy to address a11y
      • In building phases: through the roadmap of their branded UI components that our project was also using
      • In testing phases: they could access a dedicated team of non-typical colleagues to check for issues within our in-development application using various methods, including, amongst others, testing the user experience of a visually impaired user through a paid version of a screen reader.
    • An employer-based BA community to ask for previous experiences (not too many insights available locally, unfortunately)
    • An internal community that organises accessibility knowledge-sharing sessions welcomes questions on “how to x” through internal channels and promptly addresses them. I wish I had known them before!
    • A passionate project manager and an experienced front-end team lead who is highly committed to overcoming context challenges and making it through what seemed to be a “mission impossible.”

The dark side of the adventure: requirements refinement

Every good story needs a villain. Our journey was not an exception. Every step felt like opening a Pandora’s box while trapping inside the hopes to get it to an end.

WCAG international standard already has three versions (2.0, 2.1, and 2.2) and three conformance levels for any of them (A - lowest, AA, and AAA -highest). Which one applies to the project when considering users from cross-EU countries?! I decided to proceed with the assumption as the most recent version available is also the fittest, and the medium conformance would be good enough.  WCAG 2.2 AA was about to become our new best friend.

Refining the requirements per the chosen standard required a shocking dose of adrenaline and cortisol. However, getting from 1 to 100 requirements took only a few seconds, thanks to a public asset IBM shares on its website: https://www.ibm.com/able/requirements/requirements for WCAG2 requirements for different target levels. The WCAG2—AA choice helped us reduce the volumes to 34.

Do you remember the deadline note from the previous section? We could not estimate or deliver this within the project boundaries. Luckily, we could share some of the burden with the team working on UI components, but unfortunately, WCAG2.2’s detailed compliance with their current UI version release was not straightforward. So, we decided to invest time in assessing per component fit as input for project executives to manage the delivery risks further while continuing the refinement activities for our application use cases.

Enough about the standard. What did we do at the application level?

Here it was, another hiccup, poking and prodding the story protagonists, forcing us to stretch and grow. The summary: everything was in scope. All existing functionalities had to be tested from an accessibility perspective, issues had to be adjusted by the front-end colleagues, and the whole learning had to be transferred to the team as implementation practice for all upcoming product functionalities. We needed to divide and conquer!

To get the project team on track, we scheduled accessibility testing—iteration 0—on a stable application version.

We discussed and agreed on ways of working, considering distribution and constraints. The client’s special testing team is accessible only remotely. This means we can use only written communications (via e-mail) so they can use a screen reader to grab our messages and other tools to reply or schedule virtual meetings (by design, without visual support) – aiming to use speech to describe and deepen a conversation.

We scheduled sessions to clarify and prioritise findings according to severity and upcoming releases. We also acknowledged non-standard deployment as acceptable for application accessibility improvements for further checks.

Where are we now?

Accessibility testing iteration 0 has ended for a while. The product has evolved since the tested version and has now doubled the number of features. New versions of UI libraries, including accessibility improvements, are available. However, the current release did not include switching to the newest one. We invested time to define the strategy for the elements we could control outside of this dependency (improve the application gradually, module by module, throughout several product releases) and tactical next steps:

  • Start with the first application module. Get feedback from accessibility and regression testing perspectives. Adjust deployment processes. Improve based on lessons learned. Iterate. 
  • To point out application flaws, use a Chrome browser add-on accessibility checker instead of a standard use-case strategy. The options are Axe, Wave, and IBM Accessibility Checker. We prioritised Wave.
  • To support manual testing, use voice-over applications available on Apple devices. For more advanced findings, count on the client accessibility team.  

The Development Team is executing the above using a capacity-based approach. I switched assignments while they continued their journey. I trust they will make it through!

In a snapshot

It is not ideal to address the accessibility topic for the first time within project deadlines and many competing priorities. Getting appropriate skills and knowledge on the matter will take time and commitment towards the goal will be a non-linear learning process with all kinds of blockers on the road while having a human-centric, straightforward value-added.  Accessibility within digital products and services is here to serve and stay.  And it is enforced in the EU space by the June 2025 deadline. Ready or not, here it comes. We can't hide. Feel free to share your experience so we can all benefit from it!

Additional resources (alphabetical order)

  • Android Accessibility Help

About the Author

Adelina Cojocaru is a CBAP Certified, Business Transformation Consultant. The above article is personal and does not necessarily represent any employer positions, strategies, or opinions.