I'm working on a site that requires WCAG 2.0 AA adherence, but although we try to make tab navigation usable on our sites, it does detract heavily from the design due to the strange borders and outlines being rendered when you click a focusable element.
My thinking is, hide all focus states until the tab key is actually pressed.
So, my question is, does this pose any potential problems with accessibility technologies for the web?
Remember that sometimes focus is placed on elements without using a keyboard, such as via script or third-party tools (like screen readers prior to page interaction). Also note that even screen reader users do not necessarily use the Tab key (for example, I can navigate the headings on a page by pressing H in most screen readers, and on mobile I can navigate a page elements without using a keyboard at all. Also note that some users with cognitive impairments benefit from focus styles even when using a mouse.
As such, if I were reviewing a site that disabled focus styles only until someone pressed the Tab key, I would still fail it for 2.4.7
Focus Visible. It might be helpful to read the Understanding SC 2.4.7 document for a little more context.
To answer your question, yes, removing it does post potential accessibility problems.
All that being said, I would instead challenge the designer to do what designers tend to do best — work within constraints. Come up with focus styles that are not distracting, with styles that are perceivable, operable, understandable, and robust (so, for example, it meets contrast minimums). It has been done before, so there is no reason it cannot be done again.
Related
I am trying to select a dynamic calendar on a website. My goal is to open the calendar and input dates as I need to. I am not able to open the calendar by "Press button on web page" or "Click link on web page" with my selected UI Element. There are no ID's available to select. I have tried using the div class names with no luck. I have tried altering the selector to make a custom selector that looks for div names containing part of the class name. The 'Name' attribute in Power Automate is unavailable for the UI Element.
After trying all this, I noticed an Icon that is part of a div for the calendar, has
aria-hidden="true"'. When I checked the MDN here it has a warning statement: "Warning: Do not use aria-hidden="true" on focusable elements."
With being unable to select the calendar with standard and custom selectors, am I being blocked by the accessibility setting? Is Power Automate unable to focus on the calendar opener from aria-hidden="true"?
I don't know power automate, but what you observe makes sense. The attribute aria-hidden=true tells assistive tools such as screen readers and voice control software to ignore the element, as if it wasn't present at all.
A focusable element must never be aria-hidden=true. A screen reader won't know what to say when landing on it, and, as observed, it won't be reachable using voice control.
That's simply a pure accessibility fail (I would even call it stupidity, but well).
Technically, the solution is very simple: remove that stupid offending aria-hidden=true. Those who made that calendar probably put it there because:
they thought that screen reader and voice control users will always enter a date by hand and won't ever use the date picker
the date picker hasn't been made accessible, and so it's better to ignore it completely rather to present something only partially accessible
They copy/paste the code from elsewhere and didn't pay attention
They have no excuse for the third one, and for the two first, both reasoning are just wrong. Even if it isn't perfect, it's better to have a little something rather than nothing.
Keyboard-only user or screen reader user don't necessarily mean eased to enter a date manually. ON a mobile, the virtual keyboard is often painful to use, and people with limited movement sometimes use a device with only a few available keys (such as enter, tab, escape, and arrow keys only). Additionally, both might be combined if you think about someone who has a strong dyslexia and an inability to use his hands (the device would be actioned with feet, blinking eyes, etc.).
In theory, you shouldn't ever use custom widgets if you can avoid it. For entering dates, the standard exists: input type=date and friends.
Using standard widgets is the best guaranty to have something accessible at long term. Even if it might not be 100% accessible right now, it's getting better as the time passes.
Sadly, UX designers often don't like standard widgets much because it doesn't look like what they want, and there are still a few older browsers which don't support them all very well.
Tab trapping is a fairly well established pattern (example). Typically for the sake of accessibility, it allows keyboard users to navigate inside dropdown menus and modals. What's concerning however are the implications for users now that the native functionality of the tab event has been overwritten with a new behavior (looping). This isn't a big deal for sighted users, but it is problematic for users of Assistive Technologies like NVDA and JAWS that critically rely on that native tab functionality.
WAI-ARIA has a solution for informing Assistive Technologies of when native keyboard functionality has been overwritten in the form of aria-role="application":
Keyboard interaction is completely under the web author's control and
can be anything associated with the particular widget being
implemented. In a slides application, for example, a widget could be
created that uses the arrow keys to position elements on the slide,
and uses audio feedback via an ARIA live region to communicate the
position and overlap status with other objects. Focus is being managed
via aria-activedescendant.
The tab , Space and Enter keys, as well as Escape , must be handled by
the application. The one exception is if focus is set to a standard
widget inside the application that supports keyboard navigation from
the browser, for example an input element.
This would imply that any component that employs tab-trapping should necessary have a role="application", always.
However I don't believe this common practice. Sites like Target.com for example (that use tab trapping on their dropdown menu) categorize it as a list, as seen here in the website Accessibility Tree:
I'd appreciate any experienced perspectives on this. Am I interpreting ARIA correctly here? Should components that employ tab-trapping always be decorated with role="application"?
Short Answer
You do not need to add role="application" provided you set the menus up as modal dialogs. With other patterns it may be applicable (highly unlikely, role="application" is a very specialised role) but at that point you probably implemented the wrong pattern in the first place.
Longer Answer
The loop pattern is fine as long as implemented correctly (and target.com did a pretty good job)
There is nothing wrong with this pattern as long as it is implemented correctly (which target.com seems to surprisingly do a quite good job of, just a few things they could do better).
Using 'target' as an example, you will notice that when you click on 'categories' for example the revealed menu actually gets treated like a modal dialog.
It has role="dialog" and the 'button' that opens it has aria-expanded.
They also trap tab focus within this modal and provide a 'close' button that appears at the bottom of the list if you are using the tab key.
All good so far, nothing wrong with looping within a modal dialog as that is expected behaviour.
They also get a few other things right, once the 'dialog' is open you cannot access any other content. For example in a screen reader you may press the keys 1-6 to find the next heading levels, you cannot do this while the menu is open as they apply aria-hidden="true" to everything outside of the menu modal (a true modal trap).
Also you can close the menu modal and focus is returned to the menu item that opened it in the first place, so they manage focus correctly too.
Finally you can close the menu modal with the Escape key, which is also expected behaviour.
So if you wanted to follow this pattern for your menus I would say go for it, they are accessible as they are and a screen reader user would not struggle using them.
What can we do better than target.com
Target got the basics right, they are just missing a few key steps.
The 'button' that opens the menu should have the aria-controls attribute just to link that together properly.
The menu items within the menu dialogs should all have <nav> elements around the <ul> (although arguably as these modals should only be accessible via the menu button this association is implied and this is a minor point).
The arrow sprites they use have focusable="false" which is good but they didn't add role="presentation" or better yet aria-hidden="true" so they do get announced if your screen reader is set to verbose. (aria-hidden="true" is preferable as support is better).
The menus themselves should not really be multi-layered. i.e. if you click 'main menu' at the top of the list it then becomes confusing as to where you are, am I still within the modal dialog? Additionally this is implemented in a way where it does not announce the first item in the 'main menu' list once you follow the link (timing issue maybe?) so it is disorientating. This is the biggest problem with their implementation.
There are other things but you get the idea, if your menu is just a single list per 'drop down' (modal), the way this is implemented is perfectly acceptable and usable and better than a lot of menu implementations I have seen.
So should I use role="application"
No.
Seriously, you will probably never need to use this during your career and it's use can break a lot of accessibility.
Oh you want more detail? No problem!
No you do not need to use role="application" here, in fact you would introduce a lot more accessibility issues doing so.
role="application" implies that all the controls are custom and that you should disregard the standard website controls. (you are basically telling the user / screen reader 'treat this like a desktop application where shortcut keys will be explained via the menus etc.' and 'expect some strange behaviour that is not associated with websites, do not rely on your normal keyboard shortcuts as they probably won't work')
As this follows a standard web pattern (trapping focus within a modal) adding role="application" would actually confuse people.
You mentioned about the Tab looping, but within the list it functions as expected (pressing the down arrow at the end of the list does not loop) so the Tab looping only occurs within the modal.
I think the following quote for the page I linked on role="application" summarises the important information. I have added bold for emphasis on the key points that are applicable to your question and added comments after if appropriate.
The application role indicates to assistive technologies that this
part of the web content contains elements that do not conform to any
other known HTML element or WAI-ARIA widget. Any sort of special
interpretation of HTML structures and widgets should be suspended, and
control should be completely handed over to the browser and web
application to handle mouse, keyboard, or touch interaction.
In this mode, the web author is completely responsible for handling
any and all keyboard input, focus management, and other interactions
and cannot assume assistive technologies would do any processing on
their end.
So basically if you added role="application" you would then not get the native behaviour of any element, this would introduce a lot of work! (in practice most screen readers will still allow basic functionality, but they do this because people misuse role="application")
If the web application encompassed by the application role contains
parts that should be treated like normal web content, a role of
document or article should be used.
So you would have to add role="article" or role="document" to the lists, the close buttons etc. Basically the whole thing would have role="article" anyway (as that would be the most appropriate role).
Unless you are building very complex software, role="application" should not be used.
I have a Mobile design to fulfil:
The menu is a fairly standard Accordion setup.
It starts collapsed.
Tapping anywhere on A will expand it to show the A sub-menu.
Tapping anywhere on B will collapse A and expand B.
Tapping anywhere on A Sub 1 will take you to that link.
All standard so far! But the additional Feature is that A is itself a page that the user might want to access!
We have to fulfil this very specific design, so we can't add expander controls, to separate the link from the expand.
I was originally using simple nested <ul> lists and some trivial JS to bind into the onclick events. That was fine for elements that were links OR expanders but that fell apart on bits that were both.
I tried changing the behaviour to exposes the submenu on hover, to utilise the behaviour that I discovered, and documented here: Tablets hover on first click, click on second click
That does technically work, but not very well: you can't scroll the menu properly because touching outside your current expansion will change the selection; the hover exposure of the submenu isn't animated; it generally doesn't actually work well for phones and on a small desktop screen it's completely unusable.
I've looked for ages online for an example or a library that will Just Do This, but nothing fits what I need, and we've been given this very specific design spec.
Currently my only solution is going to be to implement the 2 phase clicking myself in javascript, storing the current state of the element in data attributes and reading those before deciding what action to take on click.
Is there any better way to achieve this?
=-=-=-=-=-=-=-=-=-=-=-=
See here for SO posts about related scenarios for a traditional navbar menu:
Tablets hover on first click, click on second click
https://stackoverflow.com/questions/29354150/deactivate-hover-on-tablet
You just need sit at your computer and watch for responses in about 50 years when all programs will include multiple touch, voice recognition, and thought features to accommodate your functionality request.
Personal experience dictates this problem will not be solved in less then 5 to ten years based on Moore's Law and general apathy on the internet.
I'm enhancing the UI for an application to be more compatible with screen readers. The problem is I keep running into issues and I'm beginning to suspect that it' due to the screen reader itself.
Right now I'm mostly testing JAWS 15 with IE 8 (due to corporate limitations it's basically all I can test with at the moment) and getting some weird behavior, but as near as I can tell the aria markup and html all look correct.
For instance:
In some hidden divs (role="alert") the JAWS does not speak "button" after reading a button's name after the DIV is show. (It does speak "button" once you tab to the button though.)
JAWS is speaking elements with aria-hidden="true," which was fixed according to this thread.
Again with hidden alert divs, in some cases JAWS will repeatedly speak elements. In at least one case it will repeat the header and the first line of text infinitely (or at least until my patience ran out.)
The altText for images in table is not read when the entire page is first read. It does get read when the user navigates through the table with the table commands though. I don't even know what corret behavior is on this one...
I'm basically looking for something where I can find out if these are known issues with JAWS/IE8. And if there's a list of compatibility out there (similar to the HTML5 compatibility list) I'll be able to refer to it whenever people bring these issues up.
http://html5accessibility.com/ is a starting point to discover whether a browser has accessibility support for native elements and attributes.
If you're looking for documentation of screen reader support for ARIA attributes, check out The Paciello Group. For example, Steve Faulkner published a post on role=alert that may be helpful.
Accessibility is important to me as I'm a physically disabled developer. I'd like to make sure I have a good feel for what it takes to make a site accessible while also being pointed in the right direction for the things I'm uncertain with, or just haven't considered. So, here's what I'm comfortable with right now:
Alt text for images with meaning.
Percentage or font-relative measurements (ems) for those who need to re-size their screens.
Colors with good contrast for those with colorblindness.
Textual representation of any audio/visual material.
Questions:
Should I make a link at the top of the site to jump down to content on every page?
How is JavaScript handled by screen readers?
Is there anything major I'm missing?
WebAim.org is a great resource for all things web-accessibly related. Suggest starting off with their WCAG (Web Content Accessibility Guidelines) checklist.
Quick answers to your qu's:
Should I make a link at the top of the site to jump down to content on every page?
This is currently recommended best practice. (Eventually HTML5 semantic tags will remove the need for this, but we're not there yet. One thing to watch for: if you do use a hidden link, be sure to make it visible again when it has focus, so that sighted keyboard users don't get 'lost'.)
How is JavaScript handled by screen readers?
All depends on what you use it for. The main area for problem is if new content appears that the user is supposed to be aware of (eg. popups, expanding blocks); if it doesn't get keyboard focus, a screenreader may not read it out to the user and the user may not realize that anything has changed. This is one area where it may be necessary to test with a real-world screenreader (eg. NVDA or JAWS) to ensure that it's actually usable. A simple approach is to only have UI appear in response to user request: eg user hits return on a menu item to make the menu appear, don't make it appear merely in response to it getting focus. Then when it does appear, set focus to the first item: this is both expected behavior for menus in most UIs, and changing the focus typically also causes the screenreader to read out the new item, which confirms to the user that something has happened. (Also, if using Javascript to add behavior to existing elements - eg. make a link behave like a button - use WAI-ARIA attributes such as role="button" to let the screenreader know what the intent is so it will read out that role to the user, and will say 'button' instead of 'link'.)
Is there anything major I'm missing?
I think you've got most of the key points already covered above; the WCAG checklist should fill in everything else. One major area that is worth mentioning is to use headers (H1, etc) appropriately. For screenreader users, navigating by header is a major way for navigating a page. Typically when navigating to a page that a user hasn't visited before, the user will hit a hot-key to get the screenreader to bring up a list of headings on that page as a way of 'skimming' to get an overview. Having good link text is also important; ideally links should be self-describing, so you don't just hear "click for more", "click for more" as you tab through a page.
For newer browsers, IE8, IE9, Firefox 3?, and Safari 5 (possibly 4), and newer screen readers WAI-ARIA is the way to go. Among other things it has landmark roles which if you have an ARIA reading screen reader, such as JAWS 12 and possibly JAWS 11 and 10, the screen reader can use to jump around. It can get a bit clunky if you want things to be backwards accessible but is the direction the web is going in. Their are many other advantages to ARIA but that's the one relevant to your question. On a related note VoiceOver for the Mac is supposed to be ARIA compliant as well.
I'm not disagreeing with the selected best answer, but I would spend more time learning about WCAG 2.0 than with the original WCAG specification. Both in the United States and internationally, the Web Content Accessibility Guideline 2.0 are quickly becoming the standard. In fact, the Access Board, the group tasked with defining the guidelines for Section 508, are refreshing the standards to be harmonized with WCAG 2.0.
You can find great information by starting here Web Content Accessibility Guidelines (WCAG) 2.0.