One, and, thank you for joining. Welcome to the presentation mastering digital accessibility.This is a crucial topic, especially now, as digital technologies shape more and more aspects of our daily lives. So one essential question will be, how can we make sure no one is left behind in this transformation? Let's see if we can find a few answers together in today's presentation. My name is Lilia. I am head of, software quality assurance at MGM Technology Partners. After studying computer science in North Germany, I worked over fifteen years as software developer in diverse projects and, in different fields, especially in the public sector. In the last twelve years, I worked intensively in the field of software quality assurance, especially in test automation.

And there, I have my own innovation, which is called the automation of test automation. Besides, I am contributor to the German testing board. In case you would like to connect, with me in LinkedIn, please feel free to follow the QR code. And, throughout the presentation, you will also see a few other QR codes. This won't link you to my LinkedIn, but rather to the sources related to the respective topic in case you would like to dive deeper. Now let's move to the agenda. After a short motivation, we will talk about legal and technical foundations of digital accessibility with a particular focus on the European and German context.

Afterwards, I will present the shift left approach in the software development process. Following that, I will spotlight testing strategies that support digital accessibility. Last but not least, at the end of the presentation, we will have a short q and a session in case you have any questions. So let me start with the definition of digital accessibility. Digital accessibility refers to the design and development of digital applications in a way that enables all individuals, including those with disabilities, to effectively perceive, understand, navigate, and interact with digital content, ensuring equal access to all users. To understand why digital accessibility matters, let's take a closer look at who is affected. So affected are individuals with physical, cognitive, or sensory disabilities. In some cases, the disabilities are situational, for example, accident. In some other cases, individuals might experience multiple overlapping impairments, making their needs even more complex.

In Germany, around one in eight people lives with a disability. Globally, the figure rises to one in six. So these numbers clearly demonstrate why digital accessibility is not optional, but essential for inclusion and equal access. There is a very interesting US organization called Web Accessibility in Mind, for short, WebAIM, maybe you know, founded in '99 that aims to make the Internet more accessible for people with disabilities. So they test yearly 1,000,000 home pages using their own testing tool called, WAVE and publish yearly the 1,000,000 report containing very interesting statistics. So in the year twenty twenty, ninety eight percent of the tested home pages violated at least one of the WCAG accessibility success criteria, which I will present later. And every home page has an average of 61 accessibility errors. Horribly high figures. Right? Let's see what happens four years later.

So you see here a slight decrease, basically, but still high. The figures are still high. So in, 2024, almost 96% violate the WCAG success criteria, and we have an average of almost 57 errors. One year later, so this year, 2025. By the way, the the report was released, one week ago. So the figures decreased slightly, but but they are still high. I immediately tested the homepage of my company, MGM Technology Partners, using the accessibility testing tool wave, And it reported four accessibility errors, which was fortunately well below the average, 51 of 51. Let's go further. 96% of the identified errors can be classified in six categories. In six categories, which are low contrast contrast text, almost 80%, then over 50% missing alternative text for images, then over 40% missing label for input fields and forms, and then over 40% empty links.

This was one of the arrows, at the homepage of MGM. And then we have empty buttons. It means you have a button, but there is no information about what it does. And then the last but not least, the last category, sixth category, is about missing document language. So why are these categories essential and or interesting? From the testing perspective, at least if I would like to conduct risk based testing for my application and I want to quickly achieve high test coverage, I would first focus on these, on testing these six categories. If we zoom out, we can see that between the years 2019 and 2025, there has been a slight improvement across all six categories. So now maybe the crucial question is what's holding back faster progress? Is it a lack of legislation?

One of the possible technical explanation for me is that the complexity of websites has increased dramatically in the last years. So in 2025, a home page contains more than 257 UI elements on average, which is too high. Now let's move to the topic legal and technical foundations of digital accessibility in the context of Europe and Germany. Before we get started, I would like to clarify the difference between the terms directive and standard. So the EU directive is a legal act used by the European Union to set out goals that all EU member states must achieve. So it defines what to be achieved. For example, websites should be accessible, but it does not provide technical details on how to implement it.

