WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Known accessibility hurdles with popular design systems

for

From: Brooks Newton
Date: Jan 15, 2021 1:18PM

Thanks for the link, Birkir. I've looked through some of those resources
already, and will check out the others I haven't yet reviewed. Thank you!

I'm wondering if folks have found known accessibility issues in popular
Design Systems, such as the ones listed in this 2019 article "10 Best
Design Systems for 2019
<https://www.webdesignerdepot.com/2019/08/10-best-design-systems-for-2019/>
":

- Material
- Fluent
- Shopify Polaris
- Mailchimp
- Atlassian
- Apple
- IBM Design Language
- AirBnB
- Uber
- Lightning Design System

I've worked with a number of production teams who automatically assume that
if it is a big name Design System and/or JS Framework, then it must already
be vetted and fully approved for accessible use by people with
disabilities. Are there any accessibility specialists who are reading this
who have encountered the same assumptions on the part of their teammates
who don't know much about accessibility? How do those assumptions match up
with the reality of your testing? Should this community work together to
test what the out of the box design system and/or framework provides, in
terms of WCAG compliance? What about providing comprehensive guidance to
help unknowing but well-intended production teams get their brand name
frameworks, pattern libraries and style guides remediated for
accessibility? Should we consider other accessibility benchmarks that may
offer a more reliable measure of accessibility performance in fact versus
in theory?

It can be overwhelming, even frightening to take on the full brunt of the
accessibility problems a site can have as a lone organization, or worse
yet, as a lone accessibility specialist. In this forum and via other
accessibility venues, I hear a lot of talk about in the weeds accessibility
issues that content authors are required to take on themselves in
isolation. But, I don't hear nearly as much talk about putting our minds
together and trying to assess and fix known platform accessibility issues
at a more centralized and efficient spot - such as at the Design System or
JS Framework level. Why is that?

Believe you me, I've got many ideas along these lines that have sprung from
my frustration at bailing water out of the proverbial accessibility boat
while taking on massive leaks from centralized sources that are frankly,
beyond the scope of what individual content authors and site owners are
best positioned to tackle. Who is in the best position to tackle
accessibility problems at a centralized location?

Brooks Newton


On Fri, Jan 15, 2021 at 10:40 AM Birkir R. Gunnarsson <
<EMAIL REMOVED> > wrote:

> check out
> https://www.webaxe.org/web-accessible-code-library-design-systems-patterns/
> It's a place to start.
>
>
> On 1/12/21, Brooks Newton < <EMAIL REMOVED> > wrote:
> > Hello All,
> >
> > Similar to my previous post, I've got a question for everyone. Does
> anyone
> > know of a collection of known accessibility hurdles associated with the
> > most popular design systems in use today by web site production teams?
> If
> > there isn't any one authoritative collection, then maybe folks on this
> > discussion list can supply their own observations from implementing and
> > testing design systems in their own work. The observed hurdles can be
> > WCAG-related or outside of the formal WCAG umbrella.
> >
> > Wouldn't it be wonderful if site owners and content authors could have a
> > clear understanding of the baked-in accessibility problems they will
> > inherit when they adopt a design system to support their organization's
> > needs?
> >
> > Thanks!
> >
> > Brooks Newton
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
Virus-free.
www.avg.com
<http://www.avg.com/email-signature?utm_medium=email&;utm_source=link&utm_campaign=sig-email&utm_content=webmail>
<#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2>