E-mail List Archives

Search E-mail List Archives for

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

From: Murphy, Sean
Date: Wed, Jun 24 2020 5:07AM
Subject: Radio Button strange behaviour in Firefox.
No previous message | Next message →

--_004_SY3PR01MB066648618D1E4E65CCCE4EAFB4950SY3PR01MB0666ausp_
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable

All,

If you visit this site for a standard radio button:

https://www.w3schools.com/tags/tryit.asp?filename=3Dtryhtml5_input_type_rad=
io

Using Firefox with NVDA or Jaws. When an option in the radio button is not =
selected. Using the tab key, takes you to each options within the radio but=
ton component. Once the option is selected, then the tab order works as exp=
ected. Using Chrome, this behaviour does not occur. Instead the tab key tak=
es you to the next control.


Note: If the option in the radio button is pre-selected, then the issue des=
cribed above does not occur.

Is this a Firefox defect?




[cid:image001.png@01D64A6B.6F067AA0]

Sean Murphy | Accessibility expert/lead
Digital Accessibility manager
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917

www.telstra.com

This email may contain confidential information.
If I've sent it to you by accident, please delete it immediately




--_004_SY3PR01MB066648618D1E4E65CCCE4EAFB4950SY3PR01MB0666ausp_
Content-Type: image/png; name="image001.png"
Content-Description: image001.png
Content-Disposition: inline; filename="image001.png"; size=2147;
creation-date="Wed, 24 Jun 2020 11:07:16 GMT";
modification-date="Wed, 24 Jun 2020 11:07:16 GMT"
Content-ID: <image001.png@01D64A6B.6F067AA0>
Content-Transfer-Encoding: base64

