Cross-Platform Accessibility Improvement Activities
This article is originally posted in Japanese as the 8th entry in the "Pairs Engineering Advent Calendar 2024."
Over the past year, we have been working on cross-platform accessibility improvement activities for iOS, Android, and Web within Eureka. In this article, I would like to share the content of these activities and the insights we have gained.
This article is intended for those who want to start accessibility improvement activities within their company or are interested in cross-platform accessibility improvements.
1. Introduction
The matching app "Pairs" operated by our company is available on three platforms: iOS, Android, and Web. Until now, I have been working on accessibility improvements within the Web team I belong to. However, I realized that this was not sufficient for improving the app overall, including iOS and Android, so I decided to start cross-platform accessibility improvements.
Moreover, Pairs has a basic policy of providing the same functionality across all platforms. Since we aim for consistency in both functionality and design, we thought it would be efficient to proceed with accessibility improvements across platforms simultaneously.
2. Launching the Activity: Member Recruitment
The first step in the activity was to start by recruiting members.
The recruitment goals were:
- One iOS Engineer
- One Android Engineer
- One Web Engineer
- One Designer
I approached colleagues who seemed interested in accessibility directly and asked managers of each team to recommend members who might be interested. Fortunately, there were many members within the company with a high interest in accessibility, and we were able to achieve our recruitment goals successfully. This allowed us to launch a cross-platform accessibility team.
In the kickoff meeting, we aligned on the background and objectives of the activities and set the following four activity goals:
- Formulate accessibility guidelines
- Apply guidelines to future screens of our application
- Apply guidelines to existing screens of our application
- Communicate accessibility improvement efforts externally
Additionally, we held study sessions to share basic knowledge about accessibility among members and practical workshops to experience actual OS accessibility features.
The "Web Accessibility Introduction Guidebook" published by the Digital Agency of the Japanese government was extremely useful in creating materials for study sessions on basic accessibility knowledge.
3. Early Stages: Formulating Guidelines and Promoting Understanding
In the early stages of the activity, we first embarked on formulating accessibility guidelines. We believed that having a common standard and language was crucial for efficiently advancing accessibility improvement activities. While each platform—iOS, Android, and Web—has standard guidelines to refer to, there was no unified directive in the UI design domain.
Therefore, we decided to adopt the accessibility guidelines published by freee K.K. These guidelines were selected because they suited our needs, featuring:
- Based on WCAG 2.1, a web standard
- Compatible with all platforms: iOS, Android, Web
- A comprehensive checklist for the design phase
After adopting the guidelines, we regularly held one-hour weekly reading sessions to enhance understanding within the team. Due to the extensive nature of the guideline items, we focused on critical items with a "severity" of MAJOR
or higher, considering business impact. During the review of each item, we discussed the following aspects:
- Possible applicable areas within the Pairs service
- Estimated effort needed for improvements
- Technical challenges in implementation
(It took about three months to complete the review…)
4. Main Activities: Continuous Improvement through Regular Meetings
After completing the formulation and understanding of the guidelines, we started the full-scale improvement activities.
The participating members have their primary duties outside the accessibility activity. Therefore, we concentrated the activity time into one-hour weekly regular meetings and aimed to conclude as much as possible within the meeting time to minimize the burden on members.
The agenda for the regular meeting includes:
- Progress and topic sharing (weekly)
- Accessibility review of new designs (weekly)
- Accessibility review of the design system (bi-weekly)
- Accessibility improvement work (bi-weekly)
Details of each agenda:
Progress and Topic Sharing (Weekly)
This is a time for each member to share their weekly progress and topics they want to discuss. Through discussions on how to proceed with the activities and any concerns, we ensure the sustainability and continuous improvement of the activities.
Accessibility Review of New Designs (Weekly)
Since Pairs is a product that frequently develops new features, ensuring the accessibility of new UIs is crucial. When the design is nearly complete, the designer member presents the design, and all members conduct a review from an accessibility perspective.
If issues are identified, a request for correction is made to the responsible designer, and the engineer responsible for feature development implements the corrected design. However, currently, accessibility corrections do not block the release of functionalities. Therefore, if accessibility cannot be addressed during feature development due to reasons such as workload, it is logged into the accessibility team's backlog.
This initiative enables early detection and resolution of accessibility issues in new designs and dissemination of accessibility knowledge across the entire designer organization.
Accessibility Review of the Design System (Bi-weekly)
Improving the accessibility of common UI components defined in the design system is a priority due to its significant impact across the app.
If issues are identified, a solution is devised on the spot and added to the improvement backlog for the corrected design.
Accessibility Improvement Work (Bi-weekly)
This is the work time to actually correct issues identified in the aforementioned accessibility reviews of new designs and the design system. Designers refine the Figma design, and engineers make codebase corrections.
To efficiently utilize the limited one-hour per week, agendas with high time sensitivity ("Progress and Topic Sharing" and "Accessibility Review of New Designs") are held weekly, while other agendas are alternated bi-weekly.
5. Improvement Achievements
Throughout these efforts, we have been able to release multiple improvement measures into the production environment. Here, I would like to introduce a representative example: improving the visibility of text links.
Previously, text links in the Pairs app were distinguished from regular text solely by blue font color. However, for users with color blindness, it could be challenging to discern links in this manner (non-compliance with WCAG 1.4.1 Use of Color).
To address this issue, we implemented a setting feature that allows users to change the display method of text links based on their preferences.
Users can enable the following settings:
- iOS: Turn on "Button Shapes" from the OS accessibility settings screen
- Android and Web: Turn on "Underline Text Links" from the Pairs app's accessibility settings screen
This results in underlined text links in the app.
This change provides visual differentiation through underlines in addition to color information, creating a more accessible interface for a broader range of users.
6. Increasing Internal Awareness
Our company holds a monthly company-wide meeting for release reports and knowledge sharing by each team. We utilize this opportunity to regularly communicate the progress and achievements of accessibility improvement activities to enhance internal awareness.
Increasing awareness within the company is a crucial factor in driving future improvement activities. The reasons are:
- Share a basic understanding of the necessity of accessibility improvement, leading to smoother dialogues with stakeholders outside the improvement team
- Cultivation of an organizational culture where consideration for accessibility is a given
- Acquisition of new perspectives from members not directly involved in the improvement activities
7. Lessons Learned from the Activities
Over the past year, we have gained numerous insights through cross-platform accessibility activities.
Finding Allies
Improving accessibility for a multi-platform, multi-functional app like Pairs involves a substantial amount of work and requires specialized knowledge for each platform, making it challenging for individual efforts. By finding members with the same resolve from each team within the company and collaborating, not only did the workload per person decrease, but we also incorporated opinions from various perspectives, and most importantly, we could conduct activities with a sense of security.
Starting Small
When the internal awareness of accessibility is still low, it is not realistic to suddenly declare, "Accessibility compliance will be a mandatory condition for product development!" Starting with small-scale initiatives, steadily accumulating improvements, gradually increasing internal awareness, and ultimately aiming for a state where accessibility compliance is naturally incorporated into the development process is an effective approach.
Leaving No Tasks Outside Activity Hours
Volunteer activities without strong business support require continuity. By adopting a style where members gather for a one-hour weekly regular meeting, and complete discussions and tasks within the meeting time without leaving any unresolved issues, we minimized the impact on each member's regular work and lowered the barrier to participation in improvement activities.
Cementing Knowledge through Practice
To solidify the vast knowledge of the guidelines, we picked several screens from the Pairs app and conducted compliance checks against the guidelines over several weeks. This allowed us to learn the theory in practice, establishing a foundation of knowledge necessary for accessibility reviews of designs.
Continuously Improving the Activity Itself
Continuing regular meetings in the same style often leads to the mechanism becoming outdated due to changes in the surrounding environment. To avoid this, we incorporated time for discussions on the meeting agenda, enabling regular discussions about how to proceed with the activities. The current activity format was established through such discussions, and we intend to continue evolving the activity itself as needed.
This concludes the story of working on cross-platform accessibility improvements within the company over the past year.
There are still many things to be done, such as accessibility checks and improvements for existing app screens and making accessibility reviews a mandatory part of the new development process. However, based on the mechanisms and insights gained from our activities so far, we will continue to work on accessibility improvements, evolving them as we proceed.