Accessibility is Reach

A presentation at EmberFest 2021 in October 2021 in Rome, Metropolitan City of Rome, Italy by Melanie Sumner

Slide 1

Slide 1

Accessibility Is Reach The Future of A11y in Ember

Let’s talk about a11y in Ember- our past, our present, our future- and concrete ideas for how you can get involved. I also really love it when I see social media posts referencing my talks, so please feel free to post on social media!

Slide 2

Slide 2

Survey Says…

The attendee survey after EmberFest 2019 indicated that people wanted more concrete examples in presentations, so here’s one.

Slide 3

Slide 3

The Pantheon

The Pantheon here in Rome was built approximately 2000 years ago,

Slide 4

Slide 4

The Dome

and to this day it is the largest unreinforced concrete dome ever built and is still standing strong. By comparison, most modern concrete is much stronger but doesn’t last nearly as long (< 100 years) because the rebar reinforcement eventually rusts which destroys the concrete from the inside out.

Slide 5

Slide 5

Now that’s concrete.

The conference organizers hope this example is what you were looking for.

Slide 6

Slide 6

Hello, friends!

• Senior Design Systems Engineer at HashiCorp • Ember.js Framework core team member • WAI-ARIA working group & co-editor of ACCNAME specification • Disabled, Decorated Military Veteran

Slide 7

Slide 7

Our Progress

I’d like to start this talk by reviewing the accessibility progress we’ve made since we saw each other last.

Slide 8

Slide 8

The Process

  1. Set the goal 2. Identify blockers to that goal 3. Measure impact to users 4. Form a team 5. Incrementally ship solutions

So when I first set out to improve accessibility in Ember, I put a process in place to ensure success. These steps worked, which is probably why I’m talking about it now. You’ll notice that I did a lot of leg work before I formed a community team. In the same way I had to rationalize the work to my employers, I knew that anyone who joined the community team would have a similar challenge.

Slide 9

Slide 9

Step One: Set The Goal

So when I started to focus on this work, I came up with a statement that was my true north for this work. This provided the scope for the work, and proved useful when it came time to form a working group. My goal was this: no new Ember app should immediately fail accessibility conformance criteria.

Slide 10

Slide 10

Step Two: Identify Primary Issues

Keeping this premise in mind, I came up with the five major issues we could tackle.

  1. Routing - no announcement, no focus reset, no skip links
  2. Missing page title
  3. Label support for input elements
  4. Missing default language declaration
  5. Improper support for aria-attributes through …attributes

Slide 11

Slide 11

Step Three: Measuring User Impact

Next, I determined what impact these issues would have on the user so we could prioritize the work. This also gave us shared language to use on the team so we could understand more immediately.

Slide 12

Slide 12

Severity Level One

Not likely to prevent access to content but could affect the ability of some to use a page.

Slide 13

Slide 13

Severity Level Two

Likely to make it difficult for some to access content and use a page, and/or could prevent some from accessing or using page content.

Slide 14

Slide 14

Severity Level Three

Will prevent access to sections of the site or the ability to perform required functions.

Slide 15

Slide 15

Step Four: form a team

Ember Accessibility Working Group included community members from across the globe.

Slide 16

Slide 16

Step Five: Incrementally Ship Solutions

First, the router. While Ember’s router is queen because it respects the URL, we had failed to provide the things that a “regular” website provided- there was nothing that indicated that a page transition had occurred. There was no focus management. There were no well-lit paths for providing skip links.

Slide 17

Slide 17

ember-a11y-refocus

Enter ember-a11y-refocus. The routing solution needed to provide three things: 1. A way to let the screen reader know that the route has changed 2. A way to reset the focus (similar to how a native website works) 3. A way to provide a bypass mechanism so you can skip the nav and get straight to the primary content And of course, we wanted a way to customize all of this. Ember-a11y-refocus provides this.

