E-mail List Archives

Search E-mail List Archives for

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

From: Alexander Schmitz
Date: Wed, May 20 2015 11:42AM
Subject: Expected behavior for description text of a toggle button
No previous message | Next message →

Hi
We ( jQuery UI and Mobile ) are working on a new checkboxradio widget. This
takes a checkbox or radio input and styles the label to create a toggle
button, this way all the proper associations are handled by the browser.

One issue we have run into, is what the expected behavior is when you have
a form with a layout similar to http://jsbin.com/muceye/1/edit?html,output
. Should the descriptive text on the left activate the button on the right
( be an actual label like the top example, and other inputs in the form )
or just be associated maybe with a fieldset and legend like the second
example.

Any advice would be appreciated!

Alexander Schmitz
jQuery Foundation

From: Cliff Tyllick
Date: Wed, May 20 2015 1:11PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

Alexander, if I understand your question correctly, the answer is "Neither."

When I touch the text, I probably want to swipe up or down, or perhaps zoom in with a two-finger motion. I don't expect a form control to toggle, because that isn't what text—even when it's a form label—does.

I don't expect a checkbox to get checked or a radio button to get selected unless I actually touch or click inside the control itself—because that's how they work.

I'm curious: Why isn't the default behavior of the native control adequate? For usability as well as accessibility, it's best to use native controls whenever possible.

Cliff Tyllick
Texas Department of Assistive and Rehabilitative Services

Sent from my iPhone
Although its spellcheck often saves me, all goofs in sent messages are its fault.

> On May 20, 2015, at 12:42 PM, Alexander Schmitz < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hi
> We ( jQuery UI and Mobile ) are working on a new checkboxradio widget. This
> takes a checkbox or radio input and styles the label to create a toggle
> button, this way all the proper associations are handled by the browser.
>
> One issue we have run into, is what the expected behavior is when you have
> a form with a layout similar to http://jsbin.com/muceye/1/edit?html,output
> . Should the descriptive text on the left activate the button on the right
> ( be an actual label like the top example, and other inputs in the form )
> or just be associated maybe with a fieldset and legend like the second
> example.
>
> Any advice would be appreciated!
>
> Alexander Schmitz
> jQuery Foundation
> > > >

From: Scott González
Date: Wed, May 20 2015 1:40PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

On Wed, May 20, 2015 at 3:11 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:

> Alexander, if I understand your question correctly, the answer is
> "Neither."
>
> When I touch the text, I probably want to swipe up or down, or perhaps
> zoom in with a two-finger motion. I don't expect a form control to toggle,
> because that isn't what text—even when it's a form label—does.
>

That's not true. Labels for checkboxes and radios *do* activate their
associated controls. This makes forms much more usable because the
extremely small form controls receive much larger hit areas as a result.

From: Alexander Schmitz
Date: Wed, May 20 2015 2:59PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

> I'm curious: Why isn't the default behavior of the native control
adequate? For usability as well as accessibility, it's best to use native
controls whenever possible.

All of the controls in the form in my example
are exhibiting native behavior they just use different markup. The question
is what is the correct markup / behavior for this particular form layout.
When the control appears as a button type element ( toggle button ).

I updated to add a native un-styled checkbox to show this.
http://jsbin.com/muceye/3/edit?html,css,output hope this clears up any
confusion.

On Wed, May 20, 2015 at 3:40 PM, Scott González < = EMAIL ADDRESS REMOVED = >
wrote:

> On Wed, May 20, 2015 at 3:11 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
>
> > Alexander, if I understand your question correctly, the answer is
> > "Neither."
> >
> > When I touch the text, I probably want to swipe up or down, or perhaps
> > zoom in with a two-finger motion. I don't expect a form control to
> toggle,
> > because that isn't what text—even when it's a form label—does.
> >
>
> That's not true. Labels for checkboxes and radios *do* activate their
> associated controls. This makes forms much more usable because the
> extremely small form controls receive much larger hit areas as a result.
> > > > >

From: Birkir R. Gunnarsson
Date: Wed, May 20 2015 9:09PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

