Projects at Cybozu anchor
In Cybozu my work is focused on ensuring our products are accessible and follow WCAG 2.2 guidelines out of the gate. For this I have created a framework and guidelines for each step of the development process.
I also create and provide trainings for product teams (product managers, design, writing and development), support QA efforts and audit our products as they are being developed.
My product work is mainly focused onto our design system, which I have audited and for which I am writing a complete set of accessibility focused documentation.
This section does not contain any screenshots as everything is currently under NDA and not public. I hope to be able to adopt the frameworks I have written into an open source form in the future.
Writing accessibility guidelines anchor
Helping teams to create accessible products is always a balance between wanting to support the most users possible, following guidelines and staying practicable. As an accessibility practitioner I need to strike this balance daily and guide the teams I work with to succeed.
Working in Cybozu I am very lucky to work with people who have some awareness of accessibility already. Besides trainings and audits, we have the goal for each team to create their work as accessible as possible independently. To support this I have written a set of accessibility guidelines.
It starts with the “Accessibility strategy and compliance plan” which outlines the teams “Commitment to WCAG 2.2 Level AA Compliance” and the reasoning for following WCAG in the first place. The plan then outlines in more detail each team’s role, including my own, time lines and goals to be archived by the time of the first public release of our products.
Following this each team has their own guidelines, with explanations, checklists and resource lists. In order to shift left, the product management team has guidelines to write Product Requirement Documents (PRD) which include accessibility requirements.
The Design team got the longest and most comprehensive document, as many issues can be caught during the design process. As our design team also includes a group of dedicated writers I prepared a set of guidelines for them as well.
The development team’s document was made up of both: a longer introduction of HTML and the DOM as well as Wai-Aria and how we can automated code checking to aid the development process. Since development happens in React, there is a disconnect between what the engineer writes and what the end user interacts with in the browser. This disconnect is not easy to overcome. Therefore the guidelines and training sessions contain sections on HTML.
Finally, I created an extra document and kanban board for our risk management efforts. The idea behind it is to track accessibility issues and discuss their prioritisation regularly between product and project managers and the accessibility specialist.
All of these guidelines have been adopted and are considered living documents which are jointly maintained by myself and each team.
project meta data anchor
tasks & tools
- guideline writing
- risk management
- department wide training
- stakeholder management
time
2024
position
Accessibility Specialist
Making a design system accessible anchor
When I joined Cybozu, the new business design system had already been created and was in a mode of adding the last needed components. It is designed in Figma and the system itself is based of React and is hosted in Storybook.
My first task was to audit all components and ensure they were accessibly designed and coded. More complex components were tested on Mac (Safari + VoiceOver, Firefox and Chrome) and Windows (JAWS + Chrome, Firefox and Edge, NVDA + Chrome, Firefox and Edge and Narrator + Edge).
As we were adding new components, I was involved in each step of the process from designing to developing, working closely with designers and engineers.
Following the initial audit was a more complete quality assurance and documentation. Quality assurance was necessary as it turned out that there were discrepancies between the Figma designs and Storybook implementations.
Finally, the documentation process included creating an updated template in storybook, to better meet overall documentation of all aspects of a component from design over development and finally accessibility.
Each component received a full documentation of how to used it most effectively and accessibly. Taking a page from the Web Accessibility Initiatives ARIA Authoring Practices Guide, I also added keyboard interactions and where needed roles and (aria-) attributes documentations.
This is still an ongoing project and we hope to open source the design system at some point.
project meta data anchor
tasks & tools
- auditing design & code, testing and quality assurance
- accessibility related documentation
- stakeholder management
time
2023 to present
position
Accessibility Specialist