The Intersection of Performance and Accessibility

A presentation at performance.now() in November 2024 in Amsterdam, Netherlands by Eric Bailey

The Intersection of Performance & Accessibility — The Intersection of Performance & Accessibility
performance.now()

Hallo everyone!
My name is Eric, and I’m a Senior Accessibility Designer at GitHub.
I live in Boston, Massachusetts in the United States, and am a tall white man with black hair and glasses
I’m wearing a short sleeve button down shirt with a pink brain pattern on it because brains are weird and fun, and this is actually my first time in Amsterdam!

Before I get into it, I just want to extend my appreciation here Getting a chance to speak about accessibility outside of accessibility circles is a wonderful opportunity
I’m thankful to the conference organizers for enabling this, and to you, the audience, for being receptive to it
There are a lot of parallels between the practices of performance and accessibility, and I hope this talk will help illustrate that

So, with that said, let’s set the stage

This is a talk about performance,
With performance being the manner in which a mechanism behaves
And with this context established, know that I’ll mainly be talking about the behavior of the mechanisms that power assistive technology

So, I was conducting an accessibility audit a few years ago
If you’re not familiar with what an accessibility audit is, know that it is the process of performing manual and automated checks to see if a digital experience can be operated by assistive technology
It’s very similar to performance profiling and auditing, and equally as nerdy and detail-oriented
For accessibility audits, you identify areas where there would be problems or straight-up barriers that would break assistive technology support, thereby preventing someone from using your website or app
An example of assistive technology that could have its support disrupted would be a screen reader.
If you’re not familiar, a screen reader is specialized software that parses the contents of the screen, announces that content to the person using it, and lets them take action on it
And a button that someone is unable to press to save their progress because of how it is coded is an example of an audit issue that affects a screen reader user
This is a case of accidental exclusion, where someone is prevented from being able to use functionality made available to others, just by virtue of circumstance

The experience I was auditing was a medical education app used to train caregivers
It was built using a single page application framework, using Google’s Material Design library to construct the user interface

When I learned that, I thought, “Google made it? Oh sweet. I don’t have to worry as much.”
So I fire up VoiceOver, which is macOS’s built-in screen reader and start testing.
Things are going pretty well and then

VoiceOver crashes! It stops speaking!
I try restarting Safari, I try clearing the cache, I try closing other tabs. Heck, I even try rebooting.
Same result every time.
So, I ask my boss what’s going on and he says, “Oh, it’s probably problems with the Accessibility Tree.”

The what now?
Before I get more into this, here’s a question for you:
How do you describe an interface?
I’m not saying, “Tell me what you see or hear after you turn the computer on.”
I’m saying how do you speak computer to a computer to tell it what’s present and what state it’s in?

One way we do that is with the Accessibility Tree
Fundamentally, the Accessibility Tree is provided by the operating system
It is a running collection of objects, all the little atomic bits that make up a user interface
Assistive technology makes use of the Accessibility Tree to read these objects, filter out the irrelevant details, and report the remaining important objects to the user
Without a functioning Accessibility Tree there is no way to describe the current state of what an interface is
And consequently no way for some people to be able to use a computer or smartphone
So suffice it to say it’s a really important piece of technology!
So, then how do you build an Accessibility Tree? How do we make all these atomic bits of UI work?

First, you have to give each individual interactive object in an interface a name,
Names are a short identifiers used to describe purpose.

Then you give it a role.
Roles are predefined values that tell someone what they can do to the interface object.
For example, a role of button means that someone can press it to activate some predefined action.

Then we have properties, which are the attributes of the object.
Examples of this are its position in an interface, it’s state, or interactions that are allowed.
For a button, that could mean a toggled state to indicate it is being pressed in, think a play button on a media player

Finally, we have a description which can provide further information and context about the object, if needed.
Put these all together and viola! We have an accessible object!
These accessible objects are then programmatically grouped together to form more complicated interface components
For example, our play button could be part of a larger media player such as VLC, Spotify, or Apple Music
So, then how do you build these interface components?