So each member state must transpose the directive into national law within a given time frame. So the directive becomes binding for citizen or companies only once it has been transposed into national law. On the other hand, European standards are basically recommendations. These are recommended technical specification. They provide technical details and methods to achieve accessibility. So the EU standard becomes de facto legally binding once it is referred to in, in a directive, for example, if the directive refers to the standard. Let me give you a very simple example. Let's say the directive, is, telling make an apple pie. So the standard is then the recipe including ingredients, baking time, and other details. Now let's talk about the web content accessibility Guidelines for short, WCAG.

This is the technical standard worldwide for accessible web. So we talk here about recommendation. These are recommended technical requirements to ensure that digital content is accessible to everyone. They are considered binding guidelines when officially mandated by laws and standards, which sees also the case in European Union because they are mandated by the standards. So, now let's, have a look to the historical evolution of WCAG. So, the version one dot zero was released in 1919. It was HTML centric, tailored to HTML and earlier web technologies, therefore, also quickly outdated. In the year 02/2008, the version two dot zero was released. It was technology independent, and it introduced the four principles of accessibility that we, will see later in later slides and introduced 61 success criteria for accessibility, at conformance levels a, double a, triple a. Also, we will see this later.

Ten years later, the version two dot one was released, and it does not overwritten the version two dot zero, but it extended it with further 17 success criteria. Then five years later, the version two dot two was released, extending all of this with nine further success criteria. And for now, the version three dot zero is not released yet, most likely end of this year, beginning of next year. What you see here is a presentation of the WCAG two dot one. At the the top, you will find the four core principles of accessibility. These principles are broken down into 13 guidelines. Under each guideline, you can see the corresponding success criteria starting from the 61 of WCAG two dot zero, followed by the 17 additional ones introduced in WCAG two dot one.

The success criteria are divided into three levels, as I mentioned, level a in red, level double a in yellow, and level triple a in gray. Altogether, WCAG two dot one includes 78 success criteria across all three levels. This is a nice presentation explaining basically the complexity of, the criteria. Now let's go to the four principles of accessibility. First of all, perceivable, the first principle. So users must be able to see or hear the content. This includes providing text alternatives for nontext content, for example, images and videos, using sufficient color contrast and offering captions, or audio descriptions. Then operable, so users must be able to navigate and interact with the content even without a mouse. This includes ensuring keyboard accessibility, providing enough time to complete tasks, and avoiding content that may cause seizures, like flashing elements.

Then the third principle is understandable, means content should be clear and readable. Interfaces should behave in predictable ways, and users should be helped to avoid incorrect mistakes, for example, form errors. Then the last principle is robust. The code behind digital content should be clean and standardized so that it works well across different devices, browsers, and assistive technologies like screen readers. This is really crucial. These are the conformance levels we talked about. So level a defines the minimum level of accessibility. Level double a is the recommended level, for most websites. Legal requirement, basically, in many countries, including European countries. Triple a is the highest level. It's the maximum accessibility, which is not easy to achieve. So, WCAG, we have 78 success criteria. If you meet them, you meet all conformance levels.

Now let's have a closer look at key milestones in European and German accessibility legislation. So in 02/2016, it's here, EU directive mandates that European member states ensure accessibility of public sector websites and mobile applications. So the focus here is public sector. The technical standout for implementation in the public sector was the version two dot one dot two, which refers to the WCAG two dot one. In the same year, which is 02/2018, this directive was transposed in German law. This is regarding the public sector. Now in in 02/2019, which is here, a second AU directive followed, which is called the European Accessibility Act. It did not replace the previous one, but it extended the requirements to include the private sector.

So this is the public sector directive, and this is the private sector directive. The technical standard for implementation, in the private sector was the version three dot one dot two dot one, which refers also to WCAG two dot one at levels a and double a. By the way, the WCAG two dot two has not yet been incorporated into any official standard. It is currently planned, for late twenty twenty five or early, '26. Let's see. The European Accessibility Act is being transposed into German law through the Accessibility Reinforcement Act, which, will take effect one month from now. So the Accessibility Reinforcement Act will require private sector economic operators to provide accessible products and services. This obligation extends, to areas such as banking, transportation, and other essential services. Notably, the most significant area of application will be ecommerce services. If you like to dive deeper, please, follow the QR code regarding the accessibility reinforcement act.

