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.
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.
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?
I'm working on improving accessibility for a website, and I'd like to force JAWS to read a block of text in order to help the user.
For example, I have a help icon link that pops up a help modal. This modal contains some helpful text. I want to be sure that this text is read to the user. I'd like to have a solution similar to a div where I can do something like:
<div class="ForceReadText">
<p>Block of text to be read, that currently isn't being read.</p>
</div>
I'm not very familiar with JAWS, and my google-fu skills are failing me. I figured it'd be better to ask someone who might know how to accomplish this. Any ideas?
Forcing things is difficult and gives the appearance of rudeness. What I've done in the past for accessible modals is to make the icon that opens them a link, with the link pointing to the id attribute of the modal or its heading. If someone wants help, the click the link and are taken to the information (and will use the arrow keys to read the text); if not, they can just move on.
<img src="icon.png" alt="More information">
For what you are describing, it sounds like you might want an ARIA live region. MDN has an overview that may be of use.
For a quick overview, a live region is great fit for real-time updates to a page, such as errors or alerts. A live region has the ability to interrupt whatever a screen reader is speaking in order to speak the message instead. A live region does not change the location of the focus on a page.
The trick will be understanding that a page really should have just one live region.
The other trick will be getting all your messages into one live region, though it is certainly do-able if your pop-up behaves like a tool-tip (just re-use it).
If it behaves like a modal, keep reading...
Now, all that being said, the previous answer (from #stringy) is probably a smarter approach as long as you have good focus management practices (necessary for a modeal). If you do not, then a live region may be a better fit (and maybe less jarring).
Either way, take a look at these patterns and see if one addresses your goal:
2.3 Alert
2.4 Alert and Message Dialogs
2.9 Dialog (Modal)
I use Chrome's Developer Tools a lot and on the whole I prefer it to Firebug, but one thing that I've been noticing lately is that sometimes it fails to show my pseudoelements in the styles area. Sometimes it does, so I know it works occasionally, but some, seemingly, random times it doesn't. The obvious response to that would be "are you sure they are set up properly?" Which I consider each and every time it happens. But the elements are visible in the template, they just don't show up in the styles so I can't edit them.
I'm referring to :before and :after mainly because thats what I use the most.
Has anyone else had this problem? If you haven't, I'm sure this will be hard to answer, but I'll supply any more information I can. I would show you the example where I'm having trouble but it's on a private server.
Here are some examples of what I mean:
google.com - focus is set on the "search" box
gmail.google.com - focus is set on the "user name" field (actually, most web email clients do this).
stackoverflow, ask a question - focus is set on the "title" box.
Sometimes, this is a convenient feature - e.g., on Google. From a usability standpoint, however, is it really considered a good feature to have on login pages?
Personally, I have often entered my user name, started to enter my password, then the page finished loading and had focus put back onto the user name field. Unfortunately, since I have complex passwords that force me to look at the keyboard while typing, I fail to notice when focus shifts. I often wind up typing my password in the unmasked user name field for anyone standing behind me to see.
Another situation, less dangerous but still annoying, is when I'm typing a url in my address bar while my homepage is still loading. As soon as it finishes, however, and if I'm not done entering the url, focus is stolen from me and put on some other field.
Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? Do problems like this bother ordinary (i.e., non-programmer) users?
These are really two separate questions with different answers:
Q: Should focus be given to the input field the user is most likely to use?
A: Most definitely yes, if "most users" really is 90% or more.
Q: Should this happen when the webpage finishes loading?
A: No. The "onLoad" event is a pretty stupid place to put this. The input field should get the focus as soon as it appears - it's usually completely irrelevant when the page finishes loading. Just put a <script> tag that sets the focus right after the input element itself.
I personally hate it when websites assume the focus. The main reason is that on my laptop, if I'm using the track pad and hit the backspace key it will automatically navigate back to the previous page. If focus has been placed on a textbox it will treat the backspace as tho I'm trying to delete a character.
My personal preference (and this has very little to do with best practice) is that it nothing should have initial focus, but the first tab will take it to the element that you want to have initial focus.
The same happened to me in Gmail, I find it slightly annoying, especially since it should be easy to circumvent:
In the OnLoad event handler, check if the input boxes (username or password) already contain text. If this is the case, do not change the focus.
As with all simple solutions, I would not be surprised if there were some strange side effects that render it unpractical, but I would give it a try anyway.
Oh, and if it works, why don't you send an email to Google? ;-)
That being said, I consider this behaviour a usability glitch, something that is not a bug, but slightly annoying. Don't annoy your customers. Fix it.
I think only we programmers have the habit of typing even before the page gets loaded ;-)
Most of the non-programmers friends I have wait till they see the "Completed" signal from the loading area.
But the 2 issues above are les annoying than having to move our mouse pointer/use tab everytime to type in what we want (username, password) in sites which do not have focus on a particular control.
"Should websites and/or browsers be programmed so that focus won't change if the user is already interacting with the site or the browser? "
I think browsers should be enabled to do this than the websites. Becauase it will be another trip back to server and can be frustrating for connections with low speed.
Overall I think this is just another minor issue/annoyance which we can live with. As I said only we programmers jump in type even before the page loads. Most of my friends dont know that they can type before the page gets loaded :)
There are sites where you acutally have one usecase a normal user uses keyboard for (normal user - as some, like me, use keyboard to navigate also). Sites like Google search actually expect you to just enter what you're looking for and hit enter.
Sites with multiple input areas and multiple exit paths though sometimes put initial focus somewhere too, and then it gets annoying. It gets even worse if they haev some odd tabbing order of their input areas - so they actually force you to use mouse.
I personally don't see the changing of focus when site finishes it's loading as an issue, not for a general user. But, as I mentioned, if it's really useful, it's a matter of what's the usecase in your particular application. And this might be a matter of showing the application in it's beta-stage to some people and performing usability tests.
Yes, focus should default to the most likely place for a user to start typing. Not doing so is textbook bad UI design.
When focus defaulting interferes with something you're already doing, this isn't an inherent problem of focus defaulting, it's a failure of an inadequate implementation. This, among other reasons, is why I put together a generic 'smart' autofocus script that does things like leaving you the hell alone if you've already started typing.
(Yes, I know it's hairy. Most of the hairiness is dealing with cross-browser issues -- a failing of Firefox, actually, for once.)