E-mail List Archives
Re: WCAG 2.0 1.4.4 relating to form elements
From: Birkir R. Gunnarsson
Date: Dec 22, 2017 7:45AM
- Next message: Angela French: "Re: WCAG 2.0 1.4.4 relating to form elements"
- Previous message: Chagnon | PubCom: "Re: CommonLook failures and HHS requirements"
- Next message in Thread: Angela French: "Re: WCAG 2.0 1.4.4 relating to form elements"
- Previous message in Thread: Patrick H. Lauke: "WCAG 2.0 1.4.4 relating to form elements"
- View all messages in this Thread
I'd think of it as a usability issue. Why does the value in the
dropdown have to be so long? Can it be reworded or shortened. As
Patrick suggested, could it at least be reworded so that the user can
identify it based on the visible portion of the text?
e.g. if it were a city and state dropdown, replace "California, Los
Angeles" with "Los Angeles, California".
I don't think 1.4.4 applies here, (unless the content only truncates
when you zoom the page to 200%), but this sounds like a fix that would
benefit all users.
On 12/21/17, Patrick H. Lauke < <EMAIL REMOVED> > wrote:
> On 21/12/2017 20:10, Angela French wrote:
>> Hello,
>> I'm curious: is there a way to dynamically change the size of form
>> elements based on the zoom level a person is using in their browser? Is
>> there even a way to programmatically assess what zoom a person is using.
>>
>> This questions is based on an app we just had evaluated for accessibility
>> that received a ding (WCAG 2.0 1.4.4) because a particularly long value
>> in a drop down choice was truncated in the form field (not all viewable)
>> after the select was made. The browser DOES make the drop down list wide
>> enough to view the selection list when the drop down list is opened.
>> This feels more like a usability issue to me and not an accessibility
>> issue per se - something I imagine 200+ zoom level users probably
>> frequently encounter.
>
> Is there a chance that two or more values in the select are long and
> have the same text at the start / only get distinguished later on in the
> text, and that the select (when closed again) is ambiguous for users,
> who are then not able to determine what value was in fact selected? Or
> even when it's just one value, is it clear enough for somebody who comes
> across the closed select with that particular value selected what it
> actually is, without having to open it to see the full width select
> dropdown? If so, this does feel like it's at least in part an
> accessibility issue...
>
> Any way the select itself can be made wider? Alternatively, some
> JavaScript that writes out the selected value in full somewhere nearby?
> Or, depending on the number of options, turns it into a set of radio
> buttons instead?
>
> For what it's worth, you can't detect zoom level, but you can run
> JS-based media queries to work out what the viewport width is (which
> changes based not only on browser window size, but also based on zoom
> level), as well as checking for default font size (a bit more
> laboriously, admittedly).
>
> P
> --
> Patrick H. Lauke
>
> www.splintered.co.uk | https://github.com/patrickhlauke
> http://flickr.com/photos/redux/ | http://redux.deviantart.com
> twitter: @patrick_h_lauke | skype: patrick_h_lauke
> > > > >
--
Work hard. Have fun. Make history.
- Next message: Angela French: "Re: WCAG 2.0 1.4.4 relating to form elements"
- Previous message: Chagnon | PubCom: "Re: CommonLook failures and HHS requirements"
- Next message in Thread: Angela French: "Re: WCAG 2.0 1.4.4 relating to form elements"
- Previous message in Thread: Patrick H. Lauke: "WCAG 2.0 1.4.4 relating to form elements"
- View all messages in this Thread