Now let's move to the shift left approach. So accessibility is not a one time task. So we talk now in the context of software development process. It is a continuous iterative process that must be embedded into every phase of the software development life cycle. So it starts with the requirement gathering and analysis where we have to define clear accessibility goals, adhere to relevant standards and involve the relevant stakeholders right from the beginning. In the design phase, accessibility means getting the basics, basically right, getting the basics right, using sufficient color contrast, scalable font size. So the designer should ensure also, visible focus indicators and provide an intuitive navigation. So all these aspects are crucial, and we should focus on this already in the design phase, having basically, an accessibility driven design.

It is also helpful, when designing to perform prototyping with accessibility testing in order to detect and eliminate accessibility issues in the design at a very early stage. Developers can also contribute a lot to digital accessibility by using semantic HTML, proper area roles, ensuring keyboard accessibility, and implementing a meaningful focus management. Developer can use accessible component libraries, existing component libraries, instead of using own custom component, that are most likely not accessible. They can also install accessibility linters in their integrated development environment to automatically scan and detect accessibility issues in their code at an early stage. And quality assurance, accessibility must be part of the test strategy, combining automated and manual accessibility tests. And finally, accessibility does not, stop at deployment. We need accessible documentation, ongoing monitoring, user feedback loops, regular audits, very important, and continuous training of the team. The advantages of the shift left approach in development are clear.

It enables early detection of accessibility issues, reduces costs, supports compliance with legal requirements, and leads to a better user experience. Moreover, it fosters an inclusive mindset within the development team. This is really very important. Now when is shift left not advantageous? If you have a legacy system, so an array an, already existing application, that is not accessible. Here is the prioritization and gradual integration of accessibility aspects, the better transformation strategy for you. Other reasons are experimental projects where it make no sense because you are focusing on rapid implementation of basic things, when having complex and unclear requirements, lack of expertise, or budget, or time constraints. Now let's move to test strategies for digital accessibility. This automation plays an important role in efficient accessibility testing, especially when it comes to regression testing.

So given the wide range of devices and platforms, automated tests can be executed across different browsers, which is called cross browser testing, and also across different operating systems using the same implemented test cases running over different browsers and systems, basically, ensuring consistency and saving time.

There are several free accessibility testing tools available on the market. Some of them are based on the AXA core engine developed by Deku Systems, while others, like Wave, for example, use their own custom rule engines. At MGM, we use, the test automation tool QF Test, for accessibility testing, which extends basically AXA core with additional accessibility checks. And you see here the report helping to quickly analyze the accessibility issues and and raise basically defect tickets. Automating accessibility testing allows you to run checks regularly, by integrating them surely in into your CICD pipeline, ensuring continuous compliance over time. Here you see screenshots from the nightly run of the MGM local platform a 12 where we check our widgets for accessibility issues on a daily basis.

Test automation tools are useful for detecting standardized rule based accessibility issues. Here you can see many of the aspects that can be checked automatically. I will not dive deeper into these aspects, due to lack of time, but you can make a screenshot if you want. There are many technical aspects that you can automatically check using an automation tool. Automated tools can reliably test only 20 to maximum 40% approximately of the WCAG success criteria. Things like whether alternative texts are meaningful, whether content follows a logical reading order, or if interactive elements are placed intuitively, these all require human judgment. Manual testing is this therefore essential. With manual testing, we are also able to assess dynamic content on on websites, for example, custom controls, and the overall user experience, especially for screen reader compatibility, also cognitive clarity, and detecting subjective barriers like, for example, distracting animation or confusing language.

That's why human testing is irreplaceable. Several factors can help optimize the testing process. It is important to consider accessibility at a very early stage, as I mentioned, in the shift left approach, already in the planning and design phase. It is important to include accessibility as a criteria in the acceptance criteria of user stories and agile. Then also to include them in approval criteria. Then, the developer should use linters when developing to scan the code, as I mentioned. Integrating automated tests, so implementing and integrating automated tests into the CICD pipeline is a crucial factor. Then, having systematically scheduled manual tests, we should define checklists regarding accessibility testing aspects, extending the test cases using test management tool.