I am confused by this actually.
What do you mean by toggle button? In html/ARIA lingo that is a button
with an aria-pressed attribute (and a button does not have a label,
its accessible name comes from its contents, its value .. if it is an
input of type button, reset, submit etc. or from ARIA labeling).
Labels only work for compatible html form fields, checkboxes,
radiobuttons, textarea elements etc.
As far as I understand this, and being a screen reader user I may be
wrong here and can always be corrected, activating the label
associated with a checkbox or radiobutton moves focus to that control,
but does not necessarily activate it.
If you could clarify a bit more what you mean by toggle button, then
we can start to explore.
Users would generally assume that simulated controls work similarly to
the closest equivalent html controls.
So if we are still talking radiobutton or checkbox, you can check what
the behavior is for a native html version.
If we are talking about toggle buttons, I believe the only way to
associate the label with a button is through aARIA labeling which
traditionally does ot cause activation of the control if user clicks
on the associated label, that only works in case of native html
labeling by use of the <label> tag.
I am not saying this is desireable .. larger click targets are a huge
accessibility benefit to users with difficulty interacting with a
touch-screen, I am only saying that is not the generally expected
behavior, as far as I understand your question.
Thanks
-Birkir



On 5/20/15, Alexander Schmitz < = EMAIL ADDRESS REMOVED = > wrote:
>> I'm curious: Why isn't the default behavior of the native control
> adequate? For usability as well as accessibility, it's best to use native
> controls whenever possible.
>
> All of the controls in the form in my example
> are exhibiting native behavior they just use different markup. The question
> is what is the correct markup / behavior for this particular form layout.
> When the control appears as a button type element ( toggle button ).
>
> I updated to add a native un-styled checkbox to show this.
> http://jsbin.com/muceye/3/edit?html,css,output hope this clears up any
> confusion.
>
> On Wed, May 20, 2015 at 3:40 PM, Scott González < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> On Wed, May 20, 2015 at 3:11 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
>>
>> > Alexander, if I understand your question correctly, the answer is
>> > "Neither."
>> >
>> > When I touch the text, I probably want to swipe up or down, or perhaps
>> > zoom in with a two-finger motion. I don't expect a form control to
>> toggle,
>> > because that isn't what text--even when it's a form label--does.
>> >
>>
>> That's not true. Labels for checkboxes and radios *do* activate their
>> associated controls. This makes forms much more usable because the
>> extremely small form controls receive much larger hit areas as a result.
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: Paul J. Adam
Date: Wed, May 20 2015 9:24PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

To me the "Label Text" to the right of the checkbox looks like a button with button text and that's what I click to activate the toggle. I would not click on the label to the left of that text due to the design making it look like a button or making it look like the label is to the right.

I would say the accessible names/click target areas should only be on the strings "Label Text" and "Toggle2". I would not expect the text to the left to be the connected label.

I think this is pretty confusing to convey/explain if you can't see the design visually. I wish I could paste screenshots into WebAIM also ;)

Paul J. Adam
Accessibility Evangelist
www.deque.com

Join us at our Mobile Accessibility "Bootcamp!"
August 6-7 in Austin Texas
https://dequeuniversity.com/events/2015/mobile
Topics include responsive web design, native apps, & more

> On May 20, 2015, at 3:59 PM, Alexander Schmitz < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I'm curious: Why isn't the default behavior of the native control
> adequate? For usability as well as accessibility, it's best to use native
> controls whenever possible.
>
> All of the controls in the form in my example
> are exhibiting native behavior they just use different markup. The question
> is what is the correct markup / behavior for this particular form layout.
> When the control appears as a button type element ( toggle button ).
>
> I updated to add a native un-styled checkbox to show this.
> http://jsbin.com/muceye/3/edit?html,css,output hope this clears up any
> confusion.
>
> On Wed, May 20, 2015 at 3:40 PM, Scott González < = EMAIL ADDRESS REMOVED = >
> wrote:
>
>> On Wed, May 20, 2015 at 3:11 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = > wrote:
>>
>>> Alexander, if I understand your question correctly, the answer is
>>> "Neither."
>>>
>>> When I touch the text, I probably want to swipe up or down, or perhaps
>>> zoom in with a two-finger motion. I don't expect a form control to
>> toggle,
>>> because that isn't what text—even when it's a form label—does.
>>>
>>
>> That's not true. Labels for checkboxes and radios *do* activate their
>> associated controls. This makes forms much more usable because the
>> extremely small form controls receive much larger hit areas as a result.
>> >> >> >> >>
> > > >

From: Alexander Schmitz
Date: Wed, May 20 2015 9:24PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

Hi Birkir,

Thank you for your response. Sorry i was not clear in my original
description. What I am talking about is a checkbox or radio input the
input's label is styled to look like a button and the visual state toggles
when it is clicked by switching from a light grey default background to a
blue "Active" background. There are placed in a form which has a 2 column
layout in column the left column is a description of the control ( a label
) and in the right column is the control itself. In the first case to make
the descriptive text ( label ) activate the control properly i use 2 labels
one is the description and one forms the visual button. In the second i use
a fieldset and the legend forms the descriptive text and the label still
forms the button. In the second case since the descriptive text is a legend
it is associated with the input but does not activate it.