it adds a message to the page to let the screen reader user know that the route has changed and regular page navigation can resume (it is similar to https://github.com/ ember-a11y/a11y-announcer but does not use aria-live). It moves the focus to that message for the screen reader user, effectively resetting focus in Ember apps (similar to how a native web page/site works). It provides a bypass mechanism so the user can skip to the page’s primary content (see https://www.w3.org/TR/WCAG20-TECHS/G1.html). You can opt out of this if you want (see the Options section for available options).

Slide 18

Slide 18

Help wanted

While the add-on exists and you can use it today, it’s still not part of the app blueprint. So if you want to help tackle that, let me know!

Slide 19

Slide 19

Incrementally Ship Solutions

Next up in incrementally shipping solutions- Missing Page title

Slide 20

Slide 20

Ember RFC #645

As a result we have RFC #645 and this is active in new Ember apps today!

Slide 21

Slide 21

ember-page-title

ember-page-title provides a helper that allows the developer to set the title for each page.

Slide 22

Slide 22

ember-page-title: how it works

By default, using the helper will allow an interaction where additional titles are appended to the root.

Slide 23

Slide 23

customizing a separator

You can change the separator by specifying the separator attribute.

Slide 24

Slide 24

title order

For improved accessibility, Titles can be prepended to the parent, by setting the prepend attribute to true .

Slide 25

Slide 25

github repo: ember-page-title

And there are even more options than this, so check out the GitHub repo for all of the API options.

Slide 26

Slide 26

Label support for input elements

Another solution we needed was to provide improved Label support for input elements This was now especially relevant in template-only components.

Slide 27

Slide 27

solution: improved, explicit guidance

We gave examples of how to associate labels and input by creating unique ids via a backing class using the guidFor API

Slide 28

Slide 28

solution: improved guides

We also improved the guides with clearer language and illustrations

Slide 29

Slide 29

solution: addon (ember-context-id-helper)

But this still didn’t help us with template-only components, so the team came up with a way to associate labels and elements with an Ember add-on called ember-context-id-helper.

Slide 30

Slide 30

Ember RFC #659

And that’s where we got the unique-id helper, RFC 659.

Slide 31

Slide 31

Missing default language declaration

Another issue was missing default language declaration.

Slide 32

Slide 32

Ember RFC #635

And RFC 635 proposed a new way to do that. The addition of the LANG flag in Ember CLI.

Slide 33

Slide 33

how to use the lang flag

So when you start your new Ember app, you can invoke the lang flag followed by the language code

Slide 34

Slide 34

or, when in Rome...

and it will add the lang attribute to the HTML element, and just like that your app will not be failing the WCAG success criteria related to language of the page.

Slide 35

Slide 35

Pub Quiz Time!

We figured that people have been talking long before they have been programming, so maybe we should check for that. We found a few interesting things: TS is… the Tsonga language and is spoken by three countries in Africa XML is… Malaysian sign language CSS is… It was a dead language called Coastanoan but was recently revived by historians in California

Slide 36

Slide 36

Improper support for aria-attributes through …attributes

We are still working on this one.

Slide 37

Slide 37

Ideas beget more ideas

But that wasn’t all we shipped. Naturally, these ideas lead to more ideas!

Slide 38

Slide 38

Ember RFC #638

So we had the idea to make it easy to succeed when building a new app- what if we could make a way to interactively build a new Ember app? That’s where RFC 638 came in.

Slide 39

Slide 39

New addon: ember-select-light

One of the team members was also inspired to build an octane syntax native select that had all the Ember magic we know and love- @ember-a11y/ember-select-light

Slide 40

Slide 40

DX through linting: ember-template-lint

Finally we made a concerted effort to improve ember-template-lint.

Slide 41

Slide 41

Improved Accessibility Support

There are now 26 a11y-related listing rules in ember-template-lint. We have a lot more to do, so check out the ember-template-lint repo for more linting rules that could be written if you want to help out.

Slide 42

Slide 42

Improved Team Support

And there was the implementation of the TODO feature, which allows us to turn a rule on NOW, and plan to x any issues on existing code. I gave a talk called Continuous Accessibility and gave an in-depth view of this feature.

Slide 43

Slide 43

Our Present

So let’s talk about where we are right now.

Slide 44

Slide 44

Global Accessibility Awareness Day

  • this year marked the 10th anniversary of this event and with it came the announcement of the Global Accessibility Awareness Day Foundation, to permanently help spread the good news.

Slide 45

Slide 45

Ember JS Framework takes the GAAD Pledge

But that’s not all, this year the Ember Framework stepped up to the plate and took the pledge.

Slide 46

Slide 46

GAAD Statement

“As we join Global Accessibility Awareness Day (GAAD) in celebrating its tenth anniversary, we are delighted to announce that the Ember JavaScript Framework has taken the GAAD pledge to make accessibility a core value of our framework.” @melaniersumner But what does that mean? Well, it means that we have publicly pledged that accessibility is a core value of our framework.

Slide 47

Slide 47

What this means for our TODO list

This means that we have a concrete list of things to do before May of 2022! We plan to:

  1. implement unique-id helper (RFC #659)
  2. implement interactive mode for new Ember apps (RFC #638)
  3. write RFC to include ember-a11y-refocus into default blueprint
  4. finish making the Ember website accessible (including guides and API docs)
  5. increase available accessibility automation

Slide 48

Slide 48

Increasing Available Automation

We also want to increase the amount of available a11y automation.

Slide 49

Slide 49

A11y Automation Tracker

I’m working on tracking this through my side project, a11y automation tracker.

Slide 50

Slide 50

https://a11y-automation.dev

Slide 51

Slide 51

Features

Could Exist === Work To Do So I itemized all of the potential ways that an app could fail accessibility conformance, and evaluated whether or not automation could exist to test early for conformance.

Slide 52

Slide 52

Community Participation

Of course, there are ways to help. There are lots of ways to participate in our community.

  1. File issues
  2. Validate issues
  3. Help write documentation that doesn’t exist yet
  4. Edit documentation that does exist
  5. Create graphics for documentation that exists
  6. Submit a PR for an issue (https://help-wanted.emberjs.com)
  7. Write an RFC (or co-write!)
  8. Help upgrade an Ember add-on to be Embroider v2 ready
  9. Ask me for more ideas! I have lots!

Slide 53

Slide 53

What part will you play?

What part will you play? Before you ask yourself that question, I want to take a moment to recognize something very serious.

Slide 54

Slide 54

The World is temporarily closed

The global pandemic. Not only did it change the way we lived our lives, but it took an emotional toll, too. Folks are dealing with physical, emotional and mental health issues resulting from all of this- this has cost us in ways we are only beginning to understand- and by extension, it’s cost our community too. It’s easy to give when you have something to give. It’s not so easy to participate when the proverbial tank has run dry.

Slide 55

Slide 55

Start where you are.

How do you do work when all you can think about is how to prevent your family from dying? Recovery will take time, compassion and patience, both with ourselves and others. So I encourage you to start where YOU are. Maybe you’re not ready yet. That’s okay. Maybe you want a small issue but you want someone else to give you precisely a task to do. That’s okay too! Maybe your company is ready and willing to get back into the swing of things, and you’re looking for something meaningful to sink your teeth into. That’s also okay!

You don’t have to go it alone. I and many others are here for you. I’m willing to help you make a plan. Check out the Discord channels that start with DEV. If you would benefit from some planning like we did for the accessibility working group, DM me and let’s set up a zoom time to help get your team started.

Slide 56

Slide 56

Our Future

What is the future of a11y in Ember?

Slide 57

Slide 57

Reach

Our future is reach. I started playing a video game called Genshin Impact over the last month or so. I haven’t properly played a video game in a while- Like millions of other people, I played Animal Crossing during Quarantine but then the switch started making my wrists hurt so I had to put that aside. A friend started bugging me to play Genshin Impact, but I resisted at first- 10GB on my phone? Permissions to see all of my other activity on all of my apps? No fucking thank you. I won’t even install TikTok on my phone so this game was definitely out, no matter how good it was. But my friend persisted, and this is a friend who knows me well and really understands what I like and my personality. My husband Joseph reminded me that it was available on other platforms too, and I got home from a recent trip to discover a surprise install and setup on our playstation. So I started playing. As I was playing, I realized that it had some quality of life improvements over other games- you can teleport to a place on the map if you have the teleport, no matter where you are- I’ve teleported right out of some spicy battles myself, I can tell you that. I like that I can jump on cliffs and fly, and climb mountains- and these things that I consider to be “nice” - these are built into the game as a way you get things done. by thoughtfully including mechanics other games do not provide, not only did they increase the content of the game itself, they also made the game more desirable to play. Their ability to implement quality of life improvements in the game, increased the number of people (like me) who wanted to play this game- a game they may not have otherwise played. This game has reach.

Naturally, I started thinking about this idea of reach and how it relates to accessibility and Ember and then…well you know.

Slide 58

Slide 58

It's not about a11y, it's about reach

The future of Ember isn’t about accessibility, it’s about reach. Reach encompasses accessibility, performance, security, testing, … all of the things. By working to increase your product’s reach, you will naturally start paying attention to the things that will help you get there in a meaningful way. The kind of way that makes you feel good.

Slide 59

Slide 59

What platform provides maximum reach?

But what platform provides maximum reach? Let’s try to figure this out with a data-driven process.

Slide 60

Slide 60

Devices

Reach includes device types.

Slide 61

Slide 61

Connection Quality

Reach includes quality of connection

Slide 62

Slide 62

Users

Reach includes types of users

Slide 63

Slide 63

Reach Constraints

• Must have a device • Must have users • Must have some sort of network connectivity • (P.S. Physical height is not a constraint)

Slide 64

Slide 64

So, what platform is on every single device?

Slide 65

Slide 65

www

Folks, it’s the world wide web.

Slide 66

Slide 66

reach is about people

A web browser is on every device. Nearly every person has access to some kind of device So reach, then, is ultimately about people.

Slide 67

Slide 67

Think outside your dev machine.

Ironically, in order to expand our reach we have to think outside the machine we are creating on. That can be a challenge because we spend so much time in our own heads, turning ideas into code. It’s such a relief to finally finish something and see it come to life on your screen.

And now I’m asking you to think outside that particular screen and think about other screens too.

Slide 68

Slide 68

Paint the picture...

Or as my friend Eric likes to say, Paint the picture not the frame. What is the purpose of what we are building? In order to do that, we have to expand our idea of reach. This will lead us to a world without pixels.

Slide 69

Slide 69

The future of a11y in Ember is…

But if we want to hone in on accessibility as one facet of reach, what is that future?

Slide 70

Slide 70

Design Systems

Design systems. Specifically design systems for web-based products. They give us a way to think outside of the device, a way to dynamically present content to every type of user on every type of device with every type of connection. We are both thinking about every pixel and ignoring pixels all together.

We’ve had a lot of great talks about some of the facets of design systems here at EmberFest, and there’s a whole lot more goodness coming to the Ember community.

Slide 71

Slide 71

Something new

“Also here’s something new and helpful for you” - EVERY EMBER SPEAKER, EVER

And in the tradition of creating useful things to share just in time for a conference talk, I’ve made a new website that intends to provide step-by-step instructions, tips, and tricks for making an accessible Ember application. Of course, it is also an open source project, and you can absolutely contribute as you continue on your accessibility journey.

Slide 72

Slide 72

Building accessible ember applications

Slide 73

Slide 73

https://ember-a11y-for.dev

In true conference driven development, it was probably a stretch goal and I should have probably done it later. Maybe. Anyway, it’s a work in progress, but that’s where you all come in. I have an ask for you! File issues for things you WANT to see there. The content that would be helpful to you. Patterns, questions you want answers to, information you think should be included, links to other content you want folks in the community to know about- file the issue.

I am committed to making this specifically for Ember developers.

Slide 74

Slide 74

No Permission Needed

In closing I want to remind you that you don’t require permission to create accessible code.

Slide 75

Slide 75

Again for the folks in the back...

You do not require permission to create accessible code. @melaniersumner