WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: Radio Buttons Not Functioning

for

Number of posts in this thread: 13 (In chronological order)

From: JP Jamous
Date: Mon, Jan 30 2017 8:36AM
Subject: Radio Buttons Not Functioning
No previous message | Next message →

Folks,



I have various radio buttons that populate dynamically, which is not an
issue. However, if I go into forms mode, JAWS is unable to toggle between
the radio buttons using arrow keys.



1. Proper HTML semantic is being used.
2. Input fields have the same unique name.
3. No tabindex on any of the radio buttons, leaving the browser to
handle that.



The only thing that popped up at me was separate div tags. Here is how the
structure is in the DOM.



<div>

<input type="radio" id="radio1" name="offer" />

</div>

<div>

<label for="radio1">

1 year plan

</label>

</div>



<div>

<input type="radio" id="radio2" name="offer" />

</div>

<div>

<label for="radio2">

2 year plan

</label>

</div>





My assumption is that the div tags are causing JAWS not to be able to toggle
between the radio buttons via arrow keys. Although the input fields have the
same name attribute, the div is identifying to JAWS that this is a different
block of HTML. Therefore, the arrow key script is failing.



What are your thoughts?

From: Swift, Daniel P.
Date: Mon, Jan 30 2017 8:42AM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

I don't think this is the answer that you are looking for --- why not just remove the divs and style the input/labels as appropriate?

*big grin*

All the best,
Dan

From: JP Jamous
Date: Mon, Jan 30 2017 9:11AM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

I am only auditing and this is a nasty dynamic page. I have N amount of time or it would expire on me.

From: Jonathan Cohn
Date: Mon, Jan 30 2017 9:53AM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

If you are in forms mode, It is possible that if you change forms mode to
"semi-automatic" or "manual" in the insert-V options that the arrows will
behave differently. I haven't pinned down when it occurs, but sometimes
automatic forms mode causes issues.



Best Wishes,

Jonathan Cohn
On Mon, Jan 30, 2017 at 10:36 AM JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:

> Folks,
>
>
>
> I have various radio buttons that populate dynamically, which is not an
> issue. However, if I go into forms mode, JAWS is unable to toggle between
> the radio buttons using arrow keys.
>
>
>
> 1. Proper HTML semantic is being used.
> 2. Input fields have the same unique name.
> 3. No tabindex on any of the radio buttons, leaving the browser to
> handle that.
>
>
>
> The only thing that popped up at me was separate div tags. Here is how the
> structure is in the DOM.
>
>
>
> <div>
>
> <input type="radio" id="radio1" name="offer" />
>
> </div>
>
> <div>
>
> <label for="radio1">
>
> 1 year plan
>
> </label>
>
> </div>
>
>
>
> <div>
>
> <input type="radio" id="radio2" name="offer" />
>
> </div>
>
> <div>
>
> <label for="radio2">
>
> 2 year plan
>
> </label>
>
> </div>
>
>
>
>
>
> My assumption is that the div tags are causing JAWS not to be able to
> toggle
> between the radio buttons via arrow keys. Although the input fields have
> the
> same name attribute, the div is identifying to JAWS that this is a
> different
> block of HTML. Therefore, the arrow key script is failing.
>
>
>
> What are your thoughts?
>
> > > > >

From: Bossley, Peter A.
Date: Mon, Jan 30 2017 1:14PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

When you tab onto the radio group, does jaws properly report the number of options in the radio grouping and make the sound to indicate forms mode triggering?


From: JP Jamous
Date: Mon, Jan 30 2017 1:23PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

No it does not.

From: Aaron Cannon
Date: Mon, Jan 30 2017 1:30PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

A couple things I might try: Can you look at the markup of one of the radio buttons that doesn't have focus? I'm just wondering if there is some JS that is setting the name when a radio button is focused or checked. Probably a longshot.

Is this happening in more than one browser?

Does anything happen differently if you turn off the virtual cursor mode with insert+z? Any difference with NVDA? Again these are longshots.

Luck.

Aaron

--
This message was sent from a mobile device


> On Jan 30, 2017, at 14:23, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
>
> No it does not.
>
>

From: Bossley, Peter A.
Date: Mon, Jan 30 2017 2:46PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

That's odd. Is there a place you can link to that is showing this behavior live? It is going to be difficult to tell much without being able to look at the code live.


From: JP Jamous
Date: Mon, Jan 30 2017 3:22PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

Peter,

I hate to say this, but no. It is in QA and requires certain credentials to allow access. Sorry.

I will dissect it later to try to identify what the cause really is. I just wanted to real quickly on here see if any of you had something similar in the past.

From: JP Jamous
Date: Mon, Jan 30 2017 3:27PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

Thank you Aaron. I want to keep it as the default for JAWS and NVDA. I did not test it with NVDA, but I will tomorrow.

It is weird, but I am sure that something is making the SR become stuck on one radio button in forms mode.

That's old markup though. We have more accessible markup in our pattern library. It won't stop me from making the page accessible, I just think it is interesting as to why it is locking the SR on one radio button.

From: Aaron Cannon
Date: Mon, Jan 30 2017 3:46PM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

You wrote:
"Thank you Aaron. I want to keep it as the default for JAWS and NVDA."

I understand. The only reason I suggested doing the other
non-standard things was just for helping to troubleshoot what was
going on. I wasn't suggesting that that is what the end-user should
be expected to do.

Let us know what you discover.

Aaron

On 1/30/17, JP Jamous < = EMAIL ADDRESS REMOVED = > wrote:
> Thank you Aaron. I want to keep it as the default for JAWS and NVDA. I did
> not test it with NVDA, but I will tomorrow.
>
> It is weird, but I am sure that something is making the SR become stuck on
> one radio button in forms mode.
>
> That's old markup though. We have more accessible markup in our pattern
> library. It won't stop me from making the page accessible, I just think it
> is interesting as to why it is locking the SR on one radio button.
>
>

From: Bossley, Peter A.
Date: Tue, Jan 31 2017 7:56AM
Subject: Re: Radio Buttons Not Functioning
← Previous message | Next message →

My bet is on Aaron's guess- something is causing the radio group to get out of spec or there is script causing the selection of the radio button to not behave normally.
By chance what happens without the screen reader running, can you tab to the group, select an item, and then move it around via arrow key?

Peter Bossley
Director, Digital Accessibility Center
ADA Coordinator's Office | Office of University Compliance and Integrity
Student Life Disability Services
The Ohio State University
098 Baker Hall, 113 W. 12th Ave, Columbus, OH 43210
614-292-1760 Office
= EMAIL ADDRESS REMOVED = accessibility.osu.edu




From: JP Jamous
Date: Tue, Jan 31 2017 8:22AM
Subject: Re: Radio Buttons Not Functioning
← Previous message | No next message

With another page that kind of acted similarly to this one, yes the keyboard focus was placed on different radio buttons through arrow keys.

I do not want to mix this issue with the other page. I do agree with Aaron. I will be back soon on that project and will investigate deeper what the heck is occurring.

To answer your question though, I don't know as I did not have someone sighted to assist me with this one. I also did not test it with NVDA and Firefox to find out if it is more of a JAWS issue with internet explorer.

I will get back with you folks regarding it once I dissect the DOM.