Is it ok in regards to accessibility to scroll content into view? Is it disorienting for some users to have the page move by itself?
For instance, if a dropdown opens and only a few options are visible, is it better to let the user scroll the whole dropdown into view or to do this programmatically?
Scrolling into view seems like a nice UX improvement (we're avoiding an extra action from the user) but also possibly important accessibility-wise (the user might not realize there is important content below the fold, so we're making sure they see it).
On the other hand, moving the whole page seems like it could be jarring to some user, who may lose track of where they are on the page...
Good question. There may be some that benefit from it, but others will definitely find it disorientating.
Without knowing more about the actual case, I would default to not auto-scrolling, because auto-animation requires a number of other things to be in place.
There are some WCAG rules which only apply when there is automatic movement. (e.g. https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide)
Also the fact there's a CSS media query to accommodate this kind of thing shows that this is a feature that some users will prefer to avoid.
If you're using a CSS transition to handle this, it should be quite easy to put it in a prefers-reduced-motion media query, and the browser preferences would offer a mechanism to switch off the feature, making it compliant with SC 2.2.2
Even if you're doing the scrolling entirely with javaScript, you can still access the media query.
As an alternative, or even as an additional hint (belt and braces), you might consider adding a visual affordance to the last visible item indicating "more...". I have seen this handled with an ellipsis, or downward-pointing triangle/caret, but those idioms aren't strongly established for this kind of thing.
Screen reader users may be at a small advantage here. If you've marked up your popup correctly, the AT will announce the number of items, visible or not. :)
Good luck!
Related
WCAG's definition of functionality
processes and outcomes achievable through user action
link to source
Following WCAG's definition for "functionality", it seems intuitive that just as functional elements should always be keyboard focusable, non-functional elements should not.
However, in accessibility matter, naïve intuition can be misleading. As I could not find any definitive guidelines or failure criteria for this on W3C site, I'm asking here:
Is it ever a good practice to make a non-functional element keyboard focusable?
If there are W3C or other official standards supporting your answer, please mention them.
Note 1: Please do not provide scrollable but otherwise non-interactive elements as an example - for our purpose, scrolling is an interaction.
Note 2: Somewhat related, but not a duplicate of the question "Should text ever be focusable for accessibility? I'm specifically thinking about key-value pairs", also somewhat similar to this question: "Accesibility vs. read only inputs", but that was asked in 2013, and its single answer isn't authoritative enough IMO (and I'm guessing is incorrect for today's accessibility conventions).
Is it ever a good practice to make a non-functional element keyboard focusable?
Yes, but in very rare circumstances.
Oh, you want a longer answer? 😋
Tab panels are a prime example (and the only concrete example I can think of) of when tabindex="0" is useful.
In this instance it serves no purpose other than to allow a user to easily navigate to the panel so they can read it's contents.
This is demonstrated and explained on the W3 Example of manual tab activation page.
The reason this is suggested is that it functions in a similar fashion to a "skip link".
All the tabs are operable with the arrow keys, but the whole tab list is one tab stop.
Then when a user has opened the tab they want to read they can press Tab in order to jump to the content instead of having to read out the rest of the tab options.
Some "fluffy" examples
The only other time I have seen this used and it felt correct is in a "live chat" application when you could Alt + Tab through the conversation items. This felt better than using headings, sections or other ways we may make something keyboard navigable (and arrow keys didn't feel intuitive).
One last one that comes to mind would be data tables, sometimes you may want a table to receive focus so that a user can navigate by arrow keys. So it receives focus to activate the component and let people know it is interactive via keyboard.
I am thinking of someone not using assistive tech but who uses the keyboard due to mobility impairments in this instance.
However that is just speculation I have never implemented that myself and if I did it would probably be because a highlighted row changes a graph etc. (which I am sure you would count as interactive!)
Any official guidance?
With regards to official guidance, I doubt you will find something concrete. Obviously WCAG 2.4.3 - Focus Order does come into play here as adding a tabindex="0" to everything is not a "logical focus order", but it will not give you a definitive answer as it has to allow for custom components etc.
I am afraid this one is a "best practices" rather than a rules scenario. You would probably still pass WCAG if every item on the page had a tabindex="0" as WCAG doesn't focus on user experience but rather on whether something can be used at all. However nobody who relies on assistive tech would want to use the page with a hundred tabindex="0"!
If you adopt the principle that the focus should always be visible, then situations can exist in which the only way to make that be true is to put a non-interactive element into focus. A skip-navigation link needs a destination after the navigation header, but it is possible that nothing in the main region is interactive. A modal dialog, when dismissed, needs to have a focal successor, but its dismissal may cause the triggering element to disappear and leave no other element, or at least no intuitively reasonable successor element, interactive.
Another scenario: A user action could cause informative messages (hints, clues, annotations, etc.) to be inserted at various points throught a view. They might all be in live regions, but that would not make them easy to locate. Making them focusable would allow the user to navigate through them sequentially, ensuring that none of them is missed and no laborious searching is required.
I've seen a few error dialogs implemented this way, where the only interactive element on the dialog was the OK button, and they decided to set tabindex="0" on the message text.
This meant they could put focus on the OK button when the dialog opened, for faster dismissal, yet allow screen reader users to tab to the message text. This was probably more common before we had role="dialog". Overall I would say that making a noninteractive element focusable should be situational and rare. Don't do anything that would confuse users. But if it results in something that's intuitive and easier to use, I would say go for it.
I'm tasked with evaluating some legacy web pages (classic asp) for accessibility. You can assume the HTML is not perfectly formed and that it's loaded with inline javascript and that we make use of javascript libraries that vomit HTML to create dynamic features. It's a circus in there.
While I recognize that the obvious answer is to re-write the page(s), that's not an option in our given time tables. So I'm trying to find the best way to make the pages work with a screen reader. Here's what I think I know.
We can use JAWS scripting to instruct the browser how to read the page.
We can use ARIA attributes to give the pages better organization and structure.
Specifically, I'm trying to figure out:
Question 1) If a JAWS script is present, will it be used exclusively by the browser/screen reader and ignore any improvements I make in the underling HTML structure?
Question 2) Could some well-place ARIA attributes give the page enough structure so that the default screen reader properties will work in an acceptable manner (without a JAWS script).
Question 3) I suspect the tough answer is that I would need to do both, which I'm trying to avoid because we barely have the capacity to do just one. But we don't want to lose a customer, of course. :-(
Many thanks for any input.
Instead of explaining only to JAWS how to access your pages, use JavaScript to explain it to any Assistive Technology (AT) for the web. I expect the same effort, while it will profit way more users.
In a JAWS script you would need to describe ways to access DOM nodes that are not accessible. That would include
speaking out information that you have to find elsewhere on the page
adding keyboard navigation where it's missing
Both can be done in JavaScript, probably even easier (you'll need to address DOM elements).
What you will need to avoid is restructuring the DOM and changes to classes, since those are most likely used by the scripts that generate them.
But I'd expect that adding attributes and keyboard handlers will do no harm to the existing scripts. Beware of already existing handlers for focus or keyboard events, though.
I would recommend making a list of attributes and handlers you suspect to conflict with the existing scripts, and searching the scripts for these, like onkeypress or onfocus event handlers.
The absolute best way to make your application/site accessible is to use semantic HTML. It doesn't matter if that HTML is generated by asp or jsp or whatever.
If you have a table, use a <table>.
If you have a heading, use an <h2>.
If you have a list, use a <ul>.
Use <section>, <article>, <nav>, <aside>, <header>, <footer>, etc
That's how you create structure on your page that a screen reader user will appreciate.
If you can't use native HTML, then fall back to ARIA, but treat it like salt. A little bit greatly enhances the flavor but too much spoils the meal.
If you can't use a native <h2>, then make sure you use the appropriate role and attributes.
<div role="heading" aria-level="2">this is my custom h2</div>
If you can't use a native <header>, then make sure you use the appropriate role and attributes.
<div role="banner">my header stuff goes in here</div>
I would recommend totally forgetting about JAWS scripts. It doesn't matter if that's what the customer thinks they should focus us. It's not about that customer. It's about that customer's customers. The end users. They should be able to use whatever screen reader they are used to using and most comfortable with. That's the whole purpose of accessibility - making the site usable and accessible by as many people as possible using whatever assistive technology they are used to using.
Following the Web Content Accessibility Guidelines (WCAG) will lead you to that result.
I'm reviewing and recommending changes/fixes to a small web application which was recently enhanced to be more accessible.
The problem I keep running into is that there doesn't seem to be anything which details how screen readers should (or even do) work.
For instance, if you look at the Accessible Rich Internet Applications (WAI-ARIA) 1.0 specification for a TabPanel and the Authoring Practices guide state a basic definition and how it works, but doesn't really answer a question like "should the screenreader speak the contents of the TabPanel when it becomes visible?"
That example is problematic in that I need to convince the business requirements it shouldn't be spoken, yet nothing actually says one way or the other. (The best I can do is point out that the examples from the Authoring Practices guide are not spoken.)
For that, and a half dozen other issues it would be really nice to have a guide that says "This is what a screen reader does (or should do) when it encounters this element/role."
Does that exist?
There are some very simple principles:
Screen readers will default to start reading the page in DOM order from the beginning to the end. This will be preceded by some basic stats of the page such as the title and the number of links, headings etc. However users will generally not simply allow the screen reader to completely read an entire page and will interrupt the reading to start navigating
If a user knows the page, they will choose a way to navigate to the things they know on the page. Common navigation mechanisms are by headings, forms, landmarks, links, tables etc. If the user does not know the page, they may navigate and explore using different strategies similar to the way that a sighted user would scan a page with her eyes.
When the user navigates, they move their virtual cursor. Normally the focus will follow this cursor jumping from focusable element to focusable element as they are encountered (this is configurable). The screen reader will read out whatever it encounters as the user navigates this. This is akin to a sighted user scanning the page for what to read. The key here is that THE USER NEEDS TO CONTROL WHAT IS READ OUT by navigating around. The one caveat for this is that if the user activates a control that causes some other part of the page to be updated and a sighted user would expect to know that it has updated immediately or know its value, then the application should read this out using ARIA-LIVE.
As you will note, that last point is where this crosses from the technical accessibility into the usability realm. Here are some common mis-conceptions that novices hold.
You need to make everything tab focusable for screen readers: NO you do not, the screen reader can see everything without it being tab focusable,
You need to announce every update to the page: NO you do not. If a user is interacting with a tab, they know through experience, that selecting the tab will expose its contents and there are keyboard commands to get to that content. You do not need to even tell them that the tab has been shown, you simply need to update the selected state of the tab.
You don't need to announce anything: NO, you do need to decide which information is important enough to announce automatically. For example, if you are implementing a chat application, it would be dumb if the user had to navigate around to hear that messages have arrived from her friends. These should be announced automatically.
I strongly suggest that you bring a blind screen reader user into your organization and have them demonstrate to your execs how they do things to illustrate these points.
UAAG
You have to look at the User Agent Accessibility Guidelines (UAAG):
http://www.w3.org/TR/UAAG20-Reference/
They are not intended to define what a screenreader might do but what informations must give the user agent to assistive technologies.
For instance, for giving the focus to a tab panel, you can read the following points:
2.1.4 Separate Selection from Activation
3.3.1 Avoid Unpredictable Focus
Guideline 4.1 - Facilitate programmatic access to assistive technology
5.1.1 Comply with WCAG
WCAG
The WCAG defines what a web developper should do to make his content accessible. It wont tell you how the screen-reader will react, but how you should act to provide the needed informations.
For instance, the focus does not have to trigger a change of context
http://www.w3.org/TR/2015/NOTE-WCAG20-TECHS-20150226/G107
But as long as the user ask a change of context, that's ok.
And the position of the focus will then define the data to be read, except the case of aria live regions.
Important : Accessibility and screen-readers are two different things
You can't resume your accessibility policy to screenreaders only.
And you won't find guidelines oriented to screenreaders only. They are made the general way to not forget all kind of people with disabilities.
That being said, a screenreader will chose the way it acts in the most predictable way. The only thing you might do is testing that your application complies with a logical way of doing things. And if a screenreader does not act as normal, it might be a misconception that could be improved either in your code, either in the assistive technology.
This may sound like an opinion answer, but I believe there's no reliable documentation - mainly because each individual accessibility user has particular requirements of their screenreader. Some don't need text to be spoken aloud while others do. Some have selective preference of what is spoken out. You're even able to change the speed at which text is spoken aloud.
Since all of the major screenreaders are highly customizable down to extremely minute details, this is all dealer's choice.
However, by having the standards and requirements set out for developers to follow and produce consistent applications, it allows the screenreader to interpret information consistently so that the user has the best experience possible. How the screenreader relays this experience is purely up to the user.
One small note, I've addressed my answer directly to screen readers and not the typical WCAG/ARIA guidelines which are widely available and specific enough to achieve what you need as a developer.
From a User Interface design point of view when is it better to disable a control or to completely hide it. I have attached an example. In both case if the "Enable ASP.NET" checkbox is clicked the "Select. Net Version selector is enabled.
I would argue that it's almost always best to just disable. Hiding controls means you're leaving a portion of your functionality/configurability a mystery to the end-user. Unless there's a compelling reason to keep users in the dark, I wouldn't.
Your example of a checkbox that enables/disables or hides/unhides a dropdown box is a good one. If users aren't aware that checking the box allows them to select further options, they may never check it and find out, because they don't realize the option they're looking for is there.
Many of us, as developers, come from the "try everything" mindset when it comes to using a piece of software. Normal users don't think that way, and that's not a bad thing, either. It just means we have to keep in mind that not everybody will do what it takes to discover a piece of UI that's been hidden. Leaving it visible but disabled lets them see that there's something there for the having should they decide they want/need to use it, rather than leaving them either wondering if the software does something or never even considering that it might.
This really depends on the context of the example. In this case there is some value associated with disabling the control as it provides a visual affordance that enabling the ASP .Net checkbox will have a determinable outcome.
If the outcome of the checkbox is actually a whole series of non related suboptions or the parent control was a dropdownlist which determines which child elements become available then it would be better to hide / show only those elements that are appropriate to the current selection.
One other point, if you are describing "hiding" the controls as control.visible = false in code rather than display:none then remember that the output will actually not be rendered into the browser at all. This may be a concern if you are catering for disabled users with browsers requiring stricter accessibility requirements etc.
To me that depends on user knowledge. If the user knows what should follow I tend to give them as much information as possible so I would show it disabled. If the user is clueless as to what follows I hide as much as possible. Sometimes I do different things on user role and sometimes it depends on the average user of the application and their expected understanding of the underlying issues.
hth,
\ ^ / i l l
I prefer to disabled the control, so the user can see that he may have something to fill out. But it can be usefull to hide it if you are restricted on space.
It really depends on the situation
I was listening to a recent episode of Hanselminutes where Scott Hanselman was discussing accessibility in web applications and it got me thinking about accessibility in my own applications.
We all understand the importance of semantic markup in our web applications as it relates to accessibility but what about other simple enhancements that can be made to improve the user experience for disabled users?
In the episode, there were a number of times where I slapped my forehead and said "Of course! Why haven't I done that?" In particular, Scott talked about a website that placed a hidden link at the top of a web page that said "skip to main content". The link will only be visible to people using screen readers and it allows their screen reader to jump past menus and other secondary content. It's such an obvious improvement yet it's easy not to think of it.
There is more to accessibility and the overall user experience than simply creating valid XHTML and calling it a day.
What are some of your simple tricks for improving the user experience for the vision impaired?
Creating accessible pages is something that is hard to think about if you have never done it. However, once you learn the basic concepts it is very easy to do in 95% of the cases. I will mostly be repeating what others have said, but:
Only use tables for tabular data
Make sure you use the semantic tools available to you via HTML. This means using TH with a scope attribute. Use <em> instead of <i> and <strong> instead of <b>. Use the acronym and abbrev tags. Use definition lists. I can expand on these things if anyone wishes.
One of the most important things is to use the label tag on input fields. For every input field, radio button, checkbox and textinput you should have:
<label for="username">Username:</label><input name="username" />
Add a "skip navigation" or "skip to navigation" depending on where big chunks of text are. If you are working on a government site this should be second nature that everything you're creating allows you to skip repetitive information.
Do not use colors for emphasis.
Ensure that all of your text is resizable. This pretty much means don't use "px" in your css.
I will re-emphasize this: create semantic pages. Use H tags for your titles. Use ul/li for navigation.
Use the alt attribute on all images. If you have a spacer gif... well.. don't. Otherwise, explain what the picture is of and what its significance is to the content it is associated with. don't use "a chart" as your alt tag. Use "Chart of YTD finances: $5,000 Q1, $4,000 Q2, $8,000 Q3" or something similar.
Provide closed captioning or transcripts for all audio and video components
The key here is to provide those with visual, hearing and motor impairments the same experience as those with standard physical capabilities. If you can't tab into a field, a screen reader can't either. If you can't click on the text next to a check box to select it, the screen reader doesn't know the text is related to the check box.
You should frequently view your site without stylesheets (ctrl-shift-s if you have Firefox and the Web Developer Toolbar) to see if the page makes sense. If it doesn't make sense to you as a sighted individual, it won't make sense to someone using a screen reader.
Check out Fangs
Fangs is an in-browser tool for Firefox that emulates what a screen reader “sees” when visiting a Web page. Its function is simple: to output a transcript of what a screen reader will read out to a user when a Web page is visited. It’s a helpful tool for quickly analyzing if you’ve structured your content effectively so that it’s understandable and usable by vision-impaired individuals, without forcing you to learn to use (and purchase) a screen-reader application such as JAWS or Windows Eyes.
It's been awhile since I've been at a job where we had to adhere to Section 508, but here's what I remember that hasn't been touched on by the other posters...
Only use tables for data. Do not use tables for layout if you can avoid it.
When using tables for data, your column headers should be nested in TH tags and you should use title and scope attributes. Your table tags should use the summary attribute.
Images should all have a value for the alt attribute that describes what's going on in the image and if the image serves no purpose (it's a shim image or something similar) then the alt attribute should be set to empty string.
Try using a text to speech reader and/or navigate only through the keyboard and/or turn off stylesheets. I believe you need to purchase JAWS, but I'm sure there are free screen readers out there. You need to experience a site through a screen reader to truly understand how difficult most web pages are to navigate without the cues that screen readers interpret.
"Vision impaired" includes colour-blindness. I used to work with someone who couldn't distinguish red from green too well, so any applications that used a traffic-light style interface was very difficult for him to use. In the industry we were working in, alerts in rows were colour-coded, so another form of display was useful for him, such as an extra column in the row with the text of the alert type ("emergency", "warning" etc).
Biggest problem with screen readers is usually tables to position things on your page. Screenreaders can't really handle those. Put stuff in div's in your html and put them in a sensible order. Then position the div's on your page with css. Use tables to display content that should be in a table.
The code for many web pages is structured as:
Header
Top Navigation
Left Navigation
Content
Footer
When structured this way, then the hidden link for "Skip to Main Content" is beneficial. However, with CSS layout, you may be able to reorder this so that you have:
Content
Header
Top Navigation
Left Navigation
Footer
You then use CSS positioning and floats to move these different elements around on the screen to make the page look the way you want it to look.
The main advantage to structuring a web page in this way is that if the browser doesn't support the CSS, then the content is first on the page. In addition to screen readers, this is beneficial for mobile devices and search engine spiders.
For partially partially sighted we need to make sure text is not excessivly small and contrasts the background color substantially. We should also make sure text is resizable by using relative sizing units such as em's rather than absolute units like px's (although, in my opinion, this is becoming less of an issue as browsers are increasingly favoring zooming over text resizing).
For users of screen readers, it's helpful to get a good idea of the way screen readers are actualy used. The following article presents guidlines based on observations of blind people browsing the web using screen readers; it's a little out of date now, but gives you a good feel for what will help screen reader users, and what won't:
http://redish.net/content/papers/interactions.html
Additionally, the American Foundation for the blind have a section of their website dedicated to advice for web developers on how to cater for vision impaired users.
In addition to the visually impared, we need to consider those with disabilities that prevent them from using a mouse, and also those with neurological disabilities. If anyone can provide resources giving advice on how to cater for those individuals, that would be great.