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.
Related
I have a personal website and I want to spice it up a bit while also learning some front-end.
An idea I had was that the cursor of my website would be a coffee instead of the default one, and anytime I click on any content, the coffee pours.
Any idea if this is possible and if so, what I need to do to implement it?
You can change the cursor using CSS - see https://www.w3schools.com/cssref/pr_class_cursor.asp and do something like
div {
cursor:url(myCoffeeJug.cur),auto;
}
You could then use Javascript to change the cursor shape (ie URL) when the user clicks in the div. You'd need to think how to change it back again after whatever operation the click triggers is complete.
Note that you can't do animations this way - but given that clicking on a div is likely to be quite a quick action, just switching to and back from a different icon might well be enough for what you want.
However this is perhaps not a great idea from the usability point of view. Web users are used to the basic types of cursor provided by browsers - overriding them may be cute, but it can also be confusing.
If your site is designed for 'ordinary' users looking for information or functionality (rather than for web designers, or as a showcase for your techniques), you're putting a small barrier in their way. Users who are not confident, or are new to all this, or non-neurotypical users may find it off-putting.
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 am facing an issue of aria and accessibility aria labels.
That's my problem:
After opens a page, I need that the screen reader reads the title and then stop reading the rest of the page.
I need that the screen reader stops there, and just continue reading after the user uses TABS to navigate.
does anyone know if it is possible?
The screen reader user has complete control over how much information is read. They might have their settings so that nothing is read when the page is loaded except maybe the page title. Or they might have it set so the entire page is read. It's not something you can control, nor should you. It's very user specific.
Adding to the already existing answer:
Of course you could force something like this using aria notifiy (aka on page load aria notify page title, and that's it). this would lead to the screenreader getting interrupted, the page title getting announced and then silence until the user moves (or other notification arrives). But this kind of behaviour would be super confusing to blind people, as it is pretty unnatural.
I myself am blind and believe me: Blind people, especially NVDA or Jaws users (don't know about Window Eyes) have an entire scripting language at the ready if need be. They may choose to make your web page appear completely different for them than it appears for others, react in different ways - and how verbose the page is presented (on braille display and voice) is entirely up to the blind user. Don't bother with that, they'll figure it out themselves
If the talking of the screenreader annoys them, they can always press shift to pause the screenreader or control to silence it altogether. They'll be fine.
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.
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.