Let’s say an operating system alert dialog, that’s a pretty commonplace thing for UI

Starting from the top down, we have a menubar
That’s the anchor that we’re going to attach everything to.

And then we add a title for the menubar, so we know what it’s all about, and what contents we can expect to find
If you’re using a screen reader, titles are really helpful, as it saves you from having to dig around inside the component to figure out what it’s for
If your product is a single page application, it’s also really helpful to update your title to reflect the purpose of the current view instead of just displaying the app’s name
This is one of those circumstances where we actually don’t want a more app-like experience on the web

Moving on—we might also need to close this dialog window once we learn what it’s for,
So we include a close button in the menubar for quick access

Then we add the body of the dialog, the place where we can put the bulk of the dialog’s main content

In the dialog’s body there’s another title, which asks us if we want to save the changes we made to the thing we were working on

We then add text to the body, which will provide more information about what happens if you choose not to save

Then we add a save button, to allow us to commit to saving the changes we made

And an accompanying cancel button, in case we don’t
And presto! We have a dialog component!

We can now speak computer to computer to get what we want
This is because these collected objects have accessible names and are therefore present in the Accessibility Tree

I can programmatically say, “Go to the dialog.”

“Then it’s body.”

“And activate the save button.”
And it works! How cool is that!
You might also be thinking this feels a lot like traditional software tests, and yup! You’re right. They’re close friends.

So, this all might seem a little pedantic, but please, bear with me for a bit

We do have this dialog component, but there’s more to it than just that

Interface components have to have a place to live, and that place is an operating system

Operating systems also include components that allow us to navigate to, and access the stuff you store on them

It’s also the place we install and run programs

And all the little doodads and widgets we can’t live without

And the browser, which is rapidly becoming an operating system in it’s own right

The browser contains the mechanisms we use to access the web
…aaand the web is sort of the Wild West
In that you can write more or less whatever you want and it’ll usually work, Which is both a blessing and a curse

But regardless of how you write what you write, you can’t escape the fact that you ultimately have to render HTML

That HTML then has its appearance and behavior augmented by both JavaScript and CSS
Again, there’s many ways to go about doing this,
But they are the other two requisite parts that make up the whole that is a contemporary website or web app

The HTML markup, augmented by both JavaScript and CSS creates the Document Object Model, or DOM tree, which is a programming interface for websites
I know y’all know all of this, but please stay with me for a moment here

Browsers then read the DOM, and all the information contained within it to draw an interface

Which is then shown to a user

The user can then take actions, which updates the DOM,
Which in turn updates what is visually rendered, allowing us to make our websites dynamic

Running in parallel is the Accessibility Tree, which is sampled from the generated DOM
I say sampled because the Accessibility Tree will use specialized heuristics to only surface things it deems necessary
Modern versions of the Accessibility Tree are generated after styles are computed, as certain CSS properties such as display and pseudo element content will affect it
So, when people tell you CSS is only about presentation, yeah… uh, it’s not exactly true
Moving on

This sampled version of the DOM is then read by various kinds of assistive technology, including, but not limited to screen readers
There’s two things I’d like to point out here:

First, using a visually rendered interface and assistive technology aren’t mutually exclusive things.
It’s a fact that not all screen reader users are blind,
And many people choose to augment their browsing with various devices that all rely on the Accessibility Tree.

Secondly, the Accessibility Tree relies on the user interacting with the DOM to update,
Accessibility Trees are effectively a “read only” technology, in that we can’t directly work with them
There’s a few reasons for this, but the most important one is to preserve user privacy

Another thing you should be aware of is that it’s more an accessibility forest than just a single Accessibility Tree
There are different implementations of the Accessibility Tree out there,
Each one depends on what operating system you’re using and what version of said operating system is running
This is due to the different ways companies have built, and updated their operating system’s underlying code throughout the years