iVBORw0KGgoAAAANSUhEUgAAABcAAAAaCAYAAABctMd+AAAEDWlDQ1BJQ0MgUHJvZmlsZQAAOI2N
VV1oHFUUPrtzZyMkzlNsNIV0qD8NJQ2TVjShtLp/3d02bpZJNtoi6GT27s6Yyc44M7v9oU9FUHwx
6psUxL+3gCAo9Q/bPrQvlQol2tQgKD60+INQ6Ium65k7M5lpurHeZe58853vnnvuuWfvBei5qliW
kRQBFpquLRcy4nOHj4g9K5CEh6AXBqFXUR0rXalMAjZPC3e1W99Dwntf2dXd/p+tt0YdFSBxH2Kz
5qgLiI8B8KdVy3YBevqRHz/qWh72Yui3MUDEL3q44WPXw3M+fo1pZuQs4tOIBVVTaoiXEI/MxfhG
DPsxsNZfoE1q66ro5aJim3XdoLFw72H+n23BaIXzbcOnz5mfPoTvYVz7KzUl5+FRxEuqkp9G/Aji
a219thzg25abkRE/BpDc3pqvphHvRFys2weqvp+krbWKIX7nhDbzLOItiM8358pTwdirqpPFnMF2
xLc1WvLyOwTAibpbmvHHcvttU57y5+XqNZrLe3lE/Pq8eUj2fXKfOe3pfOjzhJYtB/yll5SDFcSD
iH+hRkH25+L+sdxKEAMZahrlSX8ukqMOWy/jXW2m6M9LDBc31B9LFuv6gVKg/0Szi3KAr1kGq1GM
jU/aLbnq6/lRxc4XfJ98hTargX++DbMJBSiYMIe9Ck1YAxFkKEAG3xbYaKmDDgYyFK0UGYpfoWYX
G+fAPPI6tJnNwb7ClP7IyF+D+bjOtCpkhz6CFrIa/I6sFtNl8auFXGMTP34sNwI/JhkgEtmDz14y
SfaRcTIBInmKPE32kxyyE2Tv+thKbEVePDfW/byMM1Kmm0XdObS7oGD/MypMXFPXrCwOtoYjyyn7
BV29/MZfsVzpLDdRtuIZnbpXzvlf+ev8MvYr/Gqk4H/kV/G3csdazLuyTMPsbFhzd1UabQbjFvDR
mcWJxR3zcfHkVw9GfpbJmeev9F08WW8uDkaslwX6avlWGU6NRKz0g/SHtCy9J30o/ca9zX3Kfc19
zn3BXQKRO8ud477hLnAfc1/G9mrzGlrfexZ5GLdn6ZZrrEohI2wVHhZywjbhUWEy8icMCGNCUdiB
lq3r+xafL549HQ5jH+an+1y+LlYBifuxAvRN/lVVVOlwlCkdVm9NOL5BE4wkQ2SMlDZU97hX86Ei
lU/lUmkQUztTE6mx1EEPh7OmdqBtAvv8HdWpbrJS6tJj3n0CWdM6busNzRV3S9KTYhqvNiqWmuro
iKgYhshMjmhTh9ptWhsF7970j/SbMrsPE1suR5z7DMC+P/Hs+y7ijrQAlhyAgccjbhjPygfeBTjz
hNqy28EdkUh8C+DU9+z2v/oyeH791OncxHOs5y2AtTc7nb/f73TWPkD/qwBnjX8BoJ98VVBg/m8A
AAQOSURBVEgNnVVLiBxVFD3vvarqnvQkmZloPn7QqHEgIoKgZDViVoKQiGjAnWYYs5FIxJCIm04C
ujCKZjEZFT+4cSEouslSd0FENAGFkPjBfEhipzOddNvd1VXveW5VV3f1h2C80PNevXvfued+3h2F
cfJAOUBNH4Dx9sPFtHDjrG5wpqmLf5a/o1IzWwn8Cg2ou1lgXlEKsFgcDw5sAUwA9z+AQWDnmojc
ifHgBg+mjGkoxr0ftyMieoHp2ilfLC6gEJ71ZDcgt5VXwNo7gKhBe5vTGe5X5L7TrXMtKNdJwJ14
sSGc+gR/VSribow8TfCpACunPJRWeSjSSew/C60OwkVde15VmkDRS7DuW2hdgLNCJ8QU/sQv5bDP
/P3GBjjzENNxC3y/yZxfIo8zeEFdTNDuPDQBJCH3waGXmd/jOFc+M8DwfPqVgi/Vn4A/8RYNZ5k/
Ikg2bANWncOH4Y9k9DnefOcRWOmerkhHOFtlQ6XOs/Pc6mGptQmet8iQN6LDy0nYErIqQZtZeP4s
GvUdWFlSqF6l71wP2Pg8S1fN4Q1sPRizkyAb0W7nFGxB6UJhaljHq8se/mGmhG1P6ETHp4Fyvug9
rWw0YrsNNivSgC79EKaVqkucD4DTe6t5csyN3pGG0d9A9eva02QbAaxcYRRDBJV2eHTLZGY2biXz
1jEyD9lWo3oBjpmayt9ssRy4vFxfKzw29zo+jeZHL6YnGqpzgsPpe7bfqI2At0NguTaYb0vwyZLD
5MRqWP0ePmg+P3pZcr5rpsY58BHbyo6wl3zX68C160PgjGZmhsWmc2tLMP67WGpsH3aQ5qLd+hqR
/WEs++sEbw51iqRlDcHFecxm0GY1gok3cLR5d95BCr5neplWB8iiTsO8nm3I3g5ldJBlJrJfM03Q
7lnINtZqMzzzKsouxaRtb4MXi8fI/hA0OydzIAwvXnaQy1LYiCxD1qDISbBurRoY9QkBPY/bo7ke
h2yTrEdOF1C8a5Hp2YkOQUR+PeVw+ZLqvUwp5ob1Dvffp5Jo8jM/KIjzLzAdPIcdKs7FmmLhiFuF
Yucwi7SAmOkwDC558gRNhFekLSWKYTHsOOUuULkV88VT/bRkhrvVNdSqexCHh+F7zAVNZDRI2MmP
EY0DlvvJYNPr0I45APM5l69M9q5vYFPwGqJ4H/9hVBAUqRkNMjPvr4xOKcNa3Cpno8wzy8dVhAX/
bT6wbazmd4wC8JjTfNdktr2VBKQGRrF/bwSeXZj3j6P+x3bO7ZcZ90l4AVCgk6yjMjtZA8m5Pcu0
/SSf/yVWsUvlqFsLr/UkTOEptuYcHUzxZXfZyvCzv/NR7cVC4Uu5cHPgqQvgM1dCvXEvo3iYaXiG
KPdAu48Z3VfYVfwtM/sXqjFl9oXaNQ4AAAAASUVORK5CYIIAAAA=

--_004_SY3PR01MB066648618D1E4E65CCCE4EAFB4950SY3PR01MB0666ausp_--

From: Birkir R. Gunnarsson
Date: Wed, Jun 24 2020 9:30AM
Subject: Re: Radio Button strange behaviour in Firefox.
← Previous message | Next message →

Shawn

That is an expected behavior for a set of radio buttons where no radio
button has been selected, (they're all focusable until one has been
selected). You don't see this often because one of the radio buttons
is typically selected by default (and that is the recommendation for
the pattern).
What I find odd on this page is that Chrome with Jaws announces "1 of
6" for the first radiobutton, there are 2 sets of 3. I thought they
all had the same "name" attribute (which would cause a screen reader
to perceive them as one set) but they don't.
Granted they should be in two separate <fieldset> or anotehr grouping
element, but I'm still surprised that Jaws perceives them as one set.



