WebAIM - Web Accessibility In Mind

E-mail List Archives

Re: Fw: Regarding checkboxes and radio buttons that are not input elements

for

From: Jesse Hausler
Date: May 8, 2012 6:12PM

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 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 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 REMOVED> >
> To: "WebAIM Discussion List" < <EMAIL 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.