Laying accessibility groundwork in ownCloud’s new web interface

Web accessibility is a complex topic, especially in the context of JavaScript-based web applications. With its new web interface, ownCloud starts to tackle this topic to create a front-end usable for and accessible to everyone, regardless of their circumstances, abilities or technologies used.

By Marcus Herrmann, accessibility consultant and web developer

At the start of 2019, ownCloud team lead Michael Stingl approached me and asked whether I could support the accessibility aspect of ownClouds Project Phoenix. I was very pleased to say yes, especially once I learned that Phoenix was a) a web-app and b) written in Vue.js. The intersection of web accessibility and modern, framework-driven JavaScript is a fascinating topic for me, and additionally, Vue.js is my favourite framework.

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:

  1. 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.
  2. 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.
  3. 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.

In October and November of 2019, I also had the opportunity to work in the ‘machine room’ of both Project Phoenix and the ownCloud Design System. While doing so, I tried to emphasize accessibility basics but also the special idiosyncrasies that exist in JavaScript-based web apps. In these weeks, I approached the following topics:

  • 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/.

About the author

Avatar

Marcus Herrmann

is a freelance web developer and accessibility consultant. He blogs at https://marcus.io and currently writes an ebook about accessibility in Vue.js.

By continuing to use the site, you agree to the use of cookies. more information

The cookie settings on this website are set to "allow cookies" to give you the best browsing experience possible. If you continue to use this website without changing your cookie settings or you click "Accept" below then you are consenting to this.

Close