E-mail List Archives

Search E-mail List Archives for

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

From: Bryan Garaventa
Date: Tue, May 08 2012 2:38PM
Subject: Fw: Regarding checkboxes and radio buttons that are not input elements
No previous message | Next message →

I'm forwarding this here in case anyone would like to share an opinion. I'd like to know if I'm missing something.

----- Original Message -----
From: Bryan Garaventa
To: = EMAIL ADDRESS REMOVED =
Sent: Tuesday, May 08, 2012 9:21 AM
Subject: Re: [free-aria] Regarding checkboxes and radio buttons that are not input elements


Thanks, that's along the same lines as I was thinking as well.

Does anyone know if there is CSS styling that can only be done on a Div, but cannot be done on an Input tag? From what I've read, it should be possible to use CSS styling or background images to make these elements look like whatever you wish.

So, if I'm right about this, that you can use CSS to make an Input tag look fancy using CSS, and if it's not reliable to use Divs for this purpose because of keyboard accessibility issues and lack of backwards compatibility for screen reader users, then what is the purpose of the ARIA role=radio and role=checkbox attribute sets?

Doesn't this imply that doing this is perfectly acceptable?

----- Original Message -----
From: Vincent Young
To: = EMAIL ADDRESS REMOVED =
Sent: Monday, May 07, 2012 8:44 PM
Subject: Re: [free-aria] Regarding checkboxes and radio buttons that are not input elements


Bryan,


I believe, for the most part, these are purely for aesthetic reasons. The aesthetics typically include the box and check mark of course. I've worked at several places where the design and brand ruled. Custom inputs are very compelling for these folks. Those making the decisions are more focused on the brand and accessibility hardly ever makes any cut. However, I'm sure in many cases accessibility isn't even a consideration due to the fact that the options were never presented. Of course when presented with the option, it seems from personal experience, accessibility is often cast aside. I was once told by the VP of Internet for a very large brand centric company that he'll worry about accessibility when he needs to. He was eluding to legal recourse. To a certain degree, after seeing what the guy has to deal with and worry about I understand where he is coming from. It is not his world and he has a host of other issues that take precedence. Of course if it were up
to me, I'd try to find a happy medium, but I have never found myself in such positions of power making decisions for an aesthetic centered brand, so I really don't know what it's like. Hope this made some sense.


Best,
Vincent


On Mon, May 7, 2012 at 3:40 PM, Bryan Garaventa < = EMAIL ADDRESS REMOVED = > wrote:

I've been finding this a lot recently, and I'm curious.

Why would it be more desirable to use Div tags to render radio buttons and checkboxes, instead of simply using standard Input elements for the same purpose and just styling them to look a certain way using CSS?

The drawbacks to using Divs are obvious, such as keyboard inaccessibility, textual equivalent feedback, backwards compatibility, and the time necessary to debug such implementations to make them accessible.

I know that ARIA can be used to convey the intended feedback for screen readers that support ARIA, but the same keyboard issues apply regardless.

I'm not being facetious; I would genuinely like to know why this is preferable, since there appear to be such implementations in most of the major frameworks.

--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To post to this group, send email to = EMAIL ADDRESS REMOVED = .
To unsubscribe from this group, send email to free-aria+ = EMAIL ADDRESS REMOVED = .
For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.




--
WebHipster Interactive, ltd.
Vincent Young - Principal
742 N Sweetzer
West Hollywood, CA 90069
p: 614.607.3400
f: 339-674-3400
e: = EMAIL ADDRESS REMOVED =
w: http://www.webhipster.com




--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To post to this group, send email to = EMAIL ADDRESS REMOVED = .
To unsubscribe from this group, send email to free-aria+ = EMAIL ADDRESS REMOVED = .
For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.


--
You received this message because you are subscribed to the Google Groups "Free ARIA Community" group.
To post to this group, send email to = EMAIL ADDRESS REMOVED = .
To unsubscribe from this group, send email to free-aria+ = EMAIL ADDRESS REMOVED = .
For more options, visit this group at http://groups.google.com/group/free-aria?hl=en.

From: Jared Smith
Date: Tue, May 08 2012 2:50PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

On Tue, May 8, 2012 at 2:38 PM, Bryan Garaventa wrote:
> I'd like to know if I'm missing something.

