Not just within the scope of auditing, writing criteria for new accessible features.
But specifically when you have to convince designers, developers, and stakeholders to make it a priority.
Getting buy in can be hard. It can be harder when you get buy in, and then you follow criteria, specifications, best practices, and things don't work out as expected.
There is never not another option. Whether it's a design change, or deviating from generally accepted best practices.
If we can figure out a way over, around or even barreling through that gap. Let's take it. (Note: I'm not advocating for hacks that would create significant tech debt, or create a poor experience for when a bug is fixed. Rather I mean we should implement 'silent' work arounds that would have no impact were a bug to be rectified. Or implement a separate pattern/design that wouldn't cause an issue and possibly could have better UX anyway.)
"In case of conflict, consider users over authors over implementors over specifiers over theoretical purity."
We need specs, guidance, and shouldn't take for granted the countless hours and hard work that people put into create documents.
But, if there's a gap in implementation, or something doesn't quite make sense or meet users' needs...
We can't just shrug and say "out of our hands."
What are the issues?
Credit: Jared Smith
But sometimes saying "no" doesn't work...
The issue with defining something like this, is that the best UX may be dependent on the contents:
These may all require different types of UX to make a carousel accessible. Not to mention various different 'add-on features', such as auto-playing, which could potentially diminish the experience for different users.
I have found luck with a single-focus CTA carousel, in projects I've had to write criteria for carousels. Simple UX and functionality created more equivalent and better general UX for all.
Note: a few days before giving this talk I became aware that ARIA authoring practices have released a carousel and they are presently looking for feedback. I would recommend we check it out and provide any helpful feedback we can.
<div role="group" aria-label="Name it!" aria-roledescription="carousel"> <!-- visually hidden --> <span aria-live="polite"></span> <!-- role=presentation added by JS --> <ul role="presentation"> <li role="presentation"> <div class="panel-bg"> <!-- img here --> </div> <a href="..."> <!-- CTA text here --> </a> </li> </ul> <!-- generated by the JS --> <div class="pn-btn-wrap"> <button>Previous slide</button> <button>Next slide</button> <p aria-hidden="true">X / Y</p> </div> </div>
Note: looping has been disabled in this example.
Dialogs are most often used to prompt the user to enter or respond to information. A dialog that is designed to interrupt workflow is usually modal. - ARIA 1.1
"Should" does not mean "must". "Should" is often encouraged, and typically the most desirable expectation. However, "should" also implies that authors "could" take another path if necessary.
<div role="dialog" aria-labelledby="aName"> <div role="document"> <!-- but why? --> <h1 id="aName">...</h1> <!-- STUFF! --> <button>Close</button> </div> </div> <div id="app" aria-hidden="true" inert="true"> <!-- base document stuff! --> </div>
role=document was added to the code example to mitigate
an issue with VoiceOver quick nav mode.
The issue here being that if a modal dialog has an accessible name, and the contents of the dialog are not wrapped in a role=document, then certain elements within the dialog may be inaccessible when quick nav is on.
This issue does not appear to exist if the dialog does not have an accessible name. Nor does it appear to exist if not using quick nav.
Initial focus placement is... opinionated...
For documents we start at the top
For modals, guidance and implemented native functionality may dictate that focus could go wherever the first focusable element exists, unless it is not in the visible viewport in which case another element must be focused.
There are various quirks in behavior, depending on the screen reader and browser used, when elements within a dialog have been focused.
I've written quite a bit about these in my article on native dialogs, and the current state of modal dialog accessibility (linked in references at the end of these slides)
HTML Design Principles WD:
4.2 - Avoid Needless Complexity
"Simple solutions are preferred to complex ones, when possible. ..."
Regardless of where you set focus,
test to ensure the best user experience!
If you've found that your methods for implementing dialogs, focusing them, etc. meet the expectations of your users, then keep doing what you're doing!
Consistency of expectations and meeting the goals of our end users is our priority!
We should remember we're far better off today than we used to be, regarding browser implementations, user experience, etc.
But there are inconsistencies and challenges that we still need to address.
Not just the hows and whys of accessibility.
But educate about imperfections, how to test, and strive for UX equality above all else.
Quite a bit of this talk is based on testing and writing I've done over the past year or so. Here are some links to those posts:
For a list of bug trackers (and a generally awesome article) see Semantics to Screen Readers.