Im not sure if there really is a direct native correlation to this so i'm
not sure what the expected behavior would be here. However layouts and
checkboxes of this style are becoming very popular for mobile devices
precisely because of the better hit area and visual feedback they provide
to the user.

The root of why we are trying to figure this out comes down to the choice
of which label to use to create the visual button from, if more then one
label is associated with the input. Initially we planned on just always
using the first one found. However that makes the 2 column layout i'm
describing a little tricky to create, so it may be better to actually chose
the last label not the first. However we are not even sure if in this type
of layout if it would be expected if the descriptive text would activate
the control at all.

I hope this clarifies better.

On Wed, May 20, 2015 at 11:09 PM, Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> I am confused by this actually.
> What do you mean by toggle button? In html/ARIA lingo that is a button
> with an aria-pressed attribute (and a button does not have a label,
> its accessible name comes from its contents, its value .. if it is an
> input of type button, reset, submit etc. or from ARIA labeling).
> Labels only work for compatible html form fields, checkboxes,
> radiobuttons, textarea elements etc.
> As far as I understand this, and being a screen reader user I may be
> wrong here and can always be corrected, activating the label
> associated with a checkbox or radiobutton moves focus to that control,
> but does not necessarily activate it.
> If you could clarify a bit more what you mean by toggle button, then
> we can start to explore.
> Users would generally assume that simulated controls work similarly to
> the closest equivalent html controls.
> So if we are still talking radiobutton or checkbox, you can check what
> the behavior is for a native html version.
> If we are talking about toggle buttons, I believe the only way to
> associate the label with a button is through aARIA labeling which
> traditionally does ot cause activation of the control if user clicks
> on the associated label, that only works in case of native html
> labeling by use of the <label> tag.
> I am not saying this is desireable .. larger click targets are a huge
> accessibility benefit to users with difficulty interacting with a
> touch-screen, I am only saying that is not the generally expected
> behavior, as far as I understand your question.
> Thanks
> -Birkir
>
>
>
> On 5/20/15, Alexander Schmitz < = EMAIL ADDRESS REMOVED = > wrote:
> >> I'm curious: Why isn't the default behavior of the native control
> > adequate? For usability as well as accessibility, it's best to use native
> > controls whenever possible.
> >
> > All of the controls in the form in my example
> > are exhibiting native behavior they just use different markup. The
> question
> > is what is the correct markup / behavior for this particular form layout.
> > When the control appears as a button type element ( toggle button ).
> >
> > I updated to add a native un-styled checkbox to show this.
> > http://jsbin.com/muceye/3/edit?html,css,output hope this clears up any
> > confusion.
> >
> > On Wed, May 20, 2015 at 3:40 PM, Scott González <
> = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> >> On Wed, May 20, 2015 at 3:11 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = >
> wrote:
> >>
> >> > Alexander, if I understand your question correctly, the answer is
> >> > "Neither."
> >> >
> >> > When I touch the text, I probably want to swipe up or down, or perhaps
> >> > zoom in with a two-finger motion. I don't expect a form control to
> >> toggle,
> >> > because that isn't what text--even when it's a form label--does.
> >> >
> >>
> >> That's not true. Labels for checkboxes and radios *do* activate their
> >> associated controls. This makes forms much more usable because the
> >> extremely small form controls receive much larger hit areas as a result.
> >> > >> > >> > >> > >>
> > > > > > > > > >
>
>
> --
> Work hard. Have fun. Make history.
> > > > >

From: Alexander Schmitz
Date: Wed, May 20 2015 9:29PM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | Next message →

Paul thank you. That was our thought exactly is that when it looks like a
button i don't think i would ever click the descriptive text and expect it
to activate the button, that seems a little odd. HOWEVER... Since all the
other controls are using their normal labels on the left, and the labels
properly focus or jump to their associated input ( which i would say is the
desired and expected out come in all the other cases for sure ), i was not
sure if it may be confusing to some in a layout like this that on some
items ( the checkboxes and radios ), the descriptive text DID NOT behave as
a label.

On Wed, May 20, 2015 at 11:24 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:

