As we celebrate Global Accessibility Awareness Day (GAAD), I also want to take the time to celebrate the incredible progress that the Ember community has made in our accessibility (a11y) efforts. Over the past few years, the Ember community has been purposefully strategic about accessibility improvements; it hardly came as a surprise that we made our commitment to accessibility even more visible by taking the GAAD Pledge last year to make accessibility a core value of our framework.
Getting Started: Setting Goals
After completing an analysis of the accessibility-related shortcomings shared both across all JS Frameworks and in Ember specifically, a tangible list of items that could be improved emerged. It was also clear that additional education of the community was needed to increase mindshare regarding accessiblilty in general.

Of course, there is a forever-long list of accessibility improvements to be made across the web; to avoid trying to boil the proverbial ocean, it was important to set a north-star goal to help orient all efforts.
To that end, the goal became this: no new Ember app should fail accessibility conformance checks. By this, we mean running the ember new MY-APP command, and adding at least one additional route (ember generate route NAME).
Improvements
There have been some distinct areas of improvement, and I want to take the time to highlight and celebrate them!
Community Education

One of the ways our community shares big ideas is through EmberConf, our primary annual conference. Thanks to the specific efforts of the conference program committee and the speakers who submitted CFPs, we witnessed a shift: talks began including more accessibility. In the past two Ember conferences, nearly every talk has directly discussed accessibility as it relates to the subject matter being presented. From "nearly none" to "almost all" over the space of 2-3 years is really something special; kudos to the conference speakers for providing this valuable information to our community!
This year, I especially loved Space Jamming Accessibility by Zoë Bijl & Jenny Judova. Want to browse all of talks and learn more? Check out our YouTube channel: https://www.youtube.com/c/EmberMeetupVideos
Additionally, the #talk-a11y channel on the Ember Community Discord Server has been a great place for folks to ask questions and get help implementing accessible interfaces in their Ember apps. The top question has probably been, "how do I make an accessible card component?" Thanks to the Inclusive Components project for recommending such a great solution. The answer is permanently pinned to that channel!
Framework Improvements
Page Titles
The first framework improvement to land was adding page titles by default, as outlined by RFC #645. When you generate a new route in Ember, the corresponding page template will have {{page-title "ROUTE NAME"}} at the very top of the template. Users only have to provide a meaningful page name and the framework will put it in the correct place!
By default, using the helper will append additional titles to the root. Developers can customize the separator used, and the order of the titles (maybe you would like the page title first, followed by the site title!)
Lang Attribute
Another framework improvement was to add the ability to apply a lang attribute to the element for your app. ember new my-app --lang en, where the value following the --lang flag is the language code (e.g., "en" is English; "en-US" is specifically American English); this was outlined in RFC #635.
One interesting thing about this project was finding the places where there are programming languages who shared the same code as spoken languages:

1. CSS is a recently revived language called Coastanoan
2. XML is Malaysian sign language
3. TS is the Tsonga language, spoken by three countries in Africa

Huge thank you to Joseph Sumner for doing the lion's share of the work to make this happen!
Unique Id Support

It was too easy to not get the feedback that your input element needed an associated label element! As a first step, we improved the guides, adding clearer language and illustrations. Next, we tested out the ideas presented in RFC #659 in ember-context-id-helper
And now we have a proper id helper, baked into Ember by default!
In Ember v.4.4.0, the {{unique-id}} helper will be included by default in new Ember apps. Developers can use this helper to generate a unique ID string suitable for use as an ID attribute in the DOM. Notably, this removes the need for a backing class since it can be directly used in template-only components!
A sample invocation of such a component might look like this:


Each invocation of {{unique-id}} will return a new, unique ID string.
You can also use the let helper to create an ID that can be reused within a template.
{{#let (unique-id) as |emailId|}}
Email address

{{/let}}

Interactive Ember App Creation
To build on this, look for RFC #638, an interactive way to create new Ember apps, to come to life soon! Bert De Block has submitted a PR to ember-cli. The idea is that you will be able to type ember new --interactive (or ember new -i for short) and be presented with some questions in your CLI that will guide you with strong defaults, but give you room to customize.
Ecosystem Improvements
Not every improvement lands directly in the default Ember blueprint, however. Some solutions need time to be battle-tested in Ember apps, so we ship them as an Ember addon to be tested and gather feedback BEFORE we put them into the default app experience.
Accessible Routing
While the router in general is due for a refresh, we didn't want to wait to ship an a11y solution! There have been several ideas for how to solve accessible routing in Ember over the years, but we landed on ember-a11y-refocus, as it provides three critical missing pieces all at once:

1. It adds a (customizable!) 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).
2. 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).
3. It provides a default (but optional) bypass mechanism so the user can skip to the page's primary content (see https://www.w3.org/TR/WCAG20-TECHS/G1.html).

It even provides a customizable way to define a route change to support the current implementation of query params.
Have you tried this out in your Ember apps yet? We'd love to hear about it! We also have an issue defined to write an RFC that proposes adding this to the framework by default.
Accessible Ember App Example
If you want to find a really perfect start for your Ember application, check out ember-sample-apps/accessibility-base. This sample app provides all the specific tweaks that an Ember app needs, and the README itemizes the details:

1. adds lang attribute in app/index.html (you can also do this via ember new my-app --lang en where en is the spoken language code for your application)
2. adds user-scalable=yes to the meta tag with the viewport attribute.
3. adds ember-a11y-refocus addon for accessible routing.
4. adds a main element with id="main" around the {{outlet}} in app/application.hbs (needed by ember-a11y-refocus).

Tooling
We continue our efforts to detect accessibility issues as early as possible, working to make continuous accessibility a reality. Thanks to the efforts of Judith Lung and other community members, the linting automation made available by [ember-template-lint] continues to increase! Additionally, the community continues to maintain ember-a11y-testing, our testing tool that uses axe-core to provide excellent dynamic testing support. Thank you for all you do!
We're seeing an increase in individual accessibility efforts as well, even useful outside of the Ember ecosystem.
In particular, Agathe Badia's Colorblindness Emulator is an easy-to-use browser extension that anyone can use to test the color-contrast in their designs. She gave a fantastic talk about colorblindness with lots of scientific detail at EmberConf 2022-- check out her talk and the browser extension to become more knowledgeable in this area, it's really fascinating.
My own pet project, A11y Automation Tracker, itemizes potential violations and tracks the automation that exists to prevent these issues. It's already being used to inspire additional tooling and in project planning, to help keep teams on target and figure out where automation exists…or doesn't exist yet, and opportunities exist to build something new.
More to Ship
As always, there is still more to do. While concentrated efforts have been made to improve Ember's website, there is still more work to be done to improve the guides and the API docs, most notably, getting the updated styles from the ember-styleguide applied to both of those sites. Over the last year, the effects of the global pandemic really hampered progress on the website in general; get in touch with the learning team in the #dev-learning-team channel (on Discord) if you are able to help out with this. We can use the help!
We're also experimenting with a digital brand shift to make Ember orange a bit more accessible - if you took this year's community survey, you might have noticed the slight color change. This was based on some color experiments-- so keep an eye out for an RFC on this topic in the near future.
It takes a lot to keep Ember's accessibility efforts going, so thank you to every single community member who has helped move us along in our accessibility journey. You have shown have the passion, patience and persistence required to make it happen and I'm grateful every day for every single one of you.