There are some limitations and consistency issues with styling form
controls. The default controls display quite differently across
browsers, so styling them consistently can be a bit of a pain. A lot
of CSS3 styling has not yet been implemented (or implemented
correctly) to form controls. This is exacerbated if you use HTML5
input types. With that said, you have a lot of flexibility in styling
form controls.

When styling alone is not sufficient, rather than entirely replacing
the standard form controls with ARIA-enhanced divs, etc., it is often
best to maintain the form controls on the page, yet hide them
visually. Styled divs are then used on the page to present the styled
visual representation of those form controls. In other words, keyboard
and screen reader users interact with the actual, off-screen form
controls, but visually it appears that they are interacting with the
fancy looking controls on the screen. This can allow you to use
standard semantics and form interaction, while making it appear
however you would like. Of course the on-screen controls need to be
responsive to mouse interactions and update the underlying form
controls appropriately, but this is much easier than making them both
mouse and keyboard accessible with ARIA, etc.

Jared Smith
WebAIM

From: Birkir R. Gunnarsson
Date: Tue, May 08 2012 2:54PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

Hi Jared

Do you have a handy example of the types of controls you describe?
I have been asked about this possibilityby a few developers, and it
seems a good example would be very useful.
Thanks
-B

On 5/8/12, Jared Smith < = EMAIL ADDRESS REMOVED = > wrote:
> On Tue, May 8, 2012 at 2:38 PM, Bryan Garaventa wrote:
>> I'd like to know if I'm missing something.
>
> There are some limitations and consistency issues with styling form
> controls. The default controls display quite differently across
> browsers, so styling them consistently can be a bit of a pain. A lot
> of CSS3 styling has not yet been implemented (or implemented
> correctly) to form controls. This is exacerbated if you use HTML5
> input types. With that said, you have a lot of flexibility in styling
> form controls.
>
> When styling alone is not sufficient, rather than entirely replacing
> the standard form controls with ARIA-enhanced divs, etc., it is often
> best to maintain the form controls on the page, yet hide them
> visually. Styled divs are then used on the page to present the styled
> visual representation of those form controls. In other words, keyboard
> and screen reader users interact with the actual, off-screen form
> controls, but visually it appears that they are interacting with the
> fancy looking controls on the screen. This can allow you to use
> standard semantics and form interaction, while making it appear
> however you would like. Of course the on-screen controls need to be
> responsive to mouse interactions and update the underlying form
> controls appropriately, but this is much easier than making them both
> mouse and keyboard accessible with ARIA, etc.
>
> Jared Smith
> WebAIM
> > > >

From: Bryan Garaventa
Date: Tue, May 08 2012 3:05PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

Yes, thank you, that is helpful. I see how this method can also be used to
make selectable data table rows accessible as well.

----- Original Message -----
From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
Sent: Tuesday, May 08, 2012 1:50 PM
Subject: Re: [WebAIM] Fw: Regarding checkboxes and radio buttons that are
not input elements


> On Tue, May 8, 2012 at 2:38 PM, Bryan Garaventa wrote:
>> I'd like to know if I'm missing something.
>
> There are some limitations and consistency issues with styling form
> controls. The default controls display quite differently across
> browsers, so styling them consistently can be a bit of a pain. A lot
> of CSS3 styling has not yet been implemented (or implemented
> correctly) to form controls. This is exacerbated if you use HTML5
> input types. With that said, you have a lot of flexibility in styling
> form controls.
>
> When styling alone is not sufficient, rather than entirely replacing
> the standard form controls with ARIA-enhanced divs, etc., it is often
> best to maintain the form controls on the page, yet hide them
> visually. Styled divs are then used on the page to present the styled
> visual representation of those form controls. In other words, keyboard
> and screen reader users interact with the actual, off-screen form
> controls, but visually it appears that they are interacting with the
> fancy looking controls on the screen. This can allow you to use
> standard semantics and form interaction, while making it appear
> however you would like. Of course the on-screen controls need to be
> responsive to mouse interactions and update the underlying form
> controls appropriately, but this is much easier than making them both
> mouse and keyboard accessible with ARIA, etc.
>
> Jared Smith
> WebAIM
> > >

From: Ryan Hemphill
Date: Tue, May 08 2012 6:08PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