> To me the "Label Text" to the right of the checkbox looks like a button
> with button text and that's what I click to activate the toggle. I would
> not click on the label to the left of that text due to the design making it
> look like a button or making it look like the label is to the right.
>
> I would say the accessible names/click target areas should only be on the
> strings "Label Text" and "Toggle2". I would not expect the text to the left
> to be the connected label.
>
> I think this is pretty confusing to convey/explain if you can't see the
> design visually. I wish I could paste screenshots into WebAIM also ;)
>
> Paul J. Adam
> Accessibility Evangelist
> www.deque.com
>
> Join us at our Mobile Accessibility "Bootcamp!"
> August 6-7 in Austin Texas
> https://dequeuniversity.com/events/2015/mobile
> Topics include responsive web design, native apps, & more
>
> > On May 20, 2015, at 3:59 PM, Alexander Schmitz < = EMAIL ADDRESS REMOVED = >
> wrote:
> >
> >> I'm curious: Why isn't the default behavior of the native control
> > adequate? For usability as well as accessibility, it's best to use native
> > controls whenever possible.
> >
> > All of the controls in the form in my example
> > are exhibiting native behavior they just use different markup. The
> question
> > is what is the correct markup / behavior for this particular form layout.
> > When the control appears as a button type element ( toggle button ).
> >
> > I updated to add a native un-styled checkbox to show this.
> > http://jsbin.com/muceye/3/edit?html,css,output hope this clears up any
> > confusion.
> >
> > On Wed, May 20, 2015 at 3:40 PM, Scott González <
> = EMAIL ADDRESS REMOVED = >
> > wrote:
> >
> >> On Wed, May 20, 2015 at 3:11 PM, Cliff Tyllick < = EMAIL ADDRESS REMOVED = >
> wrote:
> >>
> >>> Alexander, if I understand your question correctly, the answer is
> >>> "Neither."
> >>>
> >>> When I touch the text, I probably want to swipe up or down, or perhaps
> >>> zoom in with a two-finger motion. I don't expect a form control to
> >> toggle,
> >>> because that isn't what text—even when it's a form label—does.
> >>>
> >>
> >> That's not true. Labels for checkboxes and radios *do* activate their
> >> associated controls. This makes forms much more usable because the
> >> extremely small form controls receive much larger hit areas as a result.
> >> > >> > >> > >> > >>
> > > > > > > > >
> > > > >

From: _mallory
Date: Thu, May 21 2015 3:36AM
Subject: Re: Expected behavior for description text of a toggle button
← Previous message | No next message

Hm, I too didn't think it "looked" like clickable text, but then labels
never do, it's only their proximity to a control that lets me know that
I can click the label instead to [trigger a checkbox/radio or focus a
textarea/input/select). I'll bet if you user-tested on some (grand)
parents (on something that looks more like a real form) you'd get
those who typically click labels trying to click them and non-label-
clickers only hitting the buttony-looking bits.

Maybe that's another input for the team to use to determine if it
would be bad usability to have things which look like they're
representing labels but aren't not be at least clickable-to-move-focus.

Maybe only letting focus move to the controls in the example would be
a doable compromise? While the real labels do toggling as they normally
do? Not a standard behaviour either, but depending on the user testing
it might make the most sense to the most users.

Back in the day, when we needed non-label texts that sat near real-
label texts to act the same as labels, we'd use CSS to expand the label
padding around that text.

Covering the fake-label text with label padding let mouse/touch users
get the behaviour they expected... tho obviously this wouldn't work with
composable widgety things like this project where you can't control
where people put stuff.

_mallory


On Wed, May 20, 2015 at 11:29:25PM -0400, Alexander Schmitz wrote:
> Paul thank you. That was our thought exactly is that when it looks like a
> button i don't think i would ever click the descriptive text and expect it
> to activate the button, that seems a little odd. HOWEVER... Since all the
> other controls are using their normal labels on the left, and the labels
> properly focus or jump to their associated input ( which i would say is the
> desired and expected out come in all the other cases for sure ), i was not
> sure if it may be confusing to some in a layout like this that on some
> items ( the checkboxes and radios ), the descriptive text DID NOT behave as
> a label.
>
> On Wed, May 20, 2015 at 11:24 PM, Paul J. Adam < = EMAIL ADDRESS REMOVED = > wrote:
>
> > To me the "Label Text" to the right of the checkbox looks like a button
> > with button text and that's what I click to activate the toggle. I would
> > not click on the label to the left of that text due to the design making it
> > look like a button or making it look like the label is to the right.
> >
> > I would say the accessible names/click target areas should only be on the
> > strings "Label Text" and "Toggle2". I would not expect the text to the left
> > to be the connected label.
> >
> > I think this is pretty confusing to convey/explain if you can't see the
> > design visually. I wish I could paste screenshots into WebAIM also ;)
> >
> > Paul J. Adam
> > Accessibility Evangelist
> > www.deque.com
> >
> > Join us at our Mobile Accessibility "Bootcamp!"
> > August 6-7 in Austin Texas
> > https://dequeuniversity.com/events/2015/mobile
> > Topics include responsive web design, native apps, & more