Michael then went into more detail: It would be perfect if I could help with improving the already existing ownCloud Design System (ODS) pattern library in multiple ways:
- Help building accessible components that can be used throughout the new interface, using the strength of a design system: Authors and developers would need to build and test an inclusive interface pattern once, and it could then be used all across the interface. In the bird’s eye view, an application consisting of well-built single parts is on a good path to become a truly inclusive one.
- Help with documentation: When certain components or controls a built in a certain way – what is the reasoning behind it? What user groups and which assistive technologies are affected? What circumstances and strategies could people have when they approach the interface? In the end, the documentation is intended to have two audiences: The core team members and associated freelancers, but also anyone else building extensions for the new front-end. For both groups, the design system should serve as a knowledge center: about the available components, for sure, but also about the design and markup decisions that went into them. Project Phoenix is being heavily worked on and will, especially when it comes to user experience and screen designs, go through further iterations. But the sometimes abstract, sometimes concrete documentation bits in ODS are meant to stand the test of time and to be educational resources for everyone working in the proximity of ownCloud’s new interface.
- Lastly to conduct occasional video calls or physical meetings where I can show to the team some strategies people with disabilities employ to use websites, and the tools developers have at their disposal to help them succeed. Over the last months, these occasional “accessibility session” also dealt with what needs to be done in the future, and I tried to make it clear, why something needs to be done in accessibility terms.
- Semantics of controls, and buttons vs. links
- The importance of accessible names and labels
- Communicating interstitial states in web apps, like a condition where a progress (e.g. upload) is running for a certain time (example)
- How an application or document can be structured non-visually with headline and/or ARIA landmark regions, and how skip links will help people who are not using a pointer device (such as mouse, or a touch surface)
- The virtue of hiding things accessibly, either from visual users, or from screen reader users without alienating the other group
- The concept of an accessible disclosure widget and where it could and should be used in an interface (example)
- The Basics of WAI-ARIA (example)
- That keyboard navigation is a cornerstone of accessibility, and that good usability in that regard oftentimes is passed on to assistive technology
- The concept of an “action menu” (a widget that emulates native application menus on the desktop, and triggers screen readers to go into a special mode) (example)
- How to build a tab module accessibly (example)
- The best way of implementing an accessible date picker (example)
- The central importance that all of the above should be tested with real users, and that building inclusive interfaces is not checking of a list, and real feedback from real people wins over dogmatism
All in all, especially the weeks in the fall were exciting times. In my project accessible-app.com I built a small dummy application to show some concepts, components and patterns. But of course a living, breathing and growing project like Phoenix was something else, and I really enjoyed it to work so close to the metal.
Still, in such a relatively short amount of time and in a growing and complex application like Phoenix it is impossible to boost the accessibility up to eleven. Nevertheless, I really hope to have helped facilitate laying the groundwork for accessibility knowledge, and that everyone will reap the rewards of this work in the near future. In the meantime, you can check out Phoenix’s progress at github.com/owncloud/phoenix/.