Making Meetings Accessible

Apr 3, 2013 by Chris Higgins in meeting technology (2 minute read)


We strive to make software that "just works."

That's a core value we feel makes Lucid Meetings different from competitors -- we cut out the hassles you face with plugins, we make sure our software works beautifully on mobile devices (in case you want to join a meeting on your smartphone or tablet), and we strive to reduce clutter wherever we can.

Image: Single switch with a hand, by Flickr user vtsaran, used under Creative Commons license.

But there's a challenge here: What does "it just works" mean for someone who can't see the screen? And it's not just visual impairments -- what about people who can't type, and thus use voice-recognition software to navigate the web? Does our software work for them?

Recently we've started the journey to make Lucid Meetings "accessible," meaning that it "just works" for folks with visual, cognitive, motor, or other impairments.

We spent several days last week working with Derek Featherstone of Simply Accessible, learning about the landscape of accessibility and the current state of assistive technology as it's used online. Derek pointed out specific places within Lucid Meetings where some features currently don't "just work" for people using screen readers and other kinds of assistive technology. What we learned in those sessions drives how we will develop the next version of Lucid Meetings.

(Re)Designing for Web Accessibility

We're embarking on a redesign of Lucid Meetings to tackle, among other things, the challenges of accessible meetings. As we dive in, it's important to note that design isn't how something looks, it's how it works.

Accessible design is, in part, about understanding how things work for people who have very different needs and priorities than the people making the design. My "it just works" isn't your "it just works." So we have to go back to basics and ask fundamental questions about how we present information online.

Derek Featherstone started his presentation with an acronym that serves as a set of guideposts: "P.O.U.R." This stands for Perceivable, Operable, Understandable, and Robust.

While the details are at times complex, these notions are themselves simple. Is what we've designed clear and obvious? Are the words we use meaningful? Does it hold up well when conditions change (for instance, magnifying a small section of the screen, or globally increasing all font sizes, or being read aloud rather than read visually)?

These are the questions we now ask ourselves, in addition to the simpler questions of whether a given design "just works" for folks who don't use assistive technologies.

As Derek said: "Focuses on user needs, not technology." This is primarily a challenge in how we think about our users; the tech pieces are just how we meet those users where they are.

The Road Ahead

In the coming months, we'll post more about our redesign, and how accessibility (as well as other concerns, like internationalization) have shaped our choices. And that image above? It's how some people "click." Thanks to Flickr user vtsaran for sharing.

Try a sample meeting Start a free trial, no credit card required  

Recent Posts

Find this useful?