I'd also like to add the point on the CSS track that branding buffs are
often painfully specific about what they want. There are many many people
I have met along 15 years of design who got incredibly caught up in having
the page look 'just so' to the point where they were asking that a certain
block of designed UI be moved 2 pixels to the right and 5 pixels up because
it suited their fancy. Never mind that the adjustment had no effect on the
user behavior or impression of the site whatsoever. Yes, I'm salty about
it, but what makes it worse is when they won't consider the accessibility
issues because it offends their artistic sensibilities. There has to be a
way around these issues, but I've been having a hard time getting them to
buy into the idea. It would be great to hear if anyone has suggestions in
the direction on another thread.

Ryan

On Tuesday, May 8, 2012, Bryan Garaventa < = EMAIL ADDRESS REMOVED = >
wrote:
> Yes, thank you, that is helpful. I see how this method can also be used to
> make selectable data table rows accessible as well.
>
> ----- Original Message -----
> From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, May 08, 2012 1:50 PM
> Subject: Re: [WebAIM] Fw: Regarding checkboxes and radio buttons that are
> not input elements
>
>
>> On Tue, May 8, 2012 at 2:38 PM, Bryan Garaventa wrote:
>>> I'd like to know if I'm missing something.
>>
>> There are some limitations and consistency issues with styling form
>> controls. The default controls display quite differently across
>> browsers, so styling them consistently can be a bit of a pain. A lot
>> of CSS3 styling has not yet been implemented (or implemented
>> correctly) to form controls. This is exacerbated if you use HTML5
>> input types. With that said, you have a lot of flexibility in styling
>> form controls.
>>
>> When styling alone is not sufficient, rather than entirely replacing
>> the standard form controls with ARIA-enhanced divs, etc., it is often
>> best to maintain the form controls on the page, yet hide them
>> visually. Styled divs are then used on the page to present the styled
>> visual representation of those form controls. In other words, keyboard
>> and screen reader users interact with the actual, off-screen form
>> controls, but visually it appears that they are interacting with the
>> fancy looking controls on the screen. This can allow you to use
>> standard semantics and form interaction, while making it appear
>> however you would like. Of course the on-screen controls need to be
>> responsive to mouse interactions and update the underlying form
>> controls appropriately, but this is much easier than making them both
>> mouse and keyboard accessible with ARIA, etc.
>>
>> Jared Smith
>> WebAIM
>> >> >> >
> > > >

--



Shipping is a Feature...Perhaps the Most Important Feature.

From: Jesse Hausler
Date: Tue, May 08 2012 6:12PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

A few months back a colleague of mine played around with positioning checkboxes off screen (with pretty alternatives onscreen). The goal was to make a Menu with menuitemcheckbox, menuitemradio, etc. I showed him this thread and he picked it up again.. He's getting pretty close to having it working.

I'll post what I can once it's complete.

Jesse
--
Jesse Hausler
Sr. Accessibility Specialist | salesforce.com
Tel (415) 536-8902 | Mobile (703) 798-0903 | Fax (415) 944-1762



On 5/8/12 5:08 PM, "Ryan Hemphill" < = EMAIL ADDRESS REMOVED = > wrote:

I'd also like to add the point on the CSS track that branding buffs are
often painfully specific about what they want. There are many many people
I have met along 15 years of design who got incredibly caught up in having
the page look 'just so' to the point where they were asking that a certain
block of designed UI be moved 2 pixels to the right and 5 pixels up because
it suited their fancy. Never mind that the adjustment had no effect on the
user behavior or impression of the site whatsoever. Yes, I'm salty about
it, but what makes it worse is when they won't consider the accessibility
issues because it offends their artistic sensibilities. There has to be a
way around these issues, but I've been having a hard time getting them to
buy into the idea. It would be great to hear if anyone has suggestions in
the direction on another thread.

Ryan

