According to the The Accessibility Project screen reads make use of JavaScript.
A common misconception among web developers is that screen readers only read the non-JavaScript page. Due to this misconception, we sometimes assume it’s unnecessary to make JavaScript apps and other functionality accessible. This is categorically false.
Source: MYTH: Screen readers don’t use JavaScript
The question for me is still, in which way?
I place emails similar to this using JavaScript. A small function decrypts the value and stores it in the href-attribute as well as it replaces the placeholder text:
<a data-value="[encrypted email]">This E-Mail is being protected against bots. […]</a>
Which becomes something like this on document ready:
somebody#somedmaincom
My questions are:
Is this way accessible?
Do I have to apply an aria-role in addition to make clear, that the content is replaced with the real values using JavaScript?
Is it accessible? It depends on your JavaScript function. It would be easier to look at a page where this was implemented.
A few comments:
In general, as far as a screen reader is concerned, a link is a link and the screen reader will just read the link text ("This email is being protected... ") and the fact that it's a link. It's up to the browser to do something when the link is activated (but see comments below).
Your sample code doesn't have the href attribute. This usually means that the "link" (it's not treated as a link without href) cannot be reached with a keyboard, which would be an accessibility problem. Fix this by adding href (with any value), e.g. add href="#".
How do you trigger your script? A screen reader user will use a keyboard, so you'll get an enter key press to activate the link. Do you watch for mouse click events? Links (<a href...>) are a special case, pressing enter on a link will trigger the onclick event, so you should be OK here when following the link.
You mention placeholder text: this is a link and not an input field, so I assume you change the link text? How do you do this? If it happens on mouse hover then it would not be triggered for keyboard users (including screen reader). Add e.g. an onfocus event that triggers the same function when the keyboard focus reaches that field.
When you change the link text using JavaScript then the screensaver should "see" the change and read the new text (if it still reads the old text try a different method to change the link text, there are several ways to do this in JavaScript). I'm not sure though if the screensaver will read the new text immediately or if you need to move the screen reader focus back onto the text again yourself. You can force the screensaver to read the new text (no matter where the focus is) by adding the attribute role="alert" to the container element that contains the text.
If you have any other mouse events you also need to add corresponding keyboard events. But I think this is everything. Post a link to an example page then I can comment further.
Related
I'm very new to React and Javascript, but hoping someone might be able to offer thoughts regarding how to reliably switch keyboard focus on a route change. In the following, selecting any of the menu items(green box is an example) on the LHS leads to a change in the main screen(orange box), but keyboard focus remains on the LHS after pressing Enter.
What I'm trying to achieve is that the keyboard focus switches to being the text highlighted(blue box), thus giving a better experience from a usability point of view. Having searched google, I believe to command to achieve this to be one of the following:
document.getElementById('content-container').focus();
document.getElementById('reviews-in-progress-title').focus();
with the stated Ids being those from the blue boxes in the debug tools. They represent the main screen and specific element, respectively however, neither achieves the desired effect.
What I am able to achieve is switching focus to the element highlighted in the red box using the following:
document.getElementById('sortable-column-manuscriptTitle').focus();
So, my question for the floor is: why is it that I'm able to switch focus to the red box, but not the blue one? It feels like this will be a pretty common (and solved/understood) problem, but I'm not currently able to crack it. Any input gratefully received.
Thanks,
Phil
Some browsers won't allow the focus to be moved to an element if it's not an interactive element. In the blue box, you have an <h1>, which is not natively focusable. In the red box, you have a <buton>, which is focusable.
To get around it, add tabindex="-1" to the <h1>.
This will allow the focus to be moved to a non-interactive element via JS but won't allow the user to tab to it.
Now, having said that, in general you should not move the user's focus unless there's a really good reason for it. You mentioned you wanted to do it for a
"better experience from a usability point of view"
As a keyboard only user, I would find that a worse experience. If I'm a new user to the app and I wanted to explore the LHS menu to see what's available, I would tab to the menu, press enter or space to select the menu, then see what appears on the right. I'd then want to tab to the next menu item and select it to see what appears, but you moved my focus over to the right so now I have to shift+tab all the way back up to the menu. If I were using a sip-and-puff device or another assistive technology instead of a keyboard, that's going to be a lot of effort.
So your intention is good but it might cause a lot of difficulty for some users. That's why I recommend not moving the user's focus unless there's a really, really good reason for it.
Of course the opposite argument can be made. If the focus is not moved then the sip-and-puff user will have to navigate all the way over to the right side to interact with what appears.
You have to do some research to see what might benefit the most users without adversely affecting other users.
I am trying to build a Chrome extension that generates texts on Twitter. I am struggling with injecting the text in the inputfield.
Here is how I do it:
If the user has already input some content, it works great
If the user has not already input content, I have to slightly change the HTML (remove the default <br> and add a <span>)
However, on the second use case, it just doesn't work. The placeholder stays visible and the inputfied is broken.
See it in action:
=> https://www.loom.com/share/4bac993ba2cd4ee4a38fc209e751e323
(images if you don't want to check the video)
Am I missing something?
Is there some kind of JS variable on change in addition to changes in the HTML?
Thanks
I'm mainly interested in the a11y aspects
So as you might be aware, sometimes you might wish to have a button that acts as an anchor.
These are 4 ways (I can think of) of approaching this issue:
1. Button inside an anchor element
<button>Button</button>
2. Anchor inside button element
<button>Button</button>
<!-- Also should it be a href or button onclick (?) -->
3. Anchor styled as a button (without a button element)
<a class="buttonLike" href="//redirection">Button</a>
4. Button acting as a redirection (without an anchor element):
const button = document.getElementById('button')
button.addEventListener('click', () => {
window.location.href = "//redirection"
})
<button id="button">Button</button>
I've tried to find an answer to this myself. Closest I could find was this excerpt:
According to the MDN anchor spec, which states the following:
Anchor elements are often abused as fake buttons by setting their href to # or javascript:void(0) to prevent the page from refreshing, then listening for their click events .
These bogus href values cause unexpected behavior when copying/dragging links, opening links in a new tab/window, bookmarking, or when JavaScript is loading, errors, or is disabled. They also convey incorrect semantics to assistive technologies, like screen readers.
Use a <button> instead. In general, you should only use a hyperlink for navigation to a real URL.
Unfortunately this doesn't help me too much. Basically all it states is you should not use the third approach (anchor styled as a button) if you don't mean to provide a real link to it, which is not what this question is about.
Is there any official WCAG on this subject matter that I was unable to find or?
Option 1 is not valid HTML.
Option 2 is not valid HTML.
Option 3 is the correct choice here.
Option 4 is semantically incorrect.
Semantics are one of if not the most important aspects of accessibility.
There are two things at play which dictate option 3.
The first is that an anchor should be used only to jump to sections and to navigate between pages.
The second is that a button should perform actions on the same page.
Now if you want to style a call to action link to look like a button that is fine but make sure you use the correct semantics, but make sure that CTA leads to a new page or it isn't semantically correct.
And although it is swearing on StackOverflow to mention SEO, a hyperlink rather than a JavaScript redirection will be far better.
The first and second rules of ARIA say:
1st rule : If you can use a native HTML element [...] then do so
2nd rule : Do not change native semantics, unless you really have to.
Interactive elements like a and button can't contain other interactive elements:
The a element may be wrapped around entire paragraphs, lists, tables, and so forth, even entire sections, so long as there is no interactive content within (e.g. buttons or other links).
So, as what you want to do is linking to a page, your third solution is obviously the only one correct.
I think you might have confused the "bogus" stagement which refers to your 4th example.
From my little experience with Accessibility and semantics there is no "one size fits all". It really depends on your priorities and the user experience you are aiming for.
A <button> gets all the accessibility goodies from the browser automatically: Being selected or pressed using the tab or spacebar/enter keys.
A <a> element is a link, links are meant to be used as links or anchors within a page.
Anchors are not as important in comparison to a button within a page. From a user experience point of view; a button is used by people to interact with a UI, either to confirm or make the UI do something. Pressing a button provides a different feedback compared to a link. Anchor links on the other hand help a user with finding content within a page.
Again, it really depends on what you are trying to do:
Is this a terms page or an article? Then list your anchor links without any button-like styling
Does this a link that has to look as a button so users find it easier to spot or interact? Then style it as a button without it being actually a <button>.
I have a web page with an odd behavior on part of it.
On most of the page, the input tags work just the way one would expect.
Here's an input tag I put in to test:
<input name="vanilla1" value="vanilla" />
In one part of the page, I can click on the field to edit it, but only at the front of the field. So, if the input tag had a value of "vanilla", I could click in front of the "v" and start typing or deleting. But it won't let me click between the two "l" characters and start typing.
It's not easy to just post a full working sample, I would have to retype by hand a lot of code.
If I wanted to get that behavior I don't have a clue of how to do it.
Any ideas of what to look for that might cause this?
It's obviously not disabled or readonly because I can edit it.
When I inspect the problem input tags in the IE DOM explorer, they don't look any different from the input tags that work as expected.
There's javascript, html, angularJS and dojo, plus the esri gis api css libraries in the technical mix.
A few more observations:
In IE, when I click on a working input tag that already has a value in it, I get a little X show up on the far right of the input box. If I click on the X the field is blanked out. On my problem input tags, when I click on them, I get the X but clicking the X does not work. So I appear to be accessing the right object.
When I inspect the object, everything looks normal. No javascript events attached, it's not read only or disabled.
Isn't it like covered by another node or something like that?
Did you check it in all browsers or only in IE?
Try to open Chrome DevTools and click the "Select an element in the page to inspect it" (top left corner of the DevTools window, CTRL + Shift + C shortcut on Windows) and hover over that input. See if there's possibly any element that may cover it. If there's - voila! Remove that overlay and you're good to go. If not - I don't have any ideas for now.
I'm making a large and complex application and I need to set tabindexes to help user navigate through the pages. This is a private application so I don't have restriction about (ab)using javascript (jquery).
I currently have these questions.
1) How do you force with javascript (jquery) the browser to move the cursor inside a specific textbox as soon as a page has loaded? I noticed that often browsers don't automatically put the cursor inside the first tabindexed input. I want a surefire way that forces it there no matter what.
2) Some fields that activate ui enanchement (namely jquery ui datepicker) have problems with tabbing (like having to push tab two time to go away from it), is there any way to avoid this?
3) How do you read and set tabindex with jquery? I have some fields that get hidden/shown based on user action and they should be able to "give" their tabindex to other fields if they get hidden, is this a problem, does the browser still consider a tabindex after the page has loaded?
Thank you very muchh
To put focus on a specific textbox, do this (assuming textbox id is #firstBox): $('#firstBox').focus(); See more examples here: How do you automatically set the focus...
Not particularly because the DatePicker is also its own UI, so it has various objects within it that can be focused on (which is what tabbing picks up on).
Actually, now that I've thought about it, if you hide a field (AKA, "hidden") it will not have a tabindex and the other tabs will fall in line with what is defined for the browser (typically top to bottom, left to right order). You shouldn't have to worry about setting the tabindex manually.