That's what we do at MGM with structured accessibility test execution, including best practices. Another aspect, or proposal is to extend the defect management with the label accessibility and then prioritize the defect based on the accessibility severity barrier. For example, the critical and serious, should be fixed and tested first. Then it makes it is crucial to conduct regular accessibility audits internally, but also it's important to include from time to time external accessibility experts, let's say, in big releases, for example. Involving users with disabilities from my opinion point of view, this is really crucial, because they bring us very valuable insights. At this point, I like some people, some systems has accessibility feedback areas where people will, can give feedback and they can collect the feedback of the users, so that they can enhance the accessibility aspects.

Dividing, testing rules, and responsibilities is crucial and then, providing continuous training, raising awareness across the entire team. This is really important. Now let's talk about risk based testing because, most likely, you don't have the time to cover everything and test with all pass test all possibilities. So here, I collected very crucial questions that can direct you to the most important critical things first. So the first question is, what is the purpose of the test? So what is the legal minimum requirement? Then which user groups are particularly affected? Which page or function is especially critical? What would be the impact of a barrier in these or those areas? Then prioritizing the testing areas. What are the high risk areas? What are the most frequent used areas or used devices and modalities? Then, define the barrier types with the high impact. You remember the six categories at the beginning.

And then using the right testing methods strategically. Documenting the results and deriving the actions is crucial. And last but not least, inform the stakeholders and raise awareness. Let's talk about little bit about AI and accessibility testing. Maybe a clear message is for now, there is no one click solution where you click and your website is fully accessible, meeting all accessibility requirements. This does not exist yet. Nevertheless, I would like to recommend at least I have two tools where I can recommend using them, and both of them are using advancing, advanced AI. So first of all is Deque Systems. You can follow the code. They had a conference in February.

So if you register, you can get access for free to watch very, nice, presentations regarding AI and the development of the future of, the AXA platform. So they use use here the Q systems uses AI and machine learning to enhance automated accessibility testing, especially for dynamic and complex interfaces. It helps prioritize issues and reduce false positives when testing. And Evanced is the second tool I recommend. It's a AI driven, tool that detects accessibility, issues in web and mobile applications, beyond traditional rule based engines. It focuses on real world usability and developer integration. It analyze how components behave in interactive dynamic environments, not just in static code, and it considers visual structure, focus order, navigation flow, basically, which affect real user interaction, especially for users of screen readers or keyboard only navigation. AI has clear limitations, so it struggles, with contextual, contextual understanding. It also can't assess subjective user experience, like how intuitive or overwhelming a page feels.

Culture and contextual nuances are often missed, and ethical concerns arise due to potential biases in training data. So while AI is helpful, human insight is still essential, to ensure truly inclusive digital experiences. So AI can support accessibility testing, but it cannot replace human judgment. True digital inclusion requires empathy, context, and the user centered mindset, not just compliance, but real usability for everyone. So let me summarize. Digital accessibility is about ensuring that everyone, regardless of ability, can access, understand, and interact with digital content and services. It's not just a legal requirement or a technical checklist. It's about inclusion, equal opportunities, and building technology that truly works for all. So my take a home message for you, an inclusive digital future begins where accessibility is not an option, but the standard. Thank you so much for your attention.

Thank you so much. Do you have any questions? I hope you like the session. Thank you. And I hope it was, informative for you, giving you some insights. It's a lot of work to do. My first experience in digital accessibility, was in 02/2008. And at that time, I was software developer, of one of the web applications. It was for the German federal government taxes. And we had the basically, the task to convert this or to transform this existing system, to an accessible system. And, I we had a small team, basically, me and two other developers and one designer. And we worked on this topic over six months, prioritizing and transforming step by step this application. This was my first experience with the screen reader, Joyce. It was overwhelming, and I recognize how many aspects you have to consider if we talk about digital accessibility and inclusion. Very crucial topic. I hope you like the session.

Thank you so much for your attention. Feel free to contact me in LinkedIn, and see you then. Bye bye.