E-mail List Archives

Search E-mail List Archives for

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

From: Patrick H. Lauke
Date: Thu, Dec 21 2017 6:24PM
Subject: WCAG 2.0 1.4.4 relating to form elements
No previous message | Next message →

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

From: Birkir R. Gunnarsson
Date: Fri, Dec 22 2017 7:45AM
Subject: Re: WCAG 2.0 1.4.4 relating to form elements
← Previous message | Next message →

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

From: Angela French
Date: Fri, Dec 22 2017 9:39AM
Subject: Re: WCAG 2.0 1.4.4 relating to form elements
← Previous message | No next message

It is the name of a school district. A rather long one I'm afraid for a 200% zoom.

Angela French

-----Original Message-----
From: WebAIM-Forum [mailto: = EMAIL ADDRESS REMOVED = ] On Behalf Of Birkir R. Gunnarsson
Sent: Friday, December 22, 2017 6:46 AM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] WCAG 2.0 1.4.4 relating to form elements

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 ADDRESS 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
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.