Accessible Design System in Angular, the Architecture.

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>

• 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>

• 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>

• 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>

• 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>

• 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.