A presentation at EmberFest 2021 in October 2021 in Rome, Metropolitan City of Rome, Italy by Melanie Sumner
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!
The attendee survey after EmberFest 2019 indicated that people wanted more concrete examples in presentations, so here’s one.
The Pantheon here in Rome was built approximately 2000 years ago,
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.
The conference organizers hope this example is what you were looking for.
• 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
I’d like to start this talk by reviewing the accessibility progress we’ve made since we saw each other last.
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.
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.
Keeping this premise in mind, I came up with the five major issues we could tackle.
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.
Not likely to prevent access to content but could affect the ability of some to use a page.
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.
Will prevent access to sections of the site or the ability to perform required functions.
Ember Accessibility Working Group included community members from across the globe.
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.
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).
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!
Next up in incrementally shipping solutions- Missing Page title
As a result we have RFC #645 and this is active in new Ember apps today!
ember-page-title provides a helper that allows the developer to set the title for each page.
By default, using the helper will allow an interaction where additional titles are appended to the root.
You can change the separator by specifying the separator attribute.
For improved accessibility, Titles can be prepended to the parent, by setting the prepend attribute to true .
And there are even more options than this, so check out the GitHub repo for all of the API options.
Another solution we needed was to provide improved Label support for input elements This was now especially relevant in template-only components.
We gave examples of how to associate labels and input by creating unique ids via a backing class using the guidFor API
We also improved the guides with clearer language and illustrations
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.
And that’s where we got the unique-id helper, RFC 659.
Another issue was missing default language declaration.
And RFC 635 proposed a new way to do that. The addition of the LANG flag in Ember CLI.
So when you start your new Ember app, you can invoke the lang flag followed by the language code
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.
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
We are still working on this one.
But that wasn’t all we shipped. Naturally, these ideas lead to more ideas!
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.
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
Finally we made a concerted effort to improve ember-template-lint.
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.
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.
So let’s talk about where we are right now.
But that’s not all, this year the Ember Framework stepped up to the plate and took the pledge.
“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.
This means that we have a concrete list of things to do before May of 2022! We plan to:
We also want to increase the amount of available a11y automation.
I’m working on tracking this through my side project, a11y automation tracker.
https://a11y-automation.dev
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.
Of course, there are ways to help. There are lots of ways to participate in our community.
What part will you play? Before you ask yourself that question, I want to take a moment to recognize something very serious.
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.
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.
What is the future of a11y in Ember?
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.
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.
But what platform provides maximum reach? Let’s try to figure this out with a data-driven process.
Reach includes device types.
Reach includes quality of connection
Reach includes types of users
• Must have a device • Must have users • Must have some sort of network connectivity • (P.S. Physical height is not a constraint)
So, what platform is on every single device?
Folks, it’s the world wide web.
A web browser is on every device. Nearly every person has access to some kind of device So reach, then, is ultimately about people.
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.
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.
But if we want to hone in on accessibility as one facet of reach, what is that future?
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.
“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.
Building accessible ember applications
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.
In closing I want to remind you that you don’t require permission to create accessible code.
You do not require permission to create accessible code. @melaniersumner
