Introduction
Welcome to the first post in my A to Z of Accessibility – Power Platform Edition: An ARIA to Accessible Text. Don’t fret, I’m not going to burst into Nessun Dorma, but I am going to be presenting an ARIA and talk about Accessible Text.
ARIA is especially applicable to Power Pages but the concepts, as with all Web Accessibility Initiative guidance, apply to all areas of the Power Platform.
Accessible Text is especially relevant to Power Apps, Power BI and Power Pages
An ARIA for an Accessible world
ARIA stands for Accessible Rich Internet Applications and is the standard for making web content and applications more accessible. It covers everything from user interfaces to JavaScript, HTML coding to dynamic content, and more. It forms part of the Web Accessibility Initiative (WAI) which includes the Web Content and Accessibility Guidelines (WCAG). You can never have too many acronyms really, can you?
Information on ARIA
Full details on ARIA can be found by clicking here to go to the W3C website. There are also some really good resources and articles available at the following links:
- Mozilla Development Network – ARIA – Accessibility | MDN (mozilla.org)
- Hubspot, including a handy Website Accessibility Checklist to download – The Beginner’s Guide to ARIA Accessibility (hubspot.com)
- WebAIM – WebAIM: Introduction to ARIA – Accessible Rich Internet Applications
When talking about ARIA there is often the phrase “No ARIA is better than bad ARIA” (or similar words). It really is something that is “all or nothing”. If you don’t adhere to the guidelines, then you are creating a poor experience for those using accessibility tools. It’s a scenario where you do need to do it properly or do nothing. Of course, by doing nothing your sites and applications can fail accessible standards, not what I am advocating!
The 5 Golden Rules of ARIA
Whilst there is a lot of detail around ARIA itself, there are 5 rules that summarise ARIA usage:
- If you can use a native HTML element or attribute, then do!
It’s better to do this than to try and make it accessible by re-purposing elements and adding ARIA properties. Using ARIA incorrectly can actually end up introducing serious and significant barriers for accessibility tools and users. - Don’t change native semantics unless you really have to.
Work within the framework and structure that’s been defined, it’s there for a reason and is designed to work well. - All interactive ARIA controls MUST be usable with a keyboard.
This is a major thing of mine as keyboard navigation and usage can be so frustratingly appalling. There’s no reason for making things that cannot be EASILY used with keyboards and other input devices. We need to remember that not everyone can use a mouse or touch screen! - All interactive elements must have proper semantics and cannot be hidden.
If you design any page that has things like buttons, links, controls etc then they need to be visible. This means no using “aria-hidden” attributes for this! Yhey must also be identified with the appropriate roles etc. This ties in with the keyboard navigation rule and affects anyone trying to use screen readers. - All interactive elements must have an Accessible Name
Wherever there is an interactive control on a form there must be accessible text that can be used by screen readers. These should be descriptive, but not long winded or wordy. If you’re not sure how it works then try it out with Windows Narrator, or the free NVDA screen reading tool. This can be found on the NVDA website by clicking here
Testing ARIA standards
This is going to come up a fair number of times during this A to Z, but the best tool I’ve found for doing Accessibility testing on websites is the WebAIM WAVE plugin. This is an extension that’s available for Chrome, Edge, and Firefox. Details of the extension are available by clicking here. (WAVE Web Accessibility Evaluation Tool (webaim.org). There is also the excellent Accessibility Insights toolkit from Microsoft that provides some automated testing along with a list of checks that you can work through to check your site, and to an extent an app. The website also includes tools for Windows app development and even Android app development. More details on this can be found on the Accessibility Insights website by clicking here.
As part of the testing that the extension does it checks for ARIA tags and settings and flags up where they are missing, incorrect, or done correctly. The tool also tests other accessibility standards using the Web Content Accessibility Guidelines (WCAG) checks.
The other really important test is real life users who use accessibility tools. The saying “not about us without us” is a really key part of any accessibility development and work and should be prioritised where possible.
Accessible Text
If I posted a link that just said , with no context and no indication what it would do or where it would go, what would you do?
OK, daft question as we’d all probably press it. Imagine though, living in a world where links and buttons, controls, and entry fields, were all like that. Where every time you saw a text box it just had “text box” in front of it, or even worse something like “text_c35dag”. Quick question – how many of you did click on the link?
This is the reality experienced in too many places, by those who use screen readers and other assistive technologies. So, what do we do about it?
Alt Text – Power Pages, Power Apps, Websites, Documents, Presentations etc…
I’ll be covering this topic in more depth over on the letter I when I take a look at images, but it also has a place here. Alt Text is what describes images on a page for people using screen readers.
Screen readers cannot tell you what an image is. Pretty logical when you think about that one. So, what we need to do is include some text that describes the image in a way that lets screen reader users know what is going on, and they don’t miss key content.
Writing good Alt Text is a bit of an art, one I am learning myself. Too little information and the user is left with more questions than answers. Too much information and you may need to go and wake them up by the time it’s done.
The key is to make sure that there is the right amount of information to get the point across. If we took an image Mona Lisa and simply put “The Mona Lisa” in the alt text that is not going to help someone who has never seen it. Likewise, if we wrote a whole essay on what the image was showing then it’s just going to push people away from your site. Something simple like “The Mona Lisa showing a white female with an enigmatic smile on her face” might be enough to do the trick.
This applies anywhere that images are used, including social media. Posting GIFs might be a really funny and cool way of responding to a thread, but without alt text you are immediately excluding screen reader users from the conversation. Some networks make this easier than others, and it can often be that you cannot add alt text if using images in replies (LinkedIn I am looking at you!). If there’s no direct way to include alt text, then put it with the image. I will often put “Alt Text: The image below shows…” to get the point across.
Alt Text in Power BI
WHAT?!?! Has the universe lost its mind? Mike writing something about Power BI! Yes, it’s true folks. My name is Mike, and I am writing something about Power BI.
OK. Now the cathartic moment is done, and the shock dealt with, let’s move on to the subject at hand – Alt Text in Power BI.
This has its own section as reports and dashboards are a little special. They present a lot of information to the users and can be really overwhelming at times. Where Alt Text comes in is providing some context around what is being displayed and how. Unless there are specific details that jump out to a viewer of the report, the alt text on charts etc should be to describe the type of chart and data.
Where Power BI adds extra, and why it has its own place here, is that you can use Formulas in the alt text. So, when a number or data point really needs to be shouted about, you can use that within the alt text so that a screen reader user can appreciate and understand the information more clearly. I need to give a big shout out to Laura Graham-Brown on this one. We decided we would do a joint talk on Accessibility in Power BI without either of us having looked into the subject. She discovered the capabilities, and limitations, of Power BI including how to implement Alt Text. Laura is genuinely one of my favourite people ever and has been amazing support to me. You can find her over on her awesome Hat Full of Data blog site by clicking here.
Details on this, and other Accessibility features of Power BI, can be found by clicking here to go to the Power BI Docs on the Microsoft Learn site.
AccessibleLabel
No that’s not a typo but instead is one of the properties on Canvas App controls in Power Apps, including in Teams apps. Here’s the frustrating thing though – this property is not on every control, and is usuall under the Advanced Properties tab. I can fully appreciate why people a) don’t know it exists and b) don’t realise how important it is.
The Microsoft Docs page on AccessibleLabel here doesn’t really give much detail about this property. In fact, it pretty much says nothing that you couldn’t really work out for yourself. All it says is that it’s the “Label for screen readers.” and that “An empty value for Image, Icon, and Shape controls will hide the controls from screen reader users.”
This is a property that can make the big difference between an Accessible app, and one that is unusable for screen reader users. One thing I will note is that one screen reader user will have a different preference here to another user. It really is a good example of “one size fits one” and proof that it is impossible to build something that is 100% accessible. That’s because some people like concise and abrupt descriptions, so something like “Full Name text box” would appeal. Other people prefer a bit more detail, “Enter your Full Name in this text box” would be more appropriate perhaps.
What really matters above all is that components have AccessibleLabel set so that there is information for screen readers to present to the users.
Finally…
I hope you have found my Aria to Accessible Text useful and insightful. This is part of my series “A to Z of Accessibility – Power Platform edition”. Click here to go to the introduction article where I will be posting a Table of Contents, or simply check out the Accessibility section of the website from the top menu or by going directly to the category page here.