Update from the Accessibility Working Group 🙌, syntax highlighting in markdown with ember-showdown-prism 🔦, testing your Mirage.js setup 🧪, and last, but not least, read the proposed {{ opening_double_curly() }}id{{ closing_double_curly() }} helper RFC 🆔.
In March 2020, a group of Ember developers formed the Accessibility (A11y) Strike Team, now known as the Ember A11y Working Group. The group wanted to address the issues that were outlined in RFC #595: Technical A11y Issues in New Ember Apps.
This week, Melanie Sumner (@MelSumner) published an official blog post to provide a status update. We encourage you to read the blog post. Accessible apps are for everyone and the discussions, RFCs, and addons started by the A11y Strike Team may influence your app development.
As always, we give a big shout-out to all community members who participated in the A11y Strike Team. 💜
Chris Manson (@mansona) released the first working version of ember-showdown-prism this week. This drop-in addon automatically adds Prism syntax highlighting to Markdown code blocks if you are using showdown.
This addon adds two unique features on top of the prism and showdown features. Firstly, if you provide a data-filename attribute, it will add this name to your code block including the file type. You’ve probably seen this before in the Ember Guides. Secondly, line numbers are added to the code block and are also clickable which give you sharable links if you are using Fastboot or prember.
Chris extracted the code from the guides, and with the help of Nick Schot (@nickschot) managed to give you this cool addon with these awesome features.
Check out the demo and the GitHub repo and add some cool code blocks to your blog or documentation!
Associating label and input elements using the label's for attribute and the input's id attribute.
Using WAI-ARIA attributes to improve accessibility (e.g. aria-labelledby, aria-controls)
Integrating 3rd party libraries that attach themselves to DOM elements using DOM IDs (e.g. maps, calendars, jQuery plugins)
The proposed {{ opening_double_curly() }}id{{ closing_double_curly() }} helper can be invoked in 2 ways: without any argument or with a for argument.
When no arguments are passed, it will return a new unique ID string for every invocation. This invocation style would usually be paired with a let block.
The named argument for accepts an object, string, number, Element, or primitive, and treats it as a stable reference for an ID. This allows the helper to return the same ID for a given input.
For more information on why we need the {{ opening_double_curly() }}id{{ closing_double_curly() }} helper, please check out RFC #659. Be sure to provide your feedback by adding an emoji reaction or leaving a comment!
If you're a Mirage.js user, you may want to take a look at Tobias Bieniek's (@turbo87) new blog post on the simplabs blog that discusses testing your Mirage setup. 🎉
If you have used Mirage for your testing environment, you know how powerful it can be. The post covers a different sort of test involving Mirage – tests that test your Mirage API. 🤯 As Tobias points out, true end-to-end testing can be costly in time and complexity. One way to achieve a similar assurance that your mocked API is returning results similar to your real API is to test it.
You'll also find several helpful examples of how you might go about achieving a set of tests that test your Mirage responses. If you're a Mirage user you really should go give the post a read.
Wondering about something related to Ember, Ember Data, Glimmer, or addons in the Ember ecosystem, but don't know where to ask? Readers’ Questions are just for you!
Submit your own short and sweet question under bit.ly/ask-ember-core. And don’t worry, there are no silly questions, we appreciate them all - promise! 🤞