On 6/24/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
> All,
>
> If you visit this site for a standard radio button:
>
> https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio
>
> Using Firefox with NVDA or Jaws. When an option in the radio button is not
> selected. Using the tab key, takes you to each options within the radio
> button component. Once the option is selected, then the tab order works as
> expected. Using Chrome, this behaviour does not occur. Instead the tab key
> takes you to the next control.
>
>
> Note: If the option in the radio button is pre-selected, then the issue
> described above does not occur.
>
> Is this a Firefox defect?
>
>
>
>
> [cid:image001.png@01D64A6B.6F067AA0]
>
> Sean Murphy | Accessibility expert/lead
> Digital Accessibility manager
> Telstra Digital Channels | Digital Systems
> Mobile: 0405 129 739 | Desk: (02) 9866-7917
>
> www.telstra.com
>
> This email may contain confidential information.
> If I've sent it to you by accident, please delete it immediately
>
>
>
>


--
Work hard. Have fun. Make history.

From: Weston Thayer
Date: Wed, Jun 24 2020 12:45PM
Subject: Re: Radio Button strange behaviour in Firefox.
← Previous message | Next message →

There was a thread
<https://web-a11y.slack.com/archives/C050D9NHZ/p1580492505053200> about
this on the web-a11y Slack earlier this year. Firefox's behavior does
appear to be in conflict with the spec <https://www.w3.org/wiki/RadioButton>
:

> 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.


Asa Dotzler mentioned that he'd shared this behavior with the dev team, but
I'm not aware of a Bugzilla for it. FWIW, it is a very old Firefox
behavior, I reproduced it back to at least Firefox v40.

On Wed, Jun 24, 2020 at 8:31 AM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> Shawn
>
> That is an expected behavior for a set of radio buttons where no radio
> button has been selected, (they're all focusable until one has been
> selected). You don't see this often because one of the radio buttons
> is typically selected by default (and that is the recommendation for
> the pattern).
> What I find odd on this page is that Chrome with Jaws announces "1 of
> 6" for the first radiobutton, there are 2 sets of 3. I thought they
> all had the same "name" attribute (which would cause a screen reader
> to perceive them as one set) but they don't.
> Granted they should be in two separate <fieldset> or anotehr grouping
> element, but I'm still surprised that Jaws perceives them as one set.
>
>
>
> On 6/24/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
> > All,
> >
> > If you visit this site for a standard radio button:
> >
> >
> https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_radio
> >
> > Using Firefox with NVDA or Jaws. When an option in the radio button is
> not
> > selected. Using the tab key, takes you to each options within the radio
> > button component. Once the option is selected, then the tab order works
> as
> > expected. Using Chrome, this behaviour does not occur. Instead the tab
> key
> > takes you to the next control.
> >
> >
> > Note: If the option in the radio button is pre-selected, then the issue
> > described above does not occur.
> >
> > Is this a Firefox defect?
> >
> >
> >
> >
> > [cid:image001.png@01D64A6B.6F067AA0]
> >
> > Sean Murphy | Accessibility expert/lead
> > Digital Accessibility manager
> > Telstra Digital Channels | Digital Systems
> > Mobile: 0405 129 739 | Desk: (02) 9866-7917
> >
> > www.telstra.com
> >
> > This email may contain confidential information.
> > If I've sent it to you by accident, please delete it immediately
> >
> >
> >
> >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Patrick H. Lauke
Date: Wed, Jun 24 2020 3:28PM
Subject: Re: Radio Button strange behaviour in Firefox.
← Previous message | Next message →

On 24/06/2020 19:45, Weston Thayer wrote:
> There was a thread
> <https://web-a11y.slack.com/archives/C050D9NHZ/p1580492505053200> about
> this on the web-a11y Slack earlier this year. Firefox's behavior does
> appear to be in conflict with the spec <https://www.w3.org/wiki/RadioButton>

That's not really a "spec" though, just a note in a wiki? Unless I'm
mistaken, it's not actually normatively defined anywhere how user agents
should behave (at least I can't see anything in
https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio)
at first glance).

So this is more down to Firefox making a deliberate choice of how to
interact with these controls, which is arguably neither right nor wrong
per any spec. Against convention? Sure. But wrong? Undefined...

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke
https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Weston Thayer
Date: Wed, Jun 24 2020 4:48PM
Subject: Re: Radio Button strange behaviour in Firefox.
← Previous message | Next message →

Doh! Thanks for pointing that out Patrick.

On Wed, Jun 24, 2020 at 2:28 PM Patrick H. Lauke < = EMAIL ADDRESS REMOVED = >
wrote:

> On 24/06/2020 19:45, Weston Thayer wrote:
> > There was a thread
> > <https://web-a11y.slack.com/archives/C050D9NHZ/p1580492505053200> about
> > this on the web-a11y Slack earlier this year. Firefox's behavior does
> > appear to be in conflict with the spec <
> https://www.w3.org/wiki/RadioButton>
>
> That's not really a "spec" though, just a note in a wiki? Unless I'm
> mistaken, it's not actually normatively defined anywhere how user agents
> should behave (at least I can't see anything in
>
> https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio)
> at first glance).
>
> So this is more down to Firefox making a deliberate choice of how to
> interact with these controls, which is arguably neither right nor wrong
> per any spec. Against convention? Sure. But wrong? Undefined...
>
> P
> --
> Patrick H. Lauke
>
> https://www.splintered.co.uk/ | https://github.com/patrickhlauke
> https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >

From: Murphy, Sean
Date: Wed, Jun 24 2020 4:59PM
Subject: Re: Radio Button strange behaviour in Firefox.
← Previous message | Next message →

Patrick,

Thanks for this detailed explanation. Now I have some bed time reading. 😊



Regards
Sean Murphy



Sean Murphy | Senior Digital System specialist (Accessibility)
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917
Digital Systems Launch Page
Accessibility Single source of Truth

-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Patrick H. Lauke
Sent: Thursday, 25 June 2020 7:28 AM
To: = EMAIL ADDRESS REMOVED =
Subject: Re: [WebAIM] Radio Button strange behaviour in Firefox.

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

On 24/06/2020 19:45, Weston Thayer wrote:
> There was a thread
> <https://web-a11y.slack.com/archives/C050D9NHZ/p1580492505053200>
> about this on the web-a11y Slack earlier this year. Firefox's behavior
> does appear to be in conflict with the spec
> <https://www.w3.org/wiki/RadioButton>

That's not really a "spec" though, just a note in a wiki? Unless I'm mistaken, it's not actually normatively defined anywhere how user agents should behave (at least I can't see anything in
https://html.spec.whatwg.org/multipage/input.html#radio-button-state-(type=radio)
at first glance).

So this is more down to Firefox making a deliberate choice of how to interact with these controls, which is arguably neither right nor wrong per any spec. Against convention? Sure. But wrong? Undefined...

P
--
Patrick H. Lauke

https://www.splintered.co.uk/ | https://github.com/patrickhlauke https://flickr.com/photos/redux/ | https://www.deviantart.com/redux
twitter: @patrick_h_lauke | skype: patrick_h_lauke

From: Murphy, Sean
Date: Wed, Jun 24 2020 5:02PM
Subject: Re: Radio Button strange behaviour in Firefox.
← Previous message | No next message

Birkir


Thanks for this. Consistency would be nice.




Sean Murphy | Accessibility expert/lead
Digital Accessibility manager
Telstra Digital Channels | Digital Systems
Mobile: 0405 129 739 | Desk: (02) 9866-7917

www.telstra.com

This email may contain confidential information.
If I've sent it to you by accident, please delete it immediately



-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of Birkir R. Gunnarsson
Sent: Thursday, 25 June 2020 1:31 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] Radio Button strange behaviour in Firefox.

[External Email] This email was sent from outside the organisation – be cautious, particularly with links and attachments.

Shawn

That is an expected behavior for a set of radio buttons where no radio button has been selected, (they're all focusable until one has been selected). You don't see this often because one of the radio buttons is typically selected by default (and that is the recommendation for the pattern).
What I find odd on this page is that Chrome with Jaws announces "1 of 6" for the first radiobutton, there are 2 sets of 3. I thought they all had the same "name" attribute (which would cause a screen reader to perceive them as one set) but they don't.
Granted they should be in two separate <fieldset> or anotehr grouping element, but I'm still surprised that Jaws perceives them as one set.



On 6/24/20, Murphy, Sean < = EMAIL ADDRESS REMOVED = > wrote:
> All,
>
> If you visit this site for a standard radio button:
>
> https://www.w3schools.com/tags/tryit.asp?filename=tryhtml5_input_type_
> radio
>
> Using Firefox with NVDA or Jaws. When an option in the radio button is
> not selected. Using the tab key, takes you to each options within the
> radio button component. Once the option is selected, then the tab
> order works as expected. Using Chrome, this behaviour does not occur.
> Instead the tab key takes you to the next control.
>
>
> Note: If the option in the radio button is pre-selected, then the
> issue described above does not occur.
>
> Is this a Firefox defect?
>
>
>
>
> [cid:image001.png@01D64A6B.6F067AA0]
>
> Sean Murphy | Accessibility expert/lead Digital Accessibility manager
> Telstra Digital Channels | Digital Systems
> Mobile: 0405 129 739 | Desk: (02) 9866-7917
>
> www.telstra.com
>
> This email may contain confidential information.
> If I've sent it to you by accident, please delete it immediately
>
>
>
>


--
Work hard. Have fun. Make history.