The question consists of two parts:
Is it ok (from the UX/UI p.o.v.) to make a search box on the page activated on the first tab keypress?
How to do it technically keeping the rest of the tabbing mechanism intact (e.g. the first element activated on tab keypress by default is now activated right after the search box on the second tab keypress)?
For the desktop browsers it okay. But bad UX for the mobile browser as it will popup the keyboard focus automatically comes to search box.
Set attribute tabindex="0" for the elements programmatically using JavaScript after the the search box leaves focus. Use onblur() event.
You can use tabindex=1 attribute in your search input element to achieve. Like this,
<input type="text" placeholder="Search here" tabindex="1" />
Whether you should or not, This article might help
Related
I want to do some price monitoring on the page https://reiseauskunft.bahn.de/ but when I open/navigate, a coockie banner appears in the foreground and an acceptance buttton must be clicked, before any inquiries can be done. Using the inspect facility of the browser I have noticed the buttons are within a
#shadow-root (open)
Addressing the button directly e.g.
remDr$findElement('css selector', 'button.btn:nth-child(1)')
does not find the element.
Note: A solution using Python and the selenium module might help me to get on the right track.
I have a dropdown menu. On non-touch screen devices the dropdown menu is shown on hover.
On touch screen the menu is shown on click until the page navigates away. The user clicks the dropdown show but the page still navigates away. I have added aria-haspopup which I thought would prevent the page from navigating away on the first touch of the element. But the user is still navigated to the page.
<span class="navbar-dropdown">
<span>page</span>
<a>etc</a>
</span>
How can I stop the link from navigating away on the first link Thanks
The aria- attributes are used to describe the behaviour of your element to assistive technologies such as screen readers. They don't alter the normal behaviour of the elements in a regular browser.
ARIA - Accessibility | MDN
If you want to prevent the browser from following the link, you will need to use Javascript instead.
Is it possible to force a screen-reader to read the alt-attribute instead of the text inside a button?
Example html: <button alt="user menu">DrKawashima</button>
When testing this with the built-in accessibility screen-reader in MacOS, I found that it only said "DrKawashima", and the alt-attribute was never used.
Is there a way to hint to screen-readers that I would rather have it say "user menu"?
Yes, it's possible - but beware of completely overriding the visible text of a button.
tl;dr - I recommend approach 4 here.
Your question addresses screen readers, but there are other types of assistive technology to consider. In particular, sighted people using speech control (e.g. Dragon Naturally Speaking). Take care to address WCAG Success Criterion 2.5.3: Label in Name.
Assistive technology deals with the computed accessible name of an element:
Screen readers will read the computed accessible name. Remember that the basic purpose of of a screen reader is to read what's on the screen - beware of trying to present a different interface to screen reader users.
Confusion can arise when a blind screen reader user and a sighted person are both talking about the same screen. For example, a telephone tech support person might say "Click on the button which says DrKawashima". But if this is overridden, the screen reader says the button is called "User menu", and the user can't find the button they're being told to press.
Sighted people also use screen readers. For example, someone with dyslexia may like to have stuff read out to make life easier. When the computed accessible name differs from the visible text, the screen reader is effectively lying to the user about what it says on the screen.
Speech control will try to match what a user says, to the computed accessible name. If a button has visible text, it's important that this text appears inside the computed accessible name of the element. The expectation is that a speech control user can activate a button by saying the visible text. In your example, saying "Click DrKawashima" should activate the button. This won't work if the computed accessible name is "User menu".
There's a work-around for this. Dragon Naturally Speaking has a tool to highlight all buttons using numbers: say "Click button", look for the number, then say "Choose 2". However this is a multi-step process, requiring extra effort from the user.
Note that the computed accessible name and the visible text do not have to match exactly. Rather, the visible text must form part of the accessible name.
Let's look at some examples:
Your example with an alt attribute on the button simply won't work, because buttons don't have an alt attribute. This isn't valid HTML:
<button alt="user menu">DrKawashima</button>.
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima". The alt attribute had no effect.
This passes WCAG "Label in name", because the visible text and the computed accessible name are exactly the same.
However it doesn't manage to inform a screen reader user about the purpose of the button; sighted users can probably infer this from an accompanying icon or avatar image.
The aria-label attribute can be used to completely over-ride the button content: <button aria-label="user menu">DrKawashima</button>.
The visible text is "DrKawashima".
The computed accessible name is "User menu". The aria-label attribute completely overrides the button content.
This approach FAILS WCAG "Label in name", because the visible text doesn't form part of the accessible name. A speech control user can't activate the button by saying "Click DrKawashima".
The aria-label attribute can be used to completely over-ride the button content, whilst duplicating the visible text: <button aria-label="DrKawashima, User menu">DrKawashima</button>.
The visible text is "DrKawashima".
The computed accessible name is "DrKawashima, User menu". The aria-label attribute completely overrides the button content, but it duplicates the visible text.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This approach is simple, but may be fragile because you have to manage two strings.
Include some visually-hidden text, to give screen reader users some additional context. For example, using HTML5Boilerplate's .visuallyhidden class, or Bootstrap's .sr-only class:
<button>DrKawashima<span class="visuallyhidden">, User menu</span></button>
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima, User menu". This results from the button content.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This is the simplest solution, very robust.
The aria-labelledby attribute can build an accessible name, by referencing 2 element IDs:
<button aria-labelledby="user-menu-visible-label user-menu-suffix"><span id="user-menu-visible-label">DrKawashima</span><span id="user-menu-suffix" class="visuallyhidden">, User menu</span></button>
The visible text is "DrKawashima"
The computed accessible name is "DrKawashima, User menu". This results from concatenating the two elements refernced by aria-labelledby.
This passes WCAG "Label in name". The button can be activated saying "Click DrKawashima" because the visible text is inside the computed accessible name.
This is robust, but a bit more work to implement because you need to manage the ID references.
'alt' is not an allowed attribute within a button element. The alt attribute works with area, img and input type="image". Check out more on the topic https://www.w3.org/TR/html5/dom.html#translatable-attributes and https://www.w3.org/TR/html5/dom.html#global-attributes-2
Your best bet is to use a styled <span> tag inside the <button> with aria-hidden
<button aria-label="screen reader text">
<span aria-hidden="true">Visual Text</span>
</button>
Edit: As discussed in comment this isn't the best approach.
As a speech control user can't activate this button.
andrewmacpherson's answer provides a more inclusive solution to this.
I have a web application where users can edit their profile information. This is presented as a normal web form with input fields containing the existing values:
<form action="<snipped>" method="post" accept-charset="UTF-8" id="frmEditUser">
<fieldset>
<p>
<label for="username">Username</label>
<input type="text" name="username" id="username" value="<?= $uname ?>" size="30" title="must be unique" size="30" />
<label for="username" generated="true" class="error">*<?= form_error('username'); ?></label>
</p>
</fieldset>
</form>
There are more fields, but this simplified markup shows that I am doing nothing out of the ordinary. In both Safari and Chrome (on Windows 7) I am getting some very strange behavior when trying to select existing values in these fields:
When I select from left to right, the selected text is highlighted as expected. When I place my cursor at the end of the field and select from right to left, upon releasing the mouse button the selection is undone and the cursor sits at the end of the field again.
This problem occurs at all input fields and textareas of my application, but only in Safari and Chrome. I thought it might be a javascript problem, but the problem persists when disabling all javascript. Disabling all CSS makes the problem go away.
So the problem is in my CSS. I disabled all CSS rules that have anything to do with forms or form elements, but the problem still remains.
I was hoping there is this odd chance that somebody else encountered the same issue?
Update: The problem is even more fine-grained. It seems to only occur if I select from right to left and in this process of hovering exit the field on the left edge. Not exit as in clicking outside, exit as in hovering out of it whilst still holding the mouse button for the sake of selection.
Update II: I discovered the root of the issue. It happens when selecting from right to left and in this selection process exit the form element, not the field. I added a red border around the form element. As soon as I exit it on the left side, the selection I made is gone. If I add padding to the form element on the left, it shows that the selection remains as long as I stay inside the form element.
Still a bizarre issue that I would like to solve :(
I read your question and decided to check my site in chrome and found the same issue. Go to my site www.futurekode.com and go down to the contact form and enter your name and email and try selecting the text.
On mine, it only happens to the second input field (the email one) and not the textarea either.
I found that adding display:block to the input field fixes it in chrome but not safari :/
Very weird
I have a select box, <select multiple=true, that the user populates with values via a Picklist mechanism. I would like to disable highlighting in this box because, by definition, the values in this box are the selection.
Just to clarify, I am NOT referring to text selection, which is what ::selection operates on. I'm talking about the usually blue highlighting that the browser applies to selected line item(s) when the user clicks on them.
I'm not worried about the user blindly clicking around, because I am auto-selecting all items onsubmit so that all the values get sent.
Why not just list the items in their own div instead of a select element? You aren't having the users interact with them anyway, right?
Then, you can have a select element w/ all the values you want, but make it hidden via CSS so that the user won't ever see them. It'll just be there in your form so that you can grab those values on your submit.
If I'm reading you correctly, it sounds like you're using an accumulator model where you have a "source" box (or list or select or something) and a "selected" box. Rather than accumulating into a [select], maybe use a div? If you must use a select, you could try disabling it, but that carries other visual baggage. You could also try styling the select color, but that's definitely not going to be cross-browser.
Make it disabled?
<select disabled="disabled">
This would gray it out, unfortunately- the other option might be some javascript to unselect any selections.
if i understand you correctly, the user does not actually selects the items? then why not either disable it or if customer still interacts with it, you might need to go with some JS code to help yourself