Half a pound of tuppenny rice…
… Pop goes the weasel. Or rather Popup goes the weasel.
“Sign up to our newsletter today.” “Get 10% off your first order.” “Notice: This system will be down for maintenance on Friday”. I suspect we’ve all seen popups on our screen with similar messages at some point or other. We may have even been the ones that coded them to appear.
The challenge with popups is that they often appear over content in a way that does not trigger accessibility tools.
So, what are the options? Are there better ways of bringing key content to the attention of our users? Are all popups evil and to be avoided? Let’s take a look at what the possibilities are.
This post applies to Power Apps, Power Pages, Pro-coders, JavaScript coders and more. Those creating popups via code (JS or plugins) need to ensure their code causes the trigger conditions and alerts correctly.
To popup or not to popup?
The first question that should be asked is “do we need a popup?”
The resounding, but annoying, answer to that is “it depends!”
If you are presenting a clear “Do you want to delete this” type of message then a popup naturally makes sense. If you are displaying data errors then it could be more helpful to display a message at the error point itself and setting the focus to the issue.
There is also the option of using an error screen within a canvas app, rather than a popup. This then handles the announcement element of popups. It also has the benefit of giving more room for information such as guidance on resolving data issues etc.
The UK Government Design System (GDS) has a really useful pattern for handling errors. Click here to go to the GDS Error Pattern page. Make sure you check out the other patterns and practices as there are some excellent user experience ideas.
If a popup seems necessary then there are a couple of different things to help make your popups accessible.
Make some noise!
Not literally – nobody wants pages or apps that randomly play wav files. We left that behind in the 90’s (thank goodness). For folks using a screen reader though it is important that they are aware of three things:
- A popup will open
- One has opened
- One has closed.
This is where ensuring that labels, tooltips, tags etc are used effectively to announce what is happening. Having an Accessible Label that says “More info button to open popup window” lets a screen reader user know what the button is, and what it will do.
Likewise on web pages (Power Pages, HTML content etc) there is the ARIA-haspopup property to declare within the document model what will happen. There’s a fantastic page about using the property over at Digital A11y which you can get to here.
Focus people, focus!
When a popup is displayed it should take the focus for accessibility. This means that people using keyboard, or other alternative, navigation are in that popup and not left on the button that opened it. It also means that it is announced for screen readers so that the user knows the popup has opened.
The Live Regions property on Labels controls uses the aria-live property defined by the W3C in their Web Content Accessibility Guidelines standards. This lets screen readers know that there is a new live region that is the main focus. A word of caution though – this doesn’t always work well on controls that are hidden and then made visible. Plenty of testing required if you go this route. You can find a really useful resource on Live Regions by clicking here to go to the Microsoft Learn page on the subject.
Within a Power Apps Canvas App another option is to make use of the SetFocus PowerFX command to set the active control to the header of the popup. This then gets announced to the screen reader user and makes it clear that a popup has appeared. It also helps with keyboard navigation, making using the tab key to move control focus more intuitive.
There is a great page about the SetFocus command that you can find on this Microsoft Learn page by clicking here.
Remember consistency!
This is a useful, essential in fact, principle to apply to designs and builds. If you are consistent in the approach used it ensures that people know what to expect. If you adopt an in-line error management pattern but suddenly throw in a popup then it confuses users of all kinds.
This is even more important with accessibility as the challenges posed by requiring alternative solutions can take a lot of energy. Dealing with inconsistent UI/UX approaches amplifies this and puts all users on edge, but more so those with accessibility requirements.
Thanks for reading “Pop goes the weasel”
Thank you for reading this latest post in the A to Z Accessibility: Power Platform Edition. Hopefully this has given some food for thought and maybe even a few ideas for the future.
Please check out the rest of the series either by going to the table of contents on the launch post here or by heading to the category page in the top menu or by clicking here.
Content in this series is © Mike Hartley. I am happy for folks to quote or reuse snippets (with attribution) but please let’s not go all Clone Wars on this. This has taken a lot of work to compile so please do not copy whole sections or I may have to set Jar-Jar Binks on you. If there are any corrections or suggestions, then please use my social links to contact me. I am always happy to add additional content and remarks with full credit given. Likewise, these pages will evolve as my learning and understanding grows, so make sure to keep this bookmarked and check back every so often.