And just so we’re clear:

The DOM can be a part of the Accessibility Tree,
But the Accessibility Tree is larger, and not limited to just the contents of your browser

Because of this, the accessibility tree is more brittle
It has more to pay attention to, and it’s core technical architecture was developed before this whole “internet” thing really took off
Meaning it didn’t anticipate the sheer amount of information we’d be throwing at it

Crashing the accessibility tree, and therefore breaking assistive tech support is bad, yes
But a large amount of information present in the DOM means that there’s an accompanying large amount of work the Accessibility Tree needs to do to figure out what’s what and report on it
Which.
Slows.
It.
Down.

This can create a lack of synchronization between the current state of the page and what is being reported by assistive technology
Meaning that a user may not be working with an accurate model of the current screen,
And be taking action on interactive components that are no longer present, or are in a different state than they expect
This can create the confusing experience of users activating the wrong control, navigating to a place they didn’t intend to, or unintentional data submission
Remember, some users literally cannot the screen and therefore have no indication that this desync is present.
So, how do we help prevent this?

Start with writing semantic HTML.
Using things like the button element for buttons instead of ARIA slapped on a div helps lessen the amount of guesswork the Accessibility Tree has to do when it runs its heuristics to slot meaningful content into its description of the current state of the world.
This serves to both speed up its calculation and makes what it reports more reliable

And speaking of semantic HTML
Here’s the raw, living DOM of an actual website
In fact, it’s the homepage for this conference!

Even a static, performant website contains a lot of information a computer has to chew through

Again, utilizing semantic HTML helps reduce the effort it takes to generate the Accessibility Tree from the DOM’s contents

And unfortunately, using semantic HTML is kind of a rare thing these days, which is partly why I’m here giving this talk
But also fortunately, this site’s semantics are really good!

So, big shoutout to Hidde and Krine for keeping it real
How about a quick round of applause, folks?

Okay, I think you get the gist of it

Of the code I just showed you, five slide’s worth,

We’ve only covered roughly half of just one page
It’s worth pointing out that this is a relatively short and simple page and that again, it is still a lot of information to process

Keeping that DOM example in mind, we now have a simple form
It’s a pair of unstyled radio buttons asking you if you want the chicken or the fish as your meal preference

Here’s how that form might be translated into the Accessibility Tree
If we use semantic HTML, the names, roles, and properties are automatically filled in for us without any additional effort
When I was speaking about how semantic HTML slots in, this is a more granular example of what I’m getting at

Here’s an even more granular example, sampled again from the conference Homepage
It’s the link for the schedule, located in the website’s primary navigation
I’m using Firefox’s Accessibility Inspector to dig into this link’s text node
And there’s a ton more information exposed, including attributes, states, actions, a child element count, relations, and available actions
All of this data is used by the Accessibility Tree to help it describe the shape of things

And here’s an even more high fidelity example, a raw text dump of the Accessibility Tree for this same page
This is an example of what the language might look like when we’re speaking machine directly to machine.

We don’t speak machine directly, though
Before we had Firefox’s Accessibility Inspector, we had to rely on more specialized tools to be the translators,
The Paciello Group’s aViewer and Apple’s Accessibility Inspector are the two go-to resources
And you’ll still need them if you want to inspect anything other than websites, or do some really serious digging

So, with all that established, let’s make the abstract immediate
What going on here, and why should you care?

With my auditing project, I narrowed the problem down to issues with Material Design’s radio inputs
Here’s how these inputs appear visually

And here’s how they appear in code

To make a Material Design radio input, you need: six HTML elements containing nine attributes, with a DOM depth of 3

You also need 66 CSS selectors containing 141 properties, which weighs in at 10k when minified

You will also need 2,374 lines of JavaScript, which weighs in at 30k minified

All that will get us a radio input

But you need more than one radio input to be able to use it properly

And oftentimes there’s a few options to select from

Sometimes there’s more than just a few options

And sometimes there’s even more than that

