I am working on a web page which is relatively long (4+ pages). For ease of use I have added the back to top link at the bottom of the page.
I would like to know, whether I can skip this link from screen readers or assistive tools by using aria-hidden="true" and tabindex="-1". Does this fail the accessibility criteria ?
Since the back to top arrow is visible at the bottom of the page, is it necessary to make this link available for screen reader users ? So far my understanding is home key serves as back to top for keyboard/screen reader users.
Any suggestions would be really helpful.
You shouldn't be focusing on any one single user's experience. For example, if you have that 'Back to Top' link in logical spots, it should not be taken out of tab order because you're only considering one type of user experience. A the same time, accessible features shouldn't impede on a normal experience.
That said, on a pure development basis, links should receive focus so it does fail since it's not completely operable.
WCAG 2.1.1 is pretty clear on this topic.
All functionality of the content is operable through a keyboard interface...
It doesn't say "most" functionality.
The home key works for mouse users too so why should they also have the ability to click on the "back to top" link and no one else?
Related
TIL that screen reader users rarely use tabs for navigating web pages and instead use specific keyboard shortcuts from their screen reader software (e.g. CTRL + OPTION + Arrow Keys in VoiceOver). This would mean that optimizing for tabbable navigation does not always make sense.
However I've seen some web pages adding tabindex="-1" to their headline elements or for elements that are not directly viewable due to overflow: scroll.
So my question would be: When does it make sense to optimize for tab navigation and when doesn't it?
E.g. in our current use case we've created a questionnaire that basically shows a question (h2 element) that can be answered with 2-5 answers (button elements). Clicking the answer will lead to a new page with the next question. When activating VoiceOver it seems like a good idea to have the question element set to tabindex="-1" and auto-focussed when the question is opened. But the learning above seems to challenge this a bit.
Thanks for your help!
So first of all you are confusing tabbing with focus. While a screen reader user may use arrow key navigation, they may also bring up a list of links on the page, or forms, regions, tables or (most often) headings in order to navigate to sections that interest them / get a feel for the page layout.
Tabbing is useful as there are plenty of people who cannot, struggle or prefer not to use a mouse but do not require the assistance of a screen reader i.e. Cerebral Palsy due to accuracy issues.
Hopefully that clears that bit up for you.
As for autofocusing an input on a multi-page form, that is more of a UX issue...is it good UX for all users if you auto-focus the form.
I would say yes, requiring people to click, tab or use shortcuts to get to the input if that is going to be the action that 99% of people need to take is not good UX.
Notice I say the <input> and not the heading.
What you do want to do is look into how to indicate this is a multi-page and multi-step form on the first page of the process.
You should also consider having a checkbox as the first step that says something like "this form is multi-page, would you like us to auto-focus the first question when a new page is loaded" and have it default to checked.
That way someone has the choice to stop the auto focus if they wish.
Additionally (or as an alternative if you do not want the checkbox) you may consider adding some text near to the submit button (and properly associate it with aria-labelledby and an ID) that explains that the next step loads a new page and the first input will be auto focused.
Another thing is that assuming you have titled the pages correctly (Form name or process - step 2 of 5) then a screen reader user can easily ensure they are on the correct page.
So focus the input if this is a multi page form, not the heading level 1.
Focusing headings after navigation is a trick for Single Page Applications (SPAs) so that might be where you have seen that, if you load the page content via AJAX then that is one of the recommended ways to handle navigation. You indicated next page "loads" which makes me think this is a Multi Page Application, but I thought I better add that just in case as a general tip.
Bear in mind that all of this advice is general. Depending on your form, site design, loading pattern, user base (experienced users / internal system vs general public) etc. the best practice may be different.
So long answer short - use autofocus on the input if this is a multi step form and you think it is appropriate and obvious that the input would be the next thing to fill in.
Then test it with someone who uses a screen reader and get feedback as to whether it makes sense or if it was confusing or unexpected.
You are making a confusion between screen reader user and keyboard user.
One doesn't necessarily implies the other.
People having dyslexia but normal sight may use a screen reader so that they can hear a text out loud instead of trying hard to read it themselves, but since they otherwise use a mouse or a touch interface, they aren't keyboard users.
People having difficulties using their hands but with a normal sight might not be able to use a mouse or a touch interface.
They don't need a screen reader, but use exclusively a keyboard or maybe another specific input device that mimique the most important keys of a keyboard (in particular, tab, arrow keys, enter and escape).
A joystick in some form can be such a device.
Considering what has been said above, designing a proper keyboard navigation and optimizing it always make sense. It may not be of important use for some screen reader users, but it's very important for keyboard users, as it's maybe their only way for them to interact with the app/page.
I am a screen reader user. With others, I believe a confusion about input focus is being associated with structural and contextual concerns. To the first question regarding when to “optimize” TAB experiences. It is always important since keyboard navigation is a supporting pillar used in my toolbox as a screen reader user. In addition, any input based non-screen reader accessibility tool is likely going to use this means of access.
As a developer, a guideline I always impress on other is the fact you want the natural structure and flow of code to do most of the work for you. Secondly, the process should follow expectations of your target audience and it seems you want to follow a “wizard” style. So, let me spell out a typical expectation for a wizard style questionnaire flow when using a screen reader.
UX point: does page reload fully or dynamically change?
This matters as this has a direct impact on my current reader “cursor” and how I will navigate to find the question.
From above statements, I will assume H2 will be used consistently. Thus, I will naturally use quick navigation to go to the first H2.
Now, I will use screen reader tools to read the question (be it TTS or braille output).
Once I feel I have its meaning, I will typically use TAB to find the first input control. Buttons are not input controls and thus violates user expectations. I am looking for checkbox, radio box, text field, and/or combo box.
If check or radio boxes, then I am assuming a group and hope for grouping (sadly rarely present) and will use tactics to deal with the situation I have found. If grouped, then I am using TABs a lot to move quickly and hear the “context” of the specific box focused with input.
Finally once I have answered the question, I am looking for the next question or forward/previous mechanism. These typically show up as buttons.
Hopefully, I am demonstrating how conventions/expectation are built using basic structure rather than trying to force procedure on the user. Thirdly, sites like a11y project can be very helpful with coding.
Let's say I have a static website which I try to make accessible.
To this end, I include a "Skip to main content" link at the top.
I also want people to know what they're getting into, so I have a disclaimer message at the top.
The disclaimer message includes a JS-driven "hide" button, but this is not accessible (or visible) to users without JS.
Which do I put first, the link to #main, or the disclaimer message?
(goal 1) I want someone who is a new visitor to the site, with JS disabled, using TTS, to see the disclaimer first.
(goal 2) But if they've been before, It probably won't be helpful for them to hear the disclaimer every time they open a new page.
Is it possible to accomplish both goals?
If it wasn't static, and included a server-side element, I could have the {hide} link be server-side cookie-based, but that is not the case.
Edit: There was a comment, which I now regret flagging, saying that "99.999999% of users" (a statistic I question) have JS enabled, implying that the other 0.000001% do not matter. I disagree with this assessment, because I strongly believe in my goal of accessibility to all 100% of users visiting my site. While perhaps it is never attainable, I will not stop trying.
Is it possible to accomplish both goals?
Since it sounds like the only tools available to you in this case are HTML and CSS, I would say no, it's not. So with that in mind…
I would add the skip link first. You could place the disclaimer between your skip link and your navigation. Though your disclaimer would be repeated on every page, it'd be no different than a nav bar at the top of your page that the user would have to listen to every time – that's why you have the skip link in the first place.
TTS users should be plenty aware that they may be missing important information if they click that link. I'm no legal expert, but I'd be willing to bet that you (or your company) are not going to be suddenly liable for damages because the disclaimer was not the literal first thing a TTS user hears when entering your website.
with JS disabled, using TTS,
100,1% (*) of users using text-to-speech do use Javascript. This includes blind people, people with vision loss, people with cognitive disorders, illiterate people or non native speakers, ...
Also note that, among them, a large part of people with disabilities will view (visually) your webpage. The "skip link" is also useful for people with physical disabilities when mouse navigation is complicated (parkinson disease, hemiplegia, ...).
The other ones (blind people) relying only on audio will not view your webpage visually but will still use a javascript compliant screenreader (Jaws, NVDA, Chromevox, VoiceOver, ...).
For instance, you can see WebAim survey where JavaScript was enabled in the browsers of 100% of respondents.
(*) The 0,1% extra is because Javascript can help improving accessibility.
I have been told by my boss to add tabindex="1" to the Accessibility link in our site footer so that it will be the first thing that someone who browses a site by keyboard can get to and read about the accessibility steps we take.
I have added tabindex="1" to the link which you can see here, but the browser doesn't seem to respect it at all (tested in Chrome/FF/IE 11). There are no other tabindex attributes on the page that I can see, so surely it should get picked up as the priority by the browser.
There are access keys used on the page, could this throw it out in some way?
I am sure it is something really fundamental, but I can't see what it is. Any help would be appreciated.
Thanks
It works for me, but as a long-time accessibility advocate I'd like to help persuade your boss it's a bad idea.
To see it working I suspect you are on a Mac and you need to enable keyboard navigation. People who need that would typically have it on already.
However, the reasons that adding a positive tabindex are not helpful include:
Someone using a keyboard (or keyboard equivalent device) and can see the screen will be confused. They press tab and suddenly end up at the bottom of the page, then flip back up to the top. Combined with the lack of focus visibility, this will be very difficult to cope with.
Someone using a screenreader will probably not notice the tabindex to start with because the main way of navigating is with 'arrowing' (using up/down to go element by element). However, if they are in the content area and press tab to skip to the next link or form control, they will suddenly go to the bottom of the page. Very confusing.
So in summary: Adding a positive tab index on a link in the footer will negatively impact the people it is supposed to help.
Here are the appropriate ways to use tabindex.
There are quite a lot of obvious accessibility issues on the site, I'd recommend getting some advice.
Windows and OS X have always bumped heads on this, but what is the general concensus on whether a Save button or Cancel button goes first in a web application?
[Save] [Cancel]
or
[Cancel] [Save]
Note: I have these buttons at the top of the form flush to the right.
Follow the principle of least astonishment: do it the Windows way ([Save] [Cancel]) unless you have reason to believe that Mac users make up a greater portion of your user base.
The key here is that we are talking "web" usability. To that point, I think it is pretty clear that the principal of least astonishment referenced in the accepted answer would suggest that right is the forward action (save) and left is the backwards action (cancel), and not what the accepted answer suggests.
The web browser is the user interface web users are most accustomed to, and 15+ years of web browsing has made it pretty clear that the back button is to the left of the forward button. It also jives with the left to right based languages that the web was initially developed for. The right is where you are going, the left is where you have been.
Even in general computer vernacular, a forward slash, /, leans right while a back slash, \, leans left.
The windows UI is the outlier here, and I think it is a poor decision to base your UI design on Microsoft's precedence.
I might point out that your top right corner positioning of the two buttons is non-standard, but I don't think it bears on the ordering of the buttons themselves.
Instinctively I always put the Save button as the rightmost element.
I think there are other things to consider. Primarily whether a Cancel button is actually needed, or whether another element (such as a breadcrumb trail pointing to the previous page) might be more appropriate.
Edit: http://www.lukew.com/resources/articles/web_forms.html - The section 'Primary and Secondary Actions' shows how visual weighting can be used to good effect as well.
For all the heated arguments this issue can generate, it doesn’t seem to make much difference in actual human performance. The advantages and disadvantages of each work out to a wash. Users appear equally likely to expect Cancel on either the left or right in web forms. There appears to be a bias to favor Cancel on the left if the buttons are widely separated, but you don’t want to do that since putting the Execute button the far right is associated with slow responses and high error rates on web forms.
I’d say the most important thing is to be internally consistent in you app, and be sure Cancel is always labeled “Cancel” (not, say, “Return” like I saw in one web app). Otherwise, put the buttons next to each other and near the last field the user will look at (which is probably not in the upper right of the form).
And don’t worry about it too much.
It's probably not a big difference either way, as long as it is clear what the buttons do.
My personal vote would be to have save on the left, as that is what people do the most often, and people read left-to-right.
Also, I would also put some space between the buttons, to make sure users don't accidently click one when they are trying to click the other.
Why do you need a cancel button at all?
On a web form, the user can almost always cancel through some other action. Putting "Cancel" near "Save" is creating a situation where the user has a good chance of firing the ejection seat when all they want to do is save.
I generally put the button which will cause the most actions to occur farthest away from the center. If your buttons are top-right, my order would be [Cancel][Save]
Familiarity is often more important than being objectively correct, since things that are unfamiliar are often, by default, less usable.
People use their Windows PC or their Mac more than your app or website. So if I were in your shoes, I'd pick the order which you think will be familiar to the users you care most about. If it's a mostly-mac audience, do it the mac way. If mostly PC audience, do it the PC way.
On a normal form, Save should be under the form fields. Cancel should be to the left or right of Save, but not too close to avoid tragic mistakes. Luke W's Web Application Form Design page has some illuminating diagrams.
Your form is unusual in that you want the buttons to be at the top. In this case I'd need to know what the page looks like and how it will be used. But since you're already breaking any flow between form fields and Save, I suspect Save should be on the right to support the natural left-to-right path.
(Windows and Mac have differing standards for button placement on dialog boxes, and they both have the buttons at the bottom. These standards do not apply to web pages.)
Why on sites like Stack Overflow, Techcrunch, Smashing Magazine, etc. are the page titles (i.e. the text at the top of the page) clickable URLs that redirect to the same page that the user is on?
Some examples:
I believe that this does not effect SEO as search engines ignore internal links.
Is it for usability purposes?
It allows you to right-click on it and choose Copy link location (or equivalent) so that you can easily paste it in an email for example. This requires less time than copying it from the location bar, and some people run their browser without a visible location bar to save previous screen space.
More than anything, it provides a link to the default state of the page.
For example, for this very stack overflow page it is a user can get here through any of the following non-default links:
Why are Page Titles on some websites (including Stack Overflow) Clickable URLs?
https://stackoverflow.com/questions/904381#foobar
https://stackoverflow.com/questions/904381?sort=date
While the default link is actually:
Why are Page Titles on some websites (including Stack Overflow) Clickable URLs?
If users are unable to get to the default state, they end up bookmarking or emailing the non-default link which propagates to new users and the problem just multiplies.
Clicking on the title link of the post will restore the default state and strip off any query parameters (?sort=date), named anchors (#foobar) and fix the story slug (/why-are-page-titles/...).
I use it to refresh the page (yes, I could press F5 too).
Yes Jakob Nielsen has stated that linking to yourself is a web design mistake (nr 10). And I agree.
More reading info here. (nr 10)
The URL redirects to the beginning of the page, in case you arrived on the page via a specific answer (all answers are also clickable URLs). This way, you get the URL of the question, not of an answer.
Not sure if this is why they did it, but I find it useful to siphon off tabs:
If I look at something briefly and think "I'd like to read this thoroughly in a minute but continue with what I was doing before", I can do this:
I can right click the link, click "open in a new tab" and then click "back" and continue nicely.
It's called a Permalink... The name implies what it is, a permanent link.
It's the same reason that each answer on SO has a link you can copy.
I think it inherits the behavior from CMS where each question is a node, which has 0<= answered question. Now think you go for a search on apache questions.
The result are displayed one after another.
In terms of CMS this is called a teaser. You get a full page with lots of questions where the question's title link to the full article(question + answers)
Its not a must, but you'll find it on most sites which uses a CMS.
As long as it does not harm anyone why would people be against it?
I prefer to have those links available as hitting refresh would reload all elements of the page instead of just following the direct link (to the same page) that uses cached elements.
Makes sense to me, I find it useful! I have a lot of tabs open so I just right click the link and go back.
To me this makes perfect sense, from a SEO view this is also good! It forces it to read the page because it's linked.
UX-wise clickable titles which don't bring the user anywhere may seem unusable though that leads us into the realm of Affordance Theory and whether or not the affordance is perceptible to users.
For example, clickable page titles may provide:
A simple method for bookmarking a page to the desktop from a browser window.
A context menu with additional choices allowing users to share a blog post or article.
A method for updating the location bar so it's pointing at the canonical URL of the page.
For the sites you mentioned, however, it seems more likely the page titles were turned into hyperlinks using absolute URLs so analytics tooling could pick up inbound link clicks – those sending the referer info – resulting in DCMA takedown notices when people copied work and didn't update the URLs.
You'd be surprised what people do when they're being incentivized to produce work contractually.