On Tuesday, May 8, 2012, Bryan Garaventa < = EMAIL ADDRESS REMOVED = >
wrote:
> Yes, thank you, that is helpful. I see how this method can also be used to
> make selectable data table rows accessible as well.
>
> ----- Original Message -----
> From: "Jared Smith" < = EMAIL ADDRESS REMOVED = >
> To: "WebAIM Discussion List" < = EMAIL ADDRESS REMOVED = >
> Sent: Tuesday, May 08, 2012 1:50 PM
> Subject: Re: [WebAIM] Fw: Regarding checkboxes and radio buttons that are
> not input elements
>
>
>> On Tue, May 8, 2012 at 2:38 PM, Bryan Garaventa wrote:
>>> I'd like to know if I'm missing something.
>>
>> There are some limitations and consistency issues with styling form
>> controls. The default controls display quite differently across
>> browsers, so styling them consistently can be a bit of a pain. A lot
>> of CSS3 styling has not yet been implemented (or implemented
>> correctly) to form controls. This is exacerbated if you use HTML5
>> input types. With that said, you have a lot of flexibility in styling
>> form controls.
>>
>> When styling alone is not sufficient, rather than entirely replacing
>> the standard form controls with ARIA-enhanced divs, etc., it is often
>> best to maintain the form controls on the page, yet hide them
>> visually. Styled divs are then used on the page to present the styled
>> visual representation of those form controls. In other words, keyboard
>> and screen reader users interact with the actual, off-screen form
>> controls, but visually it appears that they are interacting with the
>> fancy looking controls on the screen. This can allow you to use
>> standard semantics and form interaction, while making it appear
>> however you would like. Of course the on-screen controls need to be
>> responsive to mouse interactions and update the underlying form
>> controls appropriately, but this is much easier than making them both
>> mouse and keyboard accessible with ARIA, etc.
>>
>> Jared Smith
>> WebAIM
>> >> >> >
> > > >

--



Shipping is a Feature...Perhaps the Most Important Feature.

From: deborah.kaplan
Date: Tue, May 08 2012 6:15PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

Ryan Hemphill wrote:

> they were asking that a certain block of designed UI be moved 2 pixels to the right and 5 pixels up because it suited their fancy.

In general, the only thing I've found that works is showing them what their so-detailed design looks like on screens other than the one they are using: usually a small laptop, a tablet such as an iPad, and a smart phone. Many designers talk the responsive design talk without paying attention to the fact that the idea is essentially all about losing control of that pixel-by-pixel look and feel, but if you actually *show* them the design on the smaller screen sometimes it sinks in.

Using accessibility as an argument has never worked for me, sadly.

-Deborah

From: Jesse Hausler
Date: Wed, May 09 2012 10:20AM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | Next message →

Here's the example that my colleague Thomas Sola put together.

Description:

The Javascript looks for checkboxes that we want to change into "fake" checkboxes in order to style them. It hides the real checkbox offscreen and adds a SPAN element that is styled to look like a checkbox.

Then the JS looks for the "change" event on that checkbox. When it changes it checks to see what the checkboxes state is and changes the classes on the fake checkbox accordingly.

One caveat: this has only been checked on FF and Chrome.

Jesse

--
Jesse Hausler
Sr. Accessibility Specialist | salesforce.com
Tel (415) 536-8902 | Mobile (703) 798-0903 | Fax (415) 944-1762

From: Jesse Hausler
Date: Wed, May 09 2012 4:46PM
Subject: Re: Fw: Regarding checkboxes and radio buttons that are not input elements
← Previous message | No next message

Here is the example that my colleague, Thomas Sola put together.

http://thomassola.com/labs/CheckboxSemantic/checkbox.html

I tried posting it earlier, but I think the file attachment got my post rejected.

His notes:

The Javascript looks for checkboxes that we want to change into "fake" checkboxes in order to style them. It hides the real checkbox offscreen and adds a SPAN element that is styled to look like a checkbox.

Then the JS looks for the "change" event on that checkbox. When it changes it checks to see what the checkboxes state is and changes the classes on the fake checkbox accordingly.

This was only tested in FF and Chrome.


Enjoy,
Jesse

--
Jesse Hausler
Sr. Accessibility Specialist | salesforce.com
Tel (415) 536-8902 | Mobile (703) 798-0903 | Fax (415) 944-1762



On 5/8/12 5:13 PM, " = EMAIL ADDRESS REMOVED = " < = EMAIL ADDRESS REMOVED = > wrote:

Ryan Hemphill wrote:

> they were asking that a certain block of designed UI be moved 2 pixels to the right and 5 pixels up because it suited their fancy.

In general, the only thing I've found that works is showing them what their so-detailed design looks like on screens other than the one they are using: usually a small laptop, a tablet such as an iPad, and a smart phone. Many designers talk the responsive design talk without paying attention to the fact that the idea is essentially all about losing control of that pixel-by-pixel look and feel, but if you actually *show* them the design on the smaller screen sometimes it sinks in.

Using accessibility as an argument has never worked for me, sadly.

-Deborah