Accessibility Handoff Design Kit
Accessibility Handoff Design Kit
Accessibility
Accessibility
Accessibility
Documentation
Documentation
Documentation
Improving accessibility communication across teams
Role
User experience designer working student
Scope
Research, Accessibility audit, Design, Survey
Duration
Feb 2025 - NOW
Collaboration
PAYBACK
Platform
Mobile(Androind, iOS)
Tool
Figma
Overview
How might we make the PAYBACK app more accessible?
How might we make the PAYBACK app more accessible?
How might we make the PAYBACK app more accessible?
This project was conducted as part of my master’s thesis within PAYBACK, a multi-partner loyalty platform serving over 34 million users across Germany, Poland, Italy, and Austria.
In response to the upcoming requirements of the European Accessibility Act (EAA), the organization began strengthening its focus on accessibility across digital products. Working with PAYBACK’s accessibility team, I explored how accessibility could be more effectively integrated into PAYBACK’s mobile app.
In this complex, cross-platform environment, I focused on ensuring accessibility by aligning WCAG 2.1 principles with practical design and development workflows.
This project was conducted as part of my master’s thesis within PAYBACK, a multi-partner loyalty platform serving over 34 million users across Germany, Poland, Italy, and Austria.
In response to the upcoming requirements of the European Accessibility Act (EAA), the organization began strengthening its focus on accessibility across digital products. Working with PAYBACK’s accessibility team, I explored how accessibility could be more effectively integrated into PAYBACK’s mobile app.
In this complex, cross-platform environment, I focused on ensuring accessibility by aligning WCAG 2.1 principles with practical design and development workflows.
Challenge & Opportunity
Seeing barriers through the user’s eyes
Seeing barriers through the user’s eyes
Seeing barriers through the user’s eyes
Despite PAYBACK’s scale and digital maturity, persistent accessibility challenges have been reported, particularly by blind and elderly users. App store reviews and internal user research reveal that blind users frequently struggle with screen reader support—for example, encountering unclear reading order, unlabeled elements, and difficulties completing verification steps.
In response to these concerns, the digital product team began discussing how to improve accessibility in a more systematic and sustainable way—focusing not only on user satisfaction and app stability, but also on building inclusive experiences across platforms.
Despite PAYBACK’s scale and digital maturity, persistent accessibility challenges have been reported, particularly by blind and elderly users. App store reviews and internal user research reveal that blind users frequently struggle with screen reader support—for example, encountering unclear reading order, unlabeled elements, and difficulties completing verification steps.
In response to these concerns, the digital product team began discussing how to improve accessibility in a more systematic and sustainable way—focusing not only on user satisfaction and app stability, but also on building inclusive experiences across platforms.
With VoiceOver, the provider is no longer legible in the coupons area. No longer usable for blind customers.
With VoiceOver, the provider is no longer legible in the coupons area. No longer usable for blind customers.
With VoiceOver, the provider is no longer legible in the coupons area. No longer usable for blind customers.
It may well be that PAYBACK is a great system. But the best system is useless if it can't be used by everyone. I am blind and use a screen reader. It was difficult to log in because there was an audio challenge during verification, but it's not clear exactly where I have to tap to verify..
It may well be that PAYBACK is a great system. But the best system is useless if it can't be used by everyone. I am blind and use a screen reader. It was difficult to log in because there was an audio challenge during verification, but it's not clear exactly where I have to tap to verify..
It may well be that PAYBACK is a great system. But the best system is useless if it can't be used by everyone. I am blind and use a screen reader. It was difficult to log in because there was an audio challenge during verification, but it's not clear exactly where I have to tap to verify..
Changes and applications are not described clearly and mostly incomprehensibly for older people and are not sufficiently explained.
Changes and applications are not described clearly and mostly incomprehensibly for older people and are not sufficiently explained.
Changes and applications are not described clearly and mostly incomprehensibly for older people and are not sufficiently explained.
Designing a tailored, mobile-friendly accessibility annotation kit
While PAYBACK’s product design system is based on platform guidelines which provide built-in accessibility support by Material Design (Android) and Apple Human Interface Guidelines (iOS), many components had been customized to meet specific brand and functional needs. These customizations including icon replacements, altered visual hierarchies, and composite components, often introduced ambiguity in semantics and unexpected behavior in screen readers.
To better address these challenges, I conducted a focused review of WCAG 2.1 to identify success criteria most relevant to mobile UI, such as focus order, semantic structure, and labeling. I aimed to understand how each criterion directly impacts screen reader interpretation and user flow. This analysis helped define which elements required annotation and how accessibility information should be structured for clarity and consistency across design and development.
Recognizing that accessibility needs to be embedded into everyday workflows, I aimed to find a practical way to communicate accessibility intent across disciplines. While accessibility knowledge is important for all team members, the real challenge was making it easy for designers to annotate within their tools and clear enough for developers to interpret and implement without ambiguity.
To address this, I conducted a comparative review of publicly available accessibility annotation kits from IBM, Indeed, and CVS Health. These kits represent thoughtful efforts to bring structure and consistency to accessibility documentation, and provided valuable references during the early stages of this project. However, most were primarily designed for web or desktop contexts and required adaptation to meet the specific needs of PAYBACK’s mobile environment, particularly in supporting mobile conventions and integrating smoothly into everyday design workflows.
These insights helped shape a new annotation kit tailored to PAYBACK’s context. The kit was designed to be platform-aware, lightweight, easy to use in Figma, and structured to facilitate collaboration and shared understanding between designers and developers.
While PAYBACK’s product design system is based on platform guidelines which provide built-in accessibility support by Material Design (Android) and Apple Human Interface Guidelines (iOS), many components had been customized to meet specific brand and functional needs. These customizations including icon replacements, altered visual hierarchies, and composite components, often introduced ambiguity in semantics and unexpected behavior in screen readers.
To better address these challenges, I conducted a focused review of WCAG 2.1 to identify success criteria most relevant to mobile UI, such as focus order, semantic structure, and labeling. I aimed to understand how each criterion directly impacts screen reader interpretation and user flow. This analysis helped define which elements required annotation and how accessibility information should be structured for clarity and consistency across design and development.
Recognizing that accessibility needs to be embedded into everyday workflows, I aimed to find a practical way to communicate accessibility intent across disciplines. While accessibility knowledge is important for all team members, the real challenge was making it easy for designers to annotate within their tools and clear enough for developers to interpret and implement without ambiguity.
To address this, I conducted a comparative review of publicly available accessibility annotation kits from IBM, Indeed, and CVS Health. These kits represent thoughtful efforts to bring structure and consistency to accessibility documentation, and provided valuable references during the early stages of this project. However, most were primarily designed for web or desktop contexts and required adaptation to meet the specific needs of PAYBACK’s mobile environment, particularly in supporting mobile conventions and integrating smoothly into everyday design workflows.
These insights helped shape a new annotation kit tailored to PAYBACK’s context. The kit was designed to be platform-aware, lightweight, easy to use in Figma, and structured to facilitate collaboration and shared understanding between designers and developers.
Approach
Integrating accessibility into real UX workflows
To make accessibility a part of our everyday design process, I mapped out how the annotation kit could be integrated into our existing workflow embedding it not as an extra step, but as something that flows naturally across the design and development cycle.
The kit was applied across multiple iterative stages to show how accessibility considerations could be incorporated into real-world practice from the start:
UI Design: design includes both system-level components and screen-level layouts.
Accessibility Annotation: Designers apply annotations directly within the design files.
Cross-role Annotation Review: Before implementation, designers, product owners, and developers review annotations together to align expectations.
Design-to-Dev Handoff: Developers begin implementation using the annotated designs as reference.
Post-release Check: After development, a QA session ensures that accessibility requirements were implemented correctly.
Rather than treating accessibility as a linear checklist, each stage was tested and refined through actual projects—showing how semantic accessibility could be shared, reviewed, and implemented collaboratively across roles. By making accessibility a shared responsibility, we were able to embed inclusive thinking into the heart of our everyday product workflow.
To make accessibility a part of our everyday design process, I mapped out how the annotation kit could be integrated into our existing workflow embedding it not as an extra step, but as something that flows naturally across the design and development cycle.
The kit was applied across multiple iterative stages to show how accessibility considerations could be incorporated into real-world practice from the start:
UI Design: design includes both system-level components and screen-level layouts.
Accessibility Annotation: Designers apply annotations directly within the design files.
Cross-role Annotation Review: Before implementation, designers, product owners, and developers review annotations together to align expectations.
Design-to-Dev Handoff: Developers begin implementation using the annotated designs as reference.
Post-release Check: After development, a QA session ensures that accessibility requirements were implemented correctly.
Rather than treating accessibility as a linear checklist, each stage was tested and refined through actual projects—showing how semantic accessibility could be shared, reviewed, and implemented collaboratively across roles. By making accessibility a shared responsibility, we were able to embed inclusive thinking into the heart of our everyday product workflow.
From research to practice to ongoing refinement
This timeline outlines the development of an accessibility annotation kit aimed at improving how accessibility information is communicated throughout the product design process.
The project began in February with an initial round of accessibility audits and foundational research, followed by a comparative review of existing annotation kits and a deep dive into WCAG 2.1. The goal was to understand common accessibility breakdowns in real product interfaces and to explore how design teams could surface semantic information more clearly and consistently.
In parallel, I began designing and applying the first version of the annotation kit. Feedback from actual use revealed areas for improvement, leading to further iteration in May. Throughout this process, WCAG remained a key reference point—not just as a standard, but as a guide for prioritizing what to annotate and how to make that information actionable across roles.
The kit continues to evolve as part of an ongoing effort. Rather than a static tool, it is being refined based on observed issues, team feedback, and the needs of our mobile product context.
This timeline outlines the development of an accessibility annotation kit aimed at improving how accessibility information is communicated throughout the product design process.
The project began in February with an initial round of accessibility audits and foundational research, followed by a comparative review of existing annotation kits and a deep dive into WCAG 2.1. The goal was to understand common accessibility breakdowns in real product interfaces and to explore how design teams could surface semantic information more clearly and consistently.
In parallel, I began designing and applying the first version of the annotation kit. Feedback from actual use revealed areas for improvement, leading to further iteration in May. Throughout this process, WCAG remained a key reference point—not just as a standard, but as a guide for prioritizing what to annotate and how to make that information actionable across roles.
The kit continues to evolve as part of an ongoing effort. Rather than a static tool, it is being refined based on observed issues, team feedback, and the needs of our mobile product context.
Insights from the First Accessibility Audit
To validate and refine the annotation kit, I selected the Coupon Center feature; where users browse and activate digital coupons in the PAYBACK app. This feature is a high-traffic area and an ideal candidate for testing accessibility improvements.
To better understand the user experience, I conducted hands-on accessibility audits using both TalkBack (Android) and VoiceOver (iOS), simulating how screen reader users interact with the interface. This practical approach helped move beyond static audits and uncover issues from a real user interaction perspective.
Several key accessibility problems were identified:
Missing or unclear labels: Coupon items did not read out partner brand names, and ad images from the CMS lacked alt text, making content hard to understand.
Lack of contextual information: Tabs provided no indication of how many coupons were inside, and the label “°P” (used for PAYBACK points) was read aloud as “grad P,” confusing users.
Focus order issues: The reading order did not follow a logical top-down sequence. Critically, it skipped the “Activate Coupon” button, preventing efficient interaction.
These findings directly shaped the practical requirements of the annotation kit, emphasizing the need for label specificity, semantic clarity, and logical navigation flow. They also established clear benchmarks for success: the kit should enable designers to identify and annotate such issues early, and support developers in resolving them efficiently during implementation.
To validate and refine the annotation kit, I selected the Coupon Center feature; where users browse and activate digital coupons in the PAYBACK app. This feature is a high-traffic area and an ideal candidate for testing accessibility improvements.
To better understand the user experience, I conducted hands-on accessibility audits using both TalkBack (Android) and VoiceOver (iOS), simulating how screen reader users interact with the interface. This practical approach helped move beyond static audits and uncover issues from a real user interaction perspective.
Several key accessibility problems were identified:
Missing or unclear labels: Coupon items did not read out partner brand names, and ad images from the CMS lacked alt text, making content hard to understand.
Lack of contextual information: Tabs provided no indication of how many coupons were inside, and the label “°P” (used for PAYBACK points) was read aloud as “grad P,” confusing users.
Focus order issues: The reading order did not follow a logical top-down sequence. Critically, it skipped the “Activate Coupon” button, preventing efficient interaction.
These findings directly shaped the practical requirements of the annotation kit, emphasizing the need for label specificity, semantic clarity, and logical navigation flow. They also established clear benchmarks for success: the kit should enable designers to identify and annotate such issues early, and support developers in resolving them efficiently during implementation.
Design process
Designing the first version of the kit
Designing the first version of the kit
To support accessibility handoffs within our design tool, I created the first version of the annotation kit directly in Figma. The kit is organized into five key annotation categories: A11y Label, Reading & Focus Order, Input Purpose, Headings, Buttons & Links.
To ensure clarity without disrupting the UI layout, I used sticker-style overlays—visual markers placed on top of the design. These helped communicate semantic intent, like interaction flow or screen reader behavior, in a way that was easy for both designers and developers to understand.
To support accessibility handoffs within our design tool, I created the first version of the annotation kit directly in Figma. The kit is organized into five key annotation categories: A11y Label, Reading & Focus Order, Input Purpose, Headings, Buttons & Links.
To ensure clarity without disrupting the UI layout, I used sticker-style overlays—visual markers placed on top of the design. These helped communicate semantic intent, like interaction flow or screen reader behavior, in a way that was easy for both designers and developers to understand.
A11y Label
Accessibility Labels provide meaningful descriptions for non-text elements like icons or images, helping screen reader users understand their purpose. This aligns with WCAG 1.1.1 and 4.1.2.
assign
When the contents coming from CMS,
assign
Reading Order & Focus Order
Reading and Focus Order define how content is announced and navigated by screen readers. Ensuring a logical sequence improves both usability and interaction, in line with WCAG 1.3.2 and 2.4.3.
assign
Input Purpose
Input Purpose identifies what each input field is for—like name or email—so assistive technologies can offer contextual support. This follows WCAG 1.3.5.
assign
Headings
Headings are used to mark visual hierarchy and structure, helping users navigate screens more efficiently. This supports WCAG 1.3.1 and 2.4.6.
assign
Buttons & Links
Buttons and Links are clearly differentiated to avoid confusion, indicating whether an element performs an action or navigates elsewhere. This corresponds to WCAG 2.4.4 and 4.1.2.
assign
Observed issues from the first design
Observed issues from the first design
The first version of the annotation kit was tested over six weeks across several mobile design projects. During this period, I gathered feedback from both designers and developers to understand how well the kit functioned in real use.
One of the earliest challenges involved accessibility labels. Since designers had to write custom descriptions, the outputs were often inconsistent—some overly detailed, others too vague. This revealed a need for more concrete examples and clearer writing guidelines.
Accessibility Labels: Designers interpreted labels differently—some were too vague, others too long. I added writing guidelines and examples to encourage concise, meaningful, and consistent labeling.
Reading Order vs. Focus Order: Many confused the two concepts. I clarified their definitions and added platform-specific examples to help annotate both reading flow and interaction path correctly.
Headings: Initially followed web-based H1–H6 levels, which don’t apply to mobile platforms. I revised this to reflect how native traits like “Heading” are used in iOS and Android for assistive navigation.
Buttons and Links: Early annotations assumed web conventions. I later documented that in mobile environments, links are not semantically distinct from buttons—and updated the kit to reflect platform behavior.
Grouping: Fragmented screen reader output revealed the need to group related elements. I introduced a new category for grouping annotations, allowing designers to define more coherent reading experiences.
These observed issues and feedback from the initial application directly informed the second iteration of the Accessibility Handoff Design Kit, with a focus on improving clarity, consistency, and usability across both design and development workflows.
The first version of the annotation kit was tested over six weeks across several mobile design projects. During this period, I gathered feedback from both designers and developers to understand how well the kit functioned in real use.
One of the earliest challenges involved accessibility labels. Since designers had to write custom descriptions, the outputs were often inconsistent—some overly detailed, others too vague. This revealed a need for more concrete examples and clearer writing guidelines.
Accessibility Labels: Designers interpreted labels differently—some were too vague, others too long. I added writing guidelines and examples to encourage concise, meaningful, and consistent labeling.
Reading Order vs. Focus Order: Many confused the two concepts. I clarified their definitions and added platform-specific examples to help annotate both reading flow and interaction path correctly.
Headings: Initially followed web-based H1–H6 levels, which don’t apply to mobile platforms. I revised this to reflect how native traits like “Heading” are used in iOS and Android for assistive navigation.
Buttons and Links: Early annotations assumed web conventions. I later documented that in mobile environments, links are not semantically distinct from buttons—and updated the kit to reflect platform behavior.
Grouping: Fragmented screen reader output revealed the need to group related elements. I introduced a new category for grouping annotations, allowing designers to define more coherent reading experiences.
These observed issues and feedback from the initial application directly informed the second iteration of the Accessibility Handoff Design Kit, with a focus on improving clarity, consistency, and usability across both design and development workflows.
Designing the first version of the kit
Designing the first version of the kit
발견한 문제점을 토대로 리디자인 그리고 이번에는 documentation을 강화했다. 왜 우리 프로덕트에서 접근성이 중요한지, 어떤 유저들이 영향을 미치는지, 접근성과 관련해서 어떤 부서에서 어떤 일을 맡으며 특히 WCAG에 따라 UX 디자이너들의 역할이 무엇인지 등에 대한 문서와 함께 각각의
발견한 문제점을 토대로 리디자인 그리고 이번에는 documentation을 강화했다. 왜 우리 프로덕트에서 접근성이 중요한지, 어떤 유저들이 영향을 미치는지, 접근성과 관련해서 어떤 부서에서 어떤 일을 맡으며 특히 WCAG에 따라 UX 디자이너들의 역할이 무엇인지 등에 대한 문서와 함께 각각의
A11y Label
Accessibility Labels provi
decision flow ,
Reading and Focus Order define how content is announced and navigated by screen readers. Ensuring a logical sequence improves both usability and interaction, in line with WCAG 1.3.2 and 2.4.3.
assign
Reading Order & Focus Order
Reading and Focus Order define how content is announced and navigated by screen readers. Ensuring a logical sequence improves both usability and interaction, in line with WCAG 1.3.2 and 2.4.3.
assign
Input Purpose
Input Purpose identifies what each input field is for—like name or email—so assistive technologies can offer contextual support. This follows WCAG 1.3.5.
assign
Headings
Headings are used to mark visual hierarchy and structure, helping users navigate screens more efficiently. This supports WCAG 1.3.1 and 2.4.6.
Buttons & Links
Buttons and Links are clearly differentiated to avoid confusion, indicating whether an element performs an action or navigates elsewhere. This corresponds to WCAG 2.4.4 and 4.1.2.
Checklist
Checklist
발견한 문제점을 토대로 리디자인
발견한 문제점을 토대로 리디자인
Handoff
Handoff
어떻게 handoff 했나?
어떻게 handoff 했나?
Validation
How the feature became accessible
How the feature became accessible
쿠폰센터
first audit
쿠폰센터
first audit
Gathering feedback from the team
Gathering feedback from the team
To evaluate the internal usefulness of the annotation kit, I conducted a short survey with designers and developers.
For designers, I asked how easy it was to use the kit during their design process. For developers, the questions focused on whether the annotations were understandable and helpful during implementation. Each question used a 10-point Likert scale, followed by an open-ended section for qualitative feedback.
This survey aims to assess how effectively the kit supports accessibility collaboration in practice. It is currently ongoing, and the insights will be used to improve the kit and update the process moving forward.
To evaluate the internal usefulness of the annotation kit, I conducted a short survey with designers and developers.
For designers, I asked how easy it was to use the kit during their design process. For developers, the questions focused on whether the annotations were understandable and helpful during implementation. Each question used a 10-point Likert scale, followed by an open-ended section for qualitative feedback.
This survey aims to assess how effectively the kit supports accessibility collaboration in practice. It is currently ongoing, and the insights will be used to improve the kit and update the process moving forward.
Reflection
Inclusive design in mind
Inclusive design in mind
Working on this project made me rethink what accessibility means in practice. It’s not just about visual contrast or screen reader support—it’s about designing for inclusion from the start, and clearly communicating those design decisions to the people building the product.
Designing and iterating on this annotation kit showed me that accessibility must be embedded into the design process through standardized patterns and shared responsibility. When accessibility is considered early, many issues don’t need to be fixed later—they simply don’t happen.
This project is still ongoing. As the kit is applied to more product areas and as the design system evolves, I expect new challenges will emerge. But each of these is an opportunity to improve and align better with inclusive design goals.
Going forward, I see potential to expand the kit beyond mobile, integrate it into design systems, and support broader adoption through onboarding resources. Most of all, this experience taught me that meaningful accessibility requires structure, feedback, and a mindset shift across the entire team—it’s not a checkbox, but a long-term, shared effort.
Working on this project made me rethink what accessibility means in practice. It’s not just about visual contrast or screen reader support—it’s about designing for inclusion from the start, and clearly communicating those design decisions to the people building the product.
Designing and iterating on this annotation kit showed me that accessibility must be embedded into the design process through standardized patterns and shared responsibility. When accessibility is considered early, many issues don’t need to be fixed later—they simply don’t happen.
This project is still ongoing. As the kit is applied to more product areas and as the design system evolves, I expect new challenges will emerge. But each of these is an opportunity to improve and align better with inclusive design goals.
Going forward, I see potential to expand the kit beyond mobile, integrate it into design systems, and support broader adoption through onboarding resources. Most of all, this experience taught me that meaningful accessibility requires structure, feedback, and a mindset shift across the entire team—it’s not a checkbox, but a long-term, shared effort.
