Starting Bentley's Accessibility Working Group

The problem

Bentley had accessibility efforts already, but it didn’t have a shared one.

Different teams worked to different standards in isolation, with a web team applying one set of practices, a communications group another, and academic technology somewhere else again. Nobody had a picture of what the university was collectively doing, and there was no persistent place to look up how to do it right, so every new hire, every new site and every new email template started the conversation over.

Expertise wasn’t the problem, since plenty of people at Bentley knew accessibility mattered and some knew it deeply. The problem was that the knowledge lived in people’s heads, in scattered departments, with no mechanism to pool it or pass it on.

What I proposed

A cross-departmental working group that would take stock of what was already happening, decide what good looked like for Bentley specifically, and leave behind something durable. Four objectives: review the current state, build an improvement plan for the platforms we controlled, create documentation for the teams we didn’t control, and treat the whole thing as teaching rather than enforcement.

We narrowed down the focus areas by weighing two things for each one: how much it affected users, and how many roles touched it in some way. The resulting site has two tiers. The Introductory Guidelines cover eight high-level topics — color contrast, assistive technology, cognitive accessibility and sensory management, and structuring and styling content, to name a few. The Advanced Guidelines go deeper and split by role into three tracks: content and production, design and development, and compliance.

Where each topic appears in the accessibility resource

Topic	Introductory	Advanced
		Content & Production	Design & Development	Compliance
Color Contrast	Yes	No	Yes	No
Images	Yes	Yes	Yes	No
Video	Yes	Yes	No	No
Assistive Technology	Yes	Yes	Yes	Yes
Cognitive Accessibility and Sensory Management	Yes	Yes	No	Yes
Structuring and Styling Content	Yes	Yes	No	No
Keyboard Accessibility	Yes	No	Yes	No
Tools for Checking Accessibility	Yes	Yes	Yes	No
Forms	No	No	Yes	No
Accessibility for Developers	No	No	Yes	No
Legal Compliance and the ADA	No	No	No	Yes
Working with Vendors or Third-party Products	No	No	No	Yes

I also designed how the group would work: two co-leads with complementary expertise (UX and development for me, legal and policy for my co-lead), members drawn from different departments with a wide variety of skill sets, an hour-long meeting twice a month, and contributions kept voluntary and secondary to everyone’s primary work.

What happened

The group came together at 15 members, larger than the eight to ten I’d scoped, and met monthly for about a year and a half. It produced an intranet site for the Bentley community: a resource teaching faculty and staff how to build accessibility into their own work.

The site idea came out of a constraint — there was no way the group could go around fixing accessibility issues on its own, but we could define standards and teach others the general principles and how they tie into their own work. Most accessibility guidance is written for developers, so everyone who isn’t a developer reasonably concludes it isn’t for them, and then keeps putting text inside images, picking heading levels by how they look, and publishing uncaptioned video.

The educational aspect extended past the group. I co-presented Designing for Everyone: The Essentials of Digital Accessibility at the Bentley Alumni Conference with Steph Bohler, the group’s co-lead. We continue to teach the importance of digital accessibility when the opportunity presents itself.