I am improving the accessibility of a website to make sure users can easily navigate using the keyboard only. There is a button that generates a file, but after clicking on the button, the generic browser download dialog appears at the bottom of the page, and the focus still stays on the button. Users with a screen reader are not notified about the dialog.
There is a way to focus on the dialog when it appears?
I am able to focus on elements of the page, but since the dialog is a browser feature, I have no idea how to do it!?
I will appreciate any guidance what can you give me. Thank you!
You do not have control to do this, plus this is expected behaviour and there is nothing you need to do.
Screen reader users will go out of the active screen using shortcut keys if they wish to access the file.
Other considerations as you said "button" in your question
You should not use a <button> element to generate a file. File downloads should always be a hyperlink (<a>).
If the document requires variables to be passed and you are able to pass them via a GET request then the hyperlink href should be the URL + GET parameters.
The advantage of this for everyone is that they can middle click to open the document in a new window (or right click and choose "open in new window" etc.), plus it works without JavaScript and is easily indexed by Search Engines.
Also adding the download attribute to a hyperlink has some advantages, especially as in some screen readers it gets signalled to users that this link will download a document.
When creating a download link you should state the document type (pdf, word etc.) and document size for accessibility. You can do this with visually hidden text if your design does not allow for it.
I have written a reasonably in-depth answer on how to add the file size and file type info for screen readers here. About 70% of it is relevant to you.
Related
I have a requirement to make a button that has a tooltip which provides some simple statistical information to a user. (a student's grades for example: "Homework: 100%, Exams: 85%") When the user clicks that same button it should bring up a modal with more detailed information. (Like each assignment's grade for example). I need this to be accessible for screen readers. I am using Bootstrap 5 as a framework. I've seen suggestions that are not ADA compliant for accomplishing this task. What is the best way to do this and have it be accessible?
If the tooltip is only available to mouse users, then that would be an accessibility issue. A keyboard user should be able to tab to the button and see the tooltip.
Say what you will about IE but it had a nice built in feature that tooltips (title= attribute) were displayed by the browser when the user navigated to the element with the keyboard. Fortunately, Edge also does this. Chrome and Firefox do not so you'd have to code this yourself.
Secondly, the tooltip text needs to be programmatically associated with your button so that screen readers can announce the tooltip text. You should get this behavior for "free" because of the "Accessible Name and Description Computation".
The "accessible name" of the button should come from the button text (step F in the previous link, "name from content"). Eg <button tooltip="grades">open dialog</button> will have an accessible name of "open dialog".
The "accessible description" of the button should come from the tooltip (step I ["eye"] in the previous link) if the description can't be found in other attributes (such as aria-describedby). Eg <button tooltip="grades">open dialog</button> will have an accessible description of "grades".
When a screen reader user navigates to the button, they will typically hear the accessible name followed by the accessible description (among other info such as the type/role of the element and possibly the state [such as aria-pressed]). So you shouldn't have to do anything to get the tooltip read but you'll want to test it in several browsers (Chrome, Firefox, Safari) with various screen readers (JAWS, NVDA, Voiceover).
Note that the screen reader user can turn off descriptions so that they'd only hear the accessible name and not hear the tooltip, but that's totally up to the user. As long as you coded it correctly, you don't have to worry about that scenario.
There's no real way to make a tooltip on a button that's accessible, since touchscreen users have no way to trigger it without triggering the button. Tooltips are also confusing, since even mouse users who can trigger a tooltip may not realize there is anything there to trigger.
The best approach in your case is likely to include the information from the tooltip in the modal itself as plain text. (You can keep the tooltip or remove it.)
This will improve the experience for other users too. This "simple statistical information" seems like it would be handy, and having it as part of the modal allows it to be copied (for example), unlike a traditional tooltip.
For constructing the modal itself, I would follow Bootstrap's example code.
I'm curious what's the proper way to push the screen read to read <span>read me on load</span> first (it's in the middle of the html page) when the page is loaded?
Even
role="rude"
doesn't help for some reason.
Thank you.
What you are using is not part of ARIA live regions. You want either role=alert or aria-live=assertive (though in an early draft "assertive" was originally "rude").
Now, that being said, live regions are intended for use on an already-loaded page. If you are making a dialog, then your HTML might look like this:
<div role="alert" aria-live="assertive">
Anything in here will be announced as soon as it changes.
</div>
If you want the dialog to be announced at page load, then consider hiding its contents and then using script to display its contents once the page has finished loading.
If you need to make it announce as soon as the page loads and it is not a dialog, consider moving focus to the element at page load using script. By placing focus, the browser will announce whatever it is.
For this to work, however, you cannot just place focus on a <span> as it is not interactive content. You can make it interactive by adding a tabindex attribute. If you do that, then you will need to add a role describing what the element does (you can use role=region if you are stuck) so that the screen reader can announce what it is instead making the user think she has landed on a control or otherwise expect to be able to take an action.
If you are moving focus to the element for users without screen readers, or if the very first thing the page displays at page load is an alert of some sort, then this should be fine.
However, since you have provided no context and no examples, and given all the ways this can be done that are far worse than doing nothing, please ask yourself this:
Is the thing you want to announce…
…an alert or dialog?
…a control that already can receive keyboard focus?
…going to be given focus for all users, not just those with screen readers?
If you end up saying no twice then you should not do this.
If you can provide an example URL that shows what you want to do, then I am happy to help you get it working. Otherwise I fear you may be coding something that ends up creating a trap or barrier for screen reader users.
This question already has an answer here:
Why are buttons discouraged from navigation?
(1 answer)
Closed last year.
The community reviewed whether to reopen this question last year and left it closed:
Original close reason(s) were not resolved
From my understanding, buttons are used to carry out functions and links are used to navigate the user to a different page. But what is best practice in terms of opening and closing a modal?
<a id="testModal" href="#">Open Modal</a>
or
<button id="testModal">Open Modal</button>
<button>
Change the <a href="#"> to a <button> and put your event handler on it.
Some more context on which elements belongs where....
Does the Control Take Me to Another Page? Use an Anchor
If, when clicked, tapped, or activated by keyboard or voice (or insert novel interaction method here), the user is whisked to another URL (including an anchor on the same page), then use <a href="[URL]">. Make sure you use the href attribute and that it has a real URL, not a “#” (otherwise you’re probably relying on JavaScript, which is not at all necessary for a hyperlink). If an href points to just a “#”, then you’re probably doing it wrong. If it points to a named anchor as part of your progressive enhancement efforts, then that’s totally valid.
Does the Control Change Something on the Current Page? Use a Button
If, when activated, the user is not moved from the page (or to an anchor within the page), but instead is presented with a new view (message boxes, changes in layout, etc.), then use a <button>. While you could use an<input type="button">, it’s more likely you’ll get into conflicts with pre-existing styles and subsequent developers (like me).
Does the Control Submit Form Fields? Use a Submit
If, when activated, information the user has entered (either by manually typing or by choosing items on the screen) is being sent back to the server, then use an <input type="submit">. This has better live within a <form>. If you need more styling control or have to embed more than just a simple text string, use a <button type="submit"> instead.
Keyboard Considerations
Think of keyboard users for a moment. A hyperlink can be fired by pressing the enter key. But a true button can be fired by pressing the enter key or the space bar. When a hyperlink has focus and the user presses the space bar, the page will scroll one screenful. If there isn’t more to scroll then the user just experiences nothing. Given a set of interface elements that look the same, if some work with a space bar and some don’t, you can’t expect users to have much confidence in how the page behaves.
I think it’s also worth mentioning that events triggered by a space bar only fire when the key is released, whereas using the Enter key will fire the event as soon as you press the key down (prior to releasing it).
I think there are two possible cases.
Your content is only visually hidden in page or visible in page (can be read by screen readers) and can be hash linked, then an anchor tag might be appropriate (this case is not so common, eg: use case is if you are highlighting a paragraph or image on the page as a modal).
In almost all other cases, your modal is loaded on the same page and is in no way navigated using a url link (except through ajax for accessing data possibly, which doesn't count). Hence it is a custom functionality and a button is the appropriate choice.
Sort of by definition, a dialog is something that will pop up over the current window. You're not really leaving the window, it's just temporarily unavailable. Once you're done with the dialog, you typically go back to the window. So in that respect, you don't want to use a link because you're not going to another page. You're doing some action on the current page. Use a button.
When using a screen reader, I will often bring up the list of links (Ins+F7 in JAWS) to see what pages I can link to. I'll also bring up a list of buttons (Ctrl+Ins+B) to see what actions are available on the page. I would expect the action to bring up a modal dialog to be in my button list.
I'd like a hyperlink on a page to open its site's landing page, in a new tab if it's not already open, or, if it is already open to have the browser switch to that tab.
My idea for this was to use the target attribute but the problem is that the tab for the landing page doesn't have a name that I can refer to.
So my question is, can a tab be named by the page loaded in it so that it can be referred to by the target attribute?
In general, no.
However, if you open a child "window" with JavaScript, you can retain a handle to that window and modify things that way.
In general, browsers control the behavior of how a link opens. Some default to open in the same viewport, others default to a new tab, and still others default to a new window entirely.
The best thing to do, however, is to not try to control this and instead allow the browser (and more importantly, the user) to decide how the clicked link should be opened. This allows your power users to control how they use your site, and at the same time keeps the behavior of the browser consistent for your users, which is a critical component in keeping your users happy.
Every solution I've seen so far for opening a new browser window uses the target property in to set it to "_blank". This is frustrating because in some browsers it only opens a new tab AND combine that with the auto-resizing behvaiour at http://www.facebook.com/connect/prompt_feed.php?&message=test, it basically mangles my browser whenever I try updating my status from my site.
How can I be sure to open a new window when a user clicks on a link?
Thanks!
Trindaz on Fedang
Popups are windows, they just have some features disables. You can make a popup act like a regular window by enabling these features. For example, if you open a popup with
window.open('url', 'name', 'width=500, height=500, status=1, toolbar=1, location=1, menubar=1, resizable=1');
the window will have a toolbar, a URL bar, a status bar, menus, and it will be resizable. It will the same as any other window.
Keep in mind, however, that many browsers block window.open() under some conditions, and some of them will open new tabs if you specify a lot of features. Some are weird about it too; Chrome, for example, uses scroll bars on popups by default, but if you specifically tell it to use scroll bars in a popup (using scrollbars=1), it will open in a tab instead.
So basically there is no way to be completely sure that your page will always open in a new window, because browsers all handle this stuff differently, users can change settings too. The code above is probably your best bet if you have to have a new window, but you might want to look into other options.
window.open(URL,name,specs,replace)
function newwindow()
{
myWindow=window.open('','','width=300,height=300');
myWindow.document.write("<p>This should open in a popup</p>");
myWindow.focus();
}
There is a legitimate reason for using Target=_blank that everybody has completely overlooked, and that is when a website is written as a BOOK with chapters/pages and the Table of Contents must remain intact without using the BACK button to reload the previous page (Table of Contents). This way all a surfer needs to do is close the Target Page when finished reading and they will be back to the Table of Contents.
Lucky for us that HTML5 has reinstated the Target="_blank" code, but unfortunately the "Block Popups" must be unchecked for it to work.