On a Sandy Beach: ARIA and Design Systems

Mikes Notes

Pipi is primarily a workplace tool. One of Ajabbi's top objectives is to use technology to eliminate barriers so that disabled people can work as a fundamental human right.

The Pipi 9 Design System database has a draft set of UI component primitives to which any other design system components could be mapped.

The Pipi 9 Content Management System (CMS) always starts with these primitives (then calls the derived design system) when rendering UI on web pages.

I previously created a rough list of primitives. Then, I discovered that ARIA has a well-defined list of "patterns" that could be used as primitives.

ARIA list of "Patterns"

Solving several problems

Accessibility is not an afterthought.

Any Design System UI components would automatically be referenced to ARIA, and so work for disabled people.

ARIA is an accepted, robust international standard. Occasionally, the standards will be updated.

It answers the problem of what component primitives to use and how to name and describe them. It would also save a lot of work.

The page layout still works. And ARIA Roles would be the default names to use.

Nested components still work. ARIA will ignore the nesting.

The Design Tokens will not be affected.

The reference to ARIA in the Design System docs will be automated.

Unanswered questions

What happens with other languages? Are WAI-ARIA roles translated into Chinese, French, etc?

Are there Design System components that won't map to these primitives?

Is this the latest version of patterns? MDN and W3C ARIA have slightly different lists.

Next steps

Importing the ARIA "pattern" definitions.

Update the derived Pipi Design System.

Look at a series of existing websites that compare how different design systems implement the same component and what names they use. Try importing popular design systems, e.g. Bootstrap, Foundation, and Material, to ensure no mapping problems.