Accessibility is a framework problem

Accessibility symbol painted on a concrete floor

Thou shalt not curse the deaf, nor put a stumblingblock before the blind, but shalt fear thy God: I am the LORD.
Leviticus 19:14, The Bible

Recently, I read an old article by Leslie Cohn-Wein called Accessibility is not a "React Problem". I completely agree with this statement. Accessibility is not a React problem, it's a framework problem.

What I mean by this is that all JS frameworks have an accessibility problem. Let's take a look at the issues developers often overlook when creating websites.

What is accessibility?

The power of the Web is in its universality.
Access by everyone regardless of disability is an essential aspect.
Tim Burners-Lee, W3C Director and inventor of the World Wid Web

Accessibility, according to Wikipedia, is the design of products, devices, services, vehicles, or environments so as to be usable by people with disabilities.

It has a similar meaning when applied to the web:

Web accessibility means that websites, tools, and technologies are designed and developed so that people with disabilities can use them.
W3C, Web Accessibility Initiative

In layman terms, it's about designing with careful thought about all possible users.

By ensuring web accessibility, we are indirectly improving the user experience of our websites. This in turn improves the chances that almost every visitor would enjoy their stay on the site and gets what they need.

The opposite is true when we neglect accessibility. Site visitors suffer for our negligence and this could sometimes lead to early exits and frustration.

However, React (along with all other JS frameworks) doesn't seem to care.

The many, overlooked accessibility issues with React

`<div>` soup

JS frameworks are notorious for making <div> soup: infinite wrappers of <div>s for some HTML tags on your document created for no beneficial purpose at all.

For example, instead of this:

<div>
    <time>10:23:12</time>
    <time datetime="2015-03-02">MONDAY, 2 MARCH 2015</time>
</div>

React may create this:

<div>
    <div>
        <div>10:23:12</div>
        <div>MONDAY, 2 MARCH 2015</div>
    </div>
</div>

It may just be a few extra bytes for a little code, but you can easily see how it can add up and cause problems.

Each site visitor first has to download more HTML code than necessary (the definition of bloat) and the browser has to do more work to process the information. The visitor therefore pays for your incompetence with his battery life (if on mobile) and his time (waiting longer than necessary for information).

Also, notice that in the React example above, every tag on the page is a <div>. There is no easy way for web crawlers to parse the document for times and dates, unlike when using <time>.

There are even times that React creates far more bloat:

<div>
    <div>
        <div>
            <div>
                <p>Yeah, this can really happen!</p>
            </div>
        </div>
    </div>
</div>

Incorrect HTML semantics

All frameworks lack context so they don't know when to apply <h1> vs <h2> vs <h3> etc. This may seem insignificant, but using the wrong tag can mess up the flow of the document and screen readers.

Take for example a résume. Instead of:

<h1>John Doe</h1>
<p>Electrical engineer on a mission</p>

<h2>Work Experience</h2>
<h3>Apple Inc.</h3>
<p>Worked on the iPhone</p>

<h3>Google</h3>
<p>Worked on the Pixel</p>

<h2>Education</h2>

<!-- More info -->

They make this:

<h1>John Doe</h1>
<p>Electrical engineer on a mission</p>

<h1>Work Experience</h1>
<h2>Apple Inc.</h2>
<p>Worked on the iPhone</p>

<h3>Google</h3>
<p>Worked on the Pixel</p>

<h1>Education</h1>

<!-- More info -->

Note how <h3> is used before <h2> and <h1> is used repeatedly¹. Issues like this makes it difficult for bots and screen readers to make sense your website.

Inline styles

Writing inline CSS can make external stylesheets harder to manage and less predictable.

Compare the generic styling of this:

<h3 class="highlight-color">Title</h3>

To React using inline styles like this:

<h3 style="color: green">Title</h3>

Using inline styles overrides all external styles.

Broken focus

Focus is very easy if you lay out HTML tags properly (which they are by default). Frameworks lack context which makes it hard for them to properly manage focus.

Code held hostage

One of the tenets of Unix philosophy is to "avoid captive user interfaces". This also applies to frameworks.

Frameworks become captive user interfaces when they prevent you from modifying your own HTML code.

HTML is the foundation of every website. Choosing the right HTML tags becomes difficult when frameworks completely handle this step.

SEO crippling

An application that can only run in the client-side cannot serve HTML to crawlers.

Speed and performance impact

If the page is rendered on the client-side, the browser has to do more work to render the page, making loading slower.

Maintainability

Logic is often duplicated between the client and server.

Learning curve

Because JS frameworks go against web standards, you are always fighting an uphill battle. You have to recreate perfectly working browser functions like refreshing a page.

Methods employed by frameworks are experimental and are constantly changing. Web APIs are a lot more stable.

Lack of customization

You limit the amount of customization you can do with frameworks, since you already have your HTML held hostage.

The bottom line

Ditch the frameworks. Learn web standards and why they have been put in place. Make the web a place everyone can benefit from by caring about users and their experiences.