In the case of my audit, we had a massive amount of radio inputs being conditionally injected into the page
I can’t really do much here. It’s my job to bear witness and catalog access issues when acting as an accessibility auditor
Which is partly why I switched over to becoming an accessibility designer instead

The larger point being is that all of this all adds up if you are not paying attention

Google’s Lighthouse recommends an optimal website DOM tree has:
Less than 1,500 nodes
Max depth of 32 nodes, and
No parent node with more than 60 child nodes

What I’d like to call attention to is the max depth of 32 nodes bit
That might seem like a lot of wiggle room at first, but take a moment and think about the templates of the sites you’ve worked on.
There’s the frameset, wrapper divs, landmarks, components wrappers and if you’re doing it right, fieldsets on your forms
Each digging a little bit more inward

Another part of accessibility auditing is providing suggested fixes to the problems you uncover
It’s tough work, but nobody likes to pay people money to tell them all the things that are wrong, but then offer no solutions
We wound up recommending a radio input pattern that utilized three HTML elements

It’s a pattern developed by my friend Scott O’Hara, taken from his excellent a11y_styled_form_controls project
It’s worth saying that Scott puts these patterns through their paces, and tests them with an incredibly robust set of assistive technologies
So a nice side benefit is knowing I can recommend this project to others with a great deal of confidence [Q

The updated radio inputs were completely visually indistinguishable from the original version

And, to compare the two solutions on the code layer:

We have a 50% reduction in HTML elements and we cut the DOM depth down by a third

There’s also a 30% reduction in CSS selectors and properties, resulting in the CSS payload for this component being reduced by 90%

We’ve also completely removed 30k of JavasScript, which is 30k less blocking resource being served

Cobbling up a rough prototype, we were able to create an environment that mimicked the conditions of the site we were auditing, only now using the new radio input code, and guess what?

It worked! VoiceOver didn’t crash!

So why is this our problem?
Why should we care about the fragility of other people’s software?

Well, prioritizing developer ergonomics without considering the generated HTML it produces can lead to bad things happening

And regardless of our setup, and despite our protests, we tend to get even more things piled on to our base experience

Things like ads

Analytics

Social marketing engagement tools

Development integration utilities,

And accessibility overlays
If you are not familiar with what an accessibility overlay is, know this:
They are predatory anti-solutions that prey on ignorance and fear of litigious action
By offering a one line of code solution that promises to “fix” all your accessibility issues they all enable arbitrary third party JavaScript execution on your product, which should hopefully already set off some alarm bells in the audience
And believe me when I tell you it’s some of the worst frontend code I’ve seen in my entire career
AccessiBe is one of the worst offenders in the market, and has been repeatedly legally demonstrated to not deliver on what it promises
In fact, I’ve given expert testimony to this effect, so believe me when I tell you I know what I’m talking about here
Additionally, they refuse to comply with European Data Protection Impact Assessment requests, which is suspicious as hell

And then there’s also the Cold War raging between websites and their users
An example of this is Facebook splitting a single word into 11 DOM elements in order to thwart ad blockers

And this graph, generated from the median values of how 1.3 million websites are generated, shows JavaScript claiming the majority of the share.
This JavaScript majority means it’s that much more time spent blocking the browser from performing other other actions,
Including things like interfacing with assistive technology

The point here being is that we oftentimes don’t realize there are very real, very important things we sacrifice when we throw out what the browser gives us for free

Here’s what Marco Zehe, Mozilla’s former senior Accessibility QA Engineer has to say about all this:
Nibbling away at those milliseconds it takes for information to reach assistive technologies when requested. My current task is to reduce the number of accessible objects we create for html:div elements. This is to reduce the size of the accessibility tree.

This reduces the amount of data being transferred across process boundaries. Part of what makes Firefox accessibility slower on Windows since Firefox Quantum is the fact that assistive technologies now no longer have direct access to the original accessible tree of the document.

A lot of it needs to be fetched across a process boundary. So the amount of data that needs to be fetched actually matters a lot now. Reducing that by filtering out objects we don’t need is a good way to reduce the time it takes for information to reach assistive technologies.

This is particularly true in dynamically updating environments like Gmail, Twitter, or Mastodon. My current patch, slatted to land early in the Firefox 67 cycle, shaves off about 10 to 20% of the time it takes for certain calls to return.

Note that all this optimization is only for one browser, Firefox

And that there are a lot of browsers out there

It’s also not all about browsers, either.
Here’s a refreshable braille display, one of many other kinds of assistive technology
They are purpose-built, low power, high efficiency devices that many blind people use to read the web
Think of them kind of like Bluetooth speakers in terms of how they connect to computers, smartphones, and tablets, and how much horsepower they have under the hood to use
Refreshable braille displays also interface with the accessibility tree in order to spell out content,
But, as previously mentioned, have far less computational power than a laptop or smartphone
This means that they can be especially susceptible to failing to work when an experience is too non-performant

So, you know, let’s say I’ve successfully pled my case here
To which I hear, “Someone should do something!” The battle cry of bystanders everywhere
Let’s pragmatically unpack this some, and figure out what our actual, available options are

For screenreaders, the main ones are JAWS

And NVDA
Both are Windows screen readers

There’s also VoiceOver for macOS and iOS

And Talkback for Android
These are the big four screen readers you’re going to hear about
It’s sort of analogous to Chrome, Safari, Edge, and Firefox
In that there’s more screen readers out there, but these cover the main use cases you’re most likely to deal with
While not all assistive technology are screen readers, if your site works well for them, chances are good it’ll work well for other forms of assistive tech

Of them, all but one have an open issue tracker

But half have closed source code
This means that while we can file issues, we aren’t really empowered to do much more about it on the assistive technology layer
I think it’s also completely unrealistic here to expect people to submit and follow issues or code pull requests across all trackers in addition to working a full-time job

We also don’t always know what is going to be prioritized and when.
Remember, assistive technology has to pay attention to the whole operating system, so your website’s current burning priority may not be the assistive technology manufacturer’s.
And as the previous slide demonstrated, sometimes we also can’t know what their own particular burning priorities are.
Because of this, our only other realistic option is to keep the DOM trees on our sites nice and shallow, and our JS payloads light
And there are actual, tangible benefits to doing so

Here’s Marco again weighing in again on his optimization efforts:
Reducing the number of milliseconds it takes for a screen reader to start speaking after a key press from about 140 to 100 here, or from 120 to 100 there, doesn’t matter much on a fast machine. On a slow machine, that reduction is from about 230 to 250 down to 200 or 190.

So now let’s talk about what a slow machine means
If you are disabled and/or underserved, you face significant barriers to entering and staying in the workforce
This means you may have less access to current technology, especially the more expensive, higher quality versions of it.
Another factor is some people who rely on assistive technology are reluctant to upgrade their software, for a very justified fear of breaking the way they use to interact with the world
This includes the assistive technology they use, as well as the browser and operating system it interfaces with

Slow machines may also not mean an ancient computer
Inexpensive Android smartphones are a common entry point for emerging markets and underserved communities, and with Android comes Talkback

A slow machine might also come from a place you may not be expecting
By which I mean you might have a state-of-the-art computer, and are doing state-of-the-art things on it
This requires a ton of computational resources, which makes fast things slow
With less computational resources to go around, we may have unintended consequences, possibly re-creating a situation similar to our too many radio inputs problem

Think Electron apps, desktop programs that are built with web technologies
On this slide we’ve got a few of the more popular Electron apps out three, including 1Password, Teams, Slack, Figma, VS Code, and Discord,
Many of which can be running concurrently

Accessibility auditing isn’t something people normally do out of the goodness of their own heart.
It’s typically performed after a lawsuit has been levied against an organization
And let me be clear: when you create inaccessible experiences, intentionally or not, you are practicing discrimination
The upcoming European Accessibility Act acknowledges this, and will put protections in place starting next year to help ensure people cannot be discriminated against based on their disability conditions
Similarly, the Americans With Disabilities Act already guarantees these protections
This extends to both private organizations and the digital space, and its language is couched in Civil Rights, which are some of the strongest protections individual citizens have in the United States.
This legislature is a good thing, as it guarantees protections as more and more of the services necessary to living life go online.

You need to work with what you have, not what you hope will be
Part of this means understanding that when we want things to be better we need to understand that these kinds of changes are really technically complicated under the hood, as well as spread across multiple concerns,
Each with their own priorities, agendas, and resourcing
On top of that, accessibility fixes are often viewed as unglamorous and deprioritized compared to other features

I don’t mean to bum you out, and I don’t expect you to become accessibility experts
However, as people who are interested in more than just the surface level of things, you are uniquely empowered to affect positive change
What I ask of you is to at least incorporate basic accessibility testing into your workflows
If anything, just check to see if a screen reader crashes when you’re auditing a particularly gnarly performance issue.
After all, a bad assistive technology experience is better than none at all

“But Eric” you say! “Accessibility is scary and I’m afraid I’ll misrepresent something.”
Don’t worry, friends! I’m going to teach you how to do what I did

If you’re using a Mac, you can start VoiceOver by pressing Command F5

Then you hit tab to navigate by interactive item
And shift plus tab moves you backwards by interactive item, if you’re feeling adventurous
Then you tab around your website or web app

Did VoiceOver crash?
If no, awesome. Keep it up!

If VoiceOver does crash, get to doing what you do best: advocating for, and submitting PRs to reduce your JS payload and DOM depths
And don’t forget, you can press Command F5 again to turn VoiceOver off when you’re done
It’s as simple as that

Okay, whoa!
The slide background color is yellow now!

This is what we call a great segue

I’m a designer by trade,
Part of that job means coming up with alternate strategies for allowing people to accomplish their goals
Because sometimes the most effective solution isn’t necessarily the most direct one

With that in mind, we’re going to talk about another definition of performance:
Which is the ability to actually accomplish something
All of these little surgical tweaks and optimizations don’t mean squat if people don’t understand how to operate the really fast thing you give them

To that point, another aspect of dynamically injecting a ton of radio inputs into a page is that it adds more things for a person to carry in their head
This is called cognitive load, and it’s a huge problem
It affects our ability to accomplish tasks, and importantly, our ability to accomplish tasks accurately

Namely, cognitive load inhibits our memory

Problem-solving skills

Attention

Reading comprehension level

Math comprehension level

And shockingly, our ability to visually process, and therefore understand what we see

Cognitive load is such a problem that NASA developed the Task Load Index, an assessment tool to help quantify it
This isn’t warm fuzzy feelings about empathy, this is a serious attempt by a serious government agency to refine efficiencies and prevent errors
One of the most interesting things about the existence of the Index is that it’s an indirect admission that disability can be conditional
Think about it: when’s the last time you were using technology while tired, distracted, sick, or learning a new skill and the outcome isn’t what you desired?
Heck, when’s the last time you were trying to use technology while drunk?
Cognitive load an important thing to track for building rockets, sure
But it also translates to other complicated things like making and using software

One of the things we can do to lessen cognitive load in software is to lessen the amount of information someone has to parse at any given moment

For the medical education app, we could have added an additional step into the user flow that asks a high-level segmenting question
It’s a little more friction, sure
But it’s being used strategically as a focused choice, to keep the overall cognitive load lower for the subsequent parts of the user flow

This would help to filter down the results you get
Which makes it easier for both the user and the browser to parse

The other big-picture question we need to ask is if all this work is even necessary?
The most performant page is the one you never have to use
By which I mean how often can we side-step these issues by using other resources and information previously made available to us by the user?

This is such an important thing that the Web Content Accessibility Guidelines has a rule for it
Success Criterion 3.3.7 Redundant Entry is level A, meaning it is a baseline requirement for all content on the web
It stipulates that you as the provider of the experience do not require someone to enter information that they have previously successfully submitted earlier on in the experience
Not only is this good UX, but it’s also helpful for people with cognitive and motor control disabilities
Like, observing this rule could quite literally save someone from experiencing pain from unnecessarily filling out information they already submitted
So, be sure to remember to keep this in mind the next time your company’s shoddy reimbursement system makes you fill out the same info in triplicate before submitting

If you’re interested in this sort of thing, the 2018 Design in Tech report is a must-read piece
One of the surprising things it revealed was that very few companies conduct qualitative user research
Which is the practice of asking people how they’d use a feature, and how they feel while they do it

So, 12% of early-stage startups

32% of mid-stage startups

And 46% of late-stage startups don’t do qualitative user testing
That’s sub-50% for each category of startup listed. Yikes.
I’m not a numbers person, but there does seem to be a trend going on here, and it’s not a great one
Another interesting thing is barely any companies conduct qualitative testing for features after launching them, even if they do perform qualitative testing beforehand
So we’re all just collectively throwing features, and the piles of code that these features require into the larger, ever-evolving ecosystems that are our products, and then not checking to see how they’ll actually affect things.

We also need to remember that we’re only seeing those companies that beat the odds
The market is built on top of the corpses of failed businesses who poured all their cash and resources into the wrong strategies and features
When we parrot these perceived successes at our own places of work, know that these successes are largely coming from sheer probabilistic luck

If you need a more concrete example of this, consider Evernote
An app that started as an industry darling is now mainly talked about in terms of concern for what will happen to note content when the company inevitably folds
This stems from decades of mismanaged strategy, redesigns that didn’t meet the mark, and features that failed to find product/market fit
We should all strive to do the opposite here:

We should make it fast

Make it accessible

Make it easy to use

Make its value apparent, and then

Ask people what they think of it, and continue to ask them what they think of it as time goes on

So, in wrapping up this talk I have three requests:

First, let’s break down all these isolated islands of siloed practice.
It’s a dirty little secret that the bulk of accessibility issues are created in the design phase. I’d wager the same is true for performance
As performance-minded engineers we can collaborate earlier with designers and plead our cases in a way that they’ll actually be willing to respond to
One such way is to proactively identify potential bottlenecks where a redesigned user flow can cut the Gordian knot.
Remember: at its heart performance is user experience, and sometimes the most impact happens before the development layer the isle (Pun intentional)

The second ask is me carrying the torch from a talk from an earlier iteration of this conference
There’s a four year old issue on GitHub from Scott Jehl asking about taking the spirit of what this talk drives at and incorporating it into Lighthouse
We all know that Lighthouse is an incredibly influential tool
I’d also like to point out that there are a ton of incredibly smart, influential, and dare I say friendly-looking people here today
And a little renewed attention on this issue could do a lot of good.

The third big ask is acknowledging that it’s one thing to read about something and believe it to be true,
But it’s another thing entirely to put it out into the world without verifying it works
Shoutout to Tammy’s wonderful morning keynote here, where she encourages us to get comfortable with being uncomfortable
So, in the spirit of that, why not experiment with incorporating basic assistive technology checks into your performance audits?

The web, and more importantly, the people who use it, are too vital not to.

Thank you for your time and attention, and thank you to performance.now() and it’s organizers and staff for this opportunity
My contact information is available on my website, which is ericwbailey.website
And I’m also on Blueky and Mastodon these days
I am also terminally online, so please feel free to reach out anytime, and thank you again!

Eric Bailey
@ericwbailey

1 / 163

Accessibility is a holistic practice, essential to some but useful to all. It is a practice that touches on many aspects of good web design and development, especially performance. This talk will highlight opportunities and techniques to improve your website or web app’s performance by embracing an accessible, inclusive mindset.