Accessible Design System in Angular, the Architecture.

Accessible Design System in Angular, the Architecture.

2 Primary Challenges addressed by 3 Design Philosophies & Dev Techniques.

I took a deep look into the inaccessible previous version in Angular.

Why did that not work?

It had  2 Primary Challenges.

  1. Property-driven components.
<rebel-component-one 
  [propOne]
  [propTwo]
  (eventThree)
>
</rebel-component-one>
Property-driven components.
  • Everything had to be a property and proxied-in.
  • Since every property needed had to be added in, it became inflexible for dev customization.
  • Component extensions were non-trivial. I wrote a wiki guide for it as well!
  • Improvements, extensions, enhancements, bug-fixes and support efforts were intensive in time and labor.

2. Wrapper component element tags on the DOM.

<rebel-component-one 
  [propOneNameNative]
  [propTwoName]
>
  <native-element
	[propOneNameNative]
	[propTwoName]	
  >
	…
  </native-element>
</rebel-component-one>
Wrapper component element tags on the DOM.
  • Every component was element-based.
  • Hence, had its own element tag on the DOM, presenting major challenges for a11y tools.
  • Element components proxied properties.
  • So, they were duplicated in the Angular component element tag, as well as the inner native element tags. Think value.
  • The above presented another hurdle to a11y tools.

Bottom line? The Angular component library had to be re-architected ground-up, literally and philosophically.

The New Architecture embodied 3 Philosophies & Techniques.

  1. Attribute Components & Directives
<div rebel-component-one> … </div>

<div rebelComponentOne> … </div>
Attribute Components & Directives
  • Based on the component being developed, I made the design choice for an attribute-selector based component or a directive.
  • The choice was on a case-by-case basis. If HTML had to be projected, we chose an attribute-selector based component design. Else, I considered directives.
  • Element-based component design was used when applicable. I didn’t want to make a change, just for the sake of it.
  • Less the count of breaking component design changes, the more conducive is the ease of version upgrade or migration for app dev community.

2.  Native Elements Leverage

<input rebel-component-one [value]>

<textarea rebelComponentOne [name]> … </textarea>
Native Elements Leverage
  • Using 1, enables use of native DOM elements and all the capability that is conducive for engineering and a11y.
  • Native properties and events can be used on the element.
  • Custom properties and events can be added as needed.
  • This allows for Dev and Design customization.

3. Compositional Component Architecture

<div rebel-component-one>
  <div rebel-component-child-one>
	<div rebel-component-grand-child-one>
	  …
	</div>
  </div>
</div>
Compositional Component Architecture
  • There are advantages in content, style and functionality at every element level.
  • Classes and elements can be added in or removed.
  • I thought through the App Dev experience in every decision, per component developed.

Be Thoughtful & Deliberate was the Mantra.

/PS: I made decisions in collaboration and consultation with the collective thoughts of my team. I combined my individual research and experimentation, along with their thoughts and feedback./


In the next episode, we will go over the Execution needed to build an Accessible Design System in Angular.

Thirumalaa Srinivas

Thirumalaa Srinivas