Why screen readers navigate radio / checkbox buttons by directly selecting them? - html

I'm trying to be WCAG friendly and have created a group of radio buttons, which, when they receive on-change, trigger action. But when I tried to navigate it by shift+arrow, I discovered that it doesn't just focus them, but right away checks them on? Am I missing something here, or is that normal behavior?
Edit:
The code looks like this for example:
<input type="radio" name="month" value="jan">January</input>
<input type="radio" name="month" value="feb">February</input>
<input type="radio" name="month" value="mar">March</input>

You didn't post any code so I'll assume you're using
<input type="radio">
and that you have several of them all with the same name attribute and that each radio button has a properly associated label with them. (Lots of assumptions but we can only guess if you don't post any code.)
When no radio buttons are initially selected, different browsers treat navigation to them differently.
On Firefox, I can tab to each radio button in the group.
On Chrome, I can only tab to one radio button in the group.
The tab does not select the radio button. It only moves the focus there.
Once my focus is on a radio button, then the arrow keys perform two behaviors:
It moves the focus to the next (or previous) radio button in the group and
It selects the radio button.
It sounds like you're asking about #2 behaivor. If so, then what you are seeing is normal behavior.

Related

jQuery requires 2 clicks on default-checked radio button to trigger event

I have a sequence of radio buttons on a web page. On page-load, the first radio button in the sequence is selected by default.
In addition, there is a <div> associated with each radio button. (The corresponding <div>'s class is the same as the corresponding radio button's value.)
Even though the first radio button is checked by default, the jQuery (source) does not trigger until the already-checked radio button is manually clicked after page-load. I learned that I can solve this by manually triggering the click myself on page-load via jQuery.
I tried doing so with $("input:radio:first").prop("checked", true).trigger("click"); (source), which I thought would click the first radio button in the sequence as desired, but to no success. (By the way, is this code clicking the first radio button on the page, or is it clicking the first checked radio button on the page? I'd prefer the code to trigger("click") the first checked radio button on the page.)
I also already hide all <div>s in the CSS, as suggested here.
$(document).ready(function() {
$('input[type="radio"]').click(function() {
var inputValue = $(this).attr("value");
var targetBox = $("." + inputValue);
$(".radio_div").not(targetBox).hide();
$(targetBox).show();
});
});
$("input:radio:first").prop("checked", true).trigger("click");
.radio_div {
display: none;
}
<script src="https://cdnjs.cloudflare.com/ajax/libs/jquery/3.3.1/jquery.min.js"></script>
<div>
<label>
<input type="radio"
value="Bacon" checked="checked">Part 1</label>
<label>
<input type="radio"
value="is">Part 2</label>
<label>
<input type="radio"
value="Good">Part 3</label>
</div>
<div class="Bacon radio_div">Cured sugary meat</div>
<div class="is radio_div">be</div>
<div class="Good radio_div">bangin</div>
JSFiddle
How can I make jQuery click the default-checked radio button (so that its respective <div> appears) on page-load?
In addition, in my actual environment (which uses a semi-customizable web builder, so it's difficult to reproduce all the code involved), the default-checked radio button must always be clicked twice in order to activate its corresponding <div> with the jQuery. However, I cannot replicate this behavior in JSFiddle. If anyone has any insight on what might be causing this (and how to troubleshoot/resolve), I'd be happy to hear. (Perhaps jQuery could simulate a second click whenever a radio button click is detected?)
EDIT: The issue with my production environment (in the gif) was that the value of the first radio button was changing to whatever radio button was previously selected. Super ridiculous.
Because you're using 2 click functions.

PrimeFaces make disabled Radiobutton tabbable

We use a modified renderer for SelectOneRadio elements. This renderer does not set the disabled attribute on the underlying <input /> for disabled selectItems.
This is due to an accessibility requirement. Every element (also the disabled radio buttons) must highlightable and tabbable via keyboard.
Problem: when the items label is clicked, the form parameter is updated to the value of the disabled option. The disabled element is also checkable via keyboard.
Any idea how I can set the disabled attribute on the <input /> while keeping the elements tabbable?
Simply changing the renderer won't do I'm afraid. Much of the functionality related to keyboard navigation can be found in the widget code of the SelectOneRadio component:
https://github.com/primefaces/primefaces/blob/master/primefaces/src/main/resources/META-INF/resources/primefaces/forms/forms.selectoneradio.js
You will probably need to override a lot of functions there.
Every element (also the disabled radio buttons) must highlightable and tabbable via keyboard.
This is by definition a contradicting requirement that can't be satisfied. A disabled element isn't focusable and it's perfectly normal. Both always go together.
So there is basicly no good solution, as the requirement is wrong.
However, here's a little fun fact:
The onclick event is triggered upon focusing the radio button, too. You may use event.preventDefault() and this will prevent the radio button from being selected.
The radio stays focusable when using arrow keys.
When the radio button is focused with arrow keys, then it doesn't become selected.
However, it iss no longer focusable using tab, and worse, tab navigation seem to be completely broken. It is even no longer possible to go from "One" two "Three" or back.
I would therefore not recommand it, but well, wrong requirement, wrong solution.
Chrome, Firefox and Internet Explorer under Windows 10 seem to all agree on that same behavior, tough !
<form action="">
<p><label for="a1">One</label>
<input type="radio" name="a" id="a1"/></p>
<p><label for="a2">Two</label>
<input type="radio" name="a" id="a2"/></p>
<p><label for="a3">Three</label>
<input type="radio" name="a" id="a3"/></p>
</form>
<script type="text/javascript">
function f(e) {
e.preventDefault();
}
var a2 = document.getElementById('a2');
a2.addEventListener('click', f, true);
</script>

radio button tab sequencing

Default tab indexing is NOT working with radio buttons, working fine with any other HTML component e.g. checkbox, textbox etc.
Below basic code not working for radio button tab index but working fine with checkbox.
<div class="box">
<input type="radio" name="rdgroup">H
<input type="radio" name="rdgroup">E
<input type="radio" name="rdgroup">L
</div>
<div class="box">
<input type="checkbox" name="ckgroup">W
<input type="checkbox" name="ckgroup">O
<input type="checkbox" name="ckgroup">R
</div>
https://jsfiddle.net/wtyg7cLz/
Thank you :)
Essentially a radio button is a group that functions as a single element since it retains only a single value. Tabbing to a radio group will bring you to the first item and then using the arrow keys you navigate within the group....
When you assign same name to the ratio buttons, it treats you like a one control. However when you don't select anyone you can have a focus on first one and then use arrow button to select the one you want to.
Focus can move to a radio group via: The Tab key An Access Key or
mnemonic targeting the label Activation of the label (through
Assistive Technology mechanism)
The Tab key moves focus between radio button groups and other widgets.
When focus is on the group and when no radio button is selected: Tab
key press moves focus to the first radio button in the group, but does
not select the radio button. Shift+Tab key press moves focus to the
last radio button in the group, but does not select the radio button.
Source: https://www.w3.org/wiki/RadioButton
As #Just Code said:
When you assign same name to the ratio buttons, it treats you like a one control. However when you don't select anyone you can have a focus on first one and then use arrow button to select the one you want to.
For radio buttons as a group if they have the same name then changing focus will work or navigate with arrow keys like (right, left, up, down).that is the default behavior of radio buttons, it is better to leave it as default. If you prefer tab control then i guess you have to implement it with javascript, because if you give them different name user can select all different radio buttons
enter code here
<div class="box">
<input type="radio" name="rdgroup" tabindex="1">H
<input type="radio" name="rdgroup" tabindex="2">E
<input type="radio" name="rdgroup" tabindex="3">L
</div>
<div class="box">
<input type="checkbox" name="ckgroup">W
<input type="checkbox" name="ckgroup">O
<input type="checkbox" name="ckgroup">R
</div>
you could use the tabindex attribute to get a workaround after the first radio button element gets focused the user can then use the arrow keys (default) to select the desired option.
kindly check the below link for more details.
https://www.w3schools.com/tags/att_global_tabindex.asp

Radio buttons accessibility, unable to tab to radiogroup with a checked disabled value

I encountered a problem, where one radio button group is dependant on other state, which caused a disabled radio button to be selected. This is not a problem when selecting another value in the radio button group with the mouse for example, but it seems it is impossible to tab to the radio button group now. I realise that I maybe should not let this happen, but I think it is strange that you can build radio button group that you cannot change by keyboard alone. Here is a simple example:
<input type="radio" disabled checked name="test" value="1">
<input type="radio" name="test" value="2">
<input type="radio" name="test" value="3">
<input type="radio" name="test" value="4">
Is there something I can do to "fix" this behaviour, or does anyone have a good way to handle these edge cases, or how to code if differently all together to avoid this issue?
This is clearly a browser issue, although i'm not sure what would be the expected bahaviour.
The problem is that when you have a radio group, the keyboard goes to the selected element. If this element is disabled, then the focus will jump the whole radio group even if the other one are not disabled.
One "fix" would be to avoid the problem by dissociating the radio buttons in two groups and relying on some javascript code to let them appear as a whole group. You can also reimplement the whole radio button feature by using aria role="radio" on 4 div elements.
It's also possible to ask and wait for the bug to be fixed.

Best practice for form w/ radio buttons and checkbox with same name

I have a form that has a list of radio buttons and one checkbox that represents a special "button". All form elements have the same name:
<input type="checkbox" name="channel" id="prv" value="ch1">
<input type="radio" name="channel" value="ch2">
<input type="radio" name="channel" value="ch3">
<input type="radio" name="channel" value="ch4">
My idea is that once the checkbox is checked, all the other radio buttons are disabled (which works quite well with jQuery). If the checkbox is unchecked, the user can select some channel with the radio buttons.
But when I submit the form, it doesn't work at all.
$('#prv').change(function () {
if (this.checked) {
$(".fc_exp input").attr('disabled',true); <--RADIO BUTTONS
$(".fc_exp input").removeAttr('checked'); <--RADIO BUTTONS
} else {
$(".fc_exp input").attr('disabled',false); <--RADIO BUTTONS
$('.fc_exp #ch1, .fc_exp label[for="#ch1"]').prop('checked',true); <--DEFAULT RADIO BUTTON: CHECKED
}
})
Now my question is: Is there any best practice for this?
Thanks a lot and merry xmas!
I would suggest using four radio buttons - first one with option "No channel" or whatever option you need here - instead of the checkbox.
If you really need checkbox and radios - checkbox should be named differently in the form - but this will require additional code on server side to handle it properly.