Re: Disabled form fields

Harry,

Please note, for organizations that have set (WCAG 2.0 A/AA or WCAG 2.1
A/AA) normative compliance as their requirement, the color contrast
exception for disabled fields is valid.

The use of dim color to indicate a field is disabled is a problem...but
solving that problem has been deferred to Silver (or WCAG 2.2. at least).

Why?  Because to truly solve this problem...I believe we will need a visual
disabled indicator symbol that meets color contrast (not just dim
color)....this will be very valuable for low vision, but also people with
cognitive disabilities (and as usual..will improve design for all).

As it stands now...the dimming of the disabled fields is helpful to SOME
people who are low vision and some people who have cognitive disabilities
because it helps them mentally filter out those fields.  BUT...if we try to
solve this problem just with color contrast...then it becomes difficult for
low vision users and people with disabilities AND everyone to tell which
fields are active and which are disabled.  This is why it has been delayed
until silver.  I bet we end up solving this with a disabled symbol.

Peace, Love & A11Y,
G

*glenda sims* <glenda.sims@deque.com>, cpacc
<http://www.accessibilityassociation.org/certification>   | team a11y lead
| 512.963.3773

        deque systems <http://www.deque.com>  accessibility for good


On Mon, Dec 17, 2018 at 5:13 AM Harry Loots <harry.loots@ieee.org> wrote:

> Thanks All for your contributions.
>
> Sounds like we are in general agreement, that it may be affected by the
> exception, but that it should not be, and that it should possibly be made
> much clearer to users when a field is disabled to avoid confusion.
>
> Note that disabled and readonly fields do not behave the same, and each
> have their specific role to play in forms:
>
>    - Disabled controls do not receive focus / readonly do.
>    - Disabled controls are skipped in tabbing navigation / readonly are
>    included in tabbing.
>    - Disabled values are not posted for processing / readonly values are
>    posted (even though the user cannot change this value).
>
> Kindest regards
> Harry
>
>
>
> On Mon, 17 Dec 2018 at 01:31, Steve Green <steve.green@testpartners.co.uk>
> wrote:
>
>> It’s certainly a bug with one or both of them, but it’s not really
>> important where the fault lies. The important thing is that developers are
>> aware of it and that they take the necessary measures to ensure it can’t
>> cause a problem.
>>
>>
>>
>> In a good design, the values in read-only fields should not be written
>> back to the database. That would ensure that the data cannot be modified by
>> any means (such as using developer tools) not just by this Dragon issue.
>>
>>
>>
>> Steve
>>
>>
>>
>> *From:* Sean Murphy (seanmmur) <seanmmur@cisco.com>
>> *Sent:* 16 December 2018 22:29
>> *To:* Steve Green <steve.green@testpartners.co.uk>; 'W3C WAI ig' <
>> w3c-wai-ig@w3.org>
>> *Subject:* RE: Disabled form fields
>>
>>
>>
>> Steve,
>>
>>
>>
>> Isn’t this a bug with Dragon or the browser? As I would have expected if
>> a read-only field was configured. Nothing should be able to modify it?
>>
>>
>>
>> [image:
>> https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/standard/02_standard_ciscoblue02.png]
>>
>> *Sean Murphy*
>>
>> SR ENGINEER.SOFTWARE ENGINEERING
>>
>> seanmmur@cisco.com
>>
>> Tel: *+61 2 8446 7751*
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> Cisco Systems, Inc.
>>
>> The Forum 201 Pacific Highway
>>
>> ST LEONARDS
>>
>> 2065
>>
>> Australia
>>
>> cisco.com
>>
>> [image: http://www.cisco.com/assets/swa/img/thinkbeforeyouprint.gif]
>>
>> Think before you print.
>>
>> This email may contain confidential and privileged material for the sole
>> use of the intended recipient. Any review, use, distribution or disclosure
>> by others is strictly prohibited. If you are not the intended recipient (or
>> authorized to receive for the recipient), please contact the sender by
>> reply email and delete all copies of this message.
>>
>> Please click here
>> <http://www.cisco.com/c/en/us/about/legal/terms-sale-software-license-agreement/company-registration-information.html>
>> for Company Registration Information.
>>
>>
>>
>>
>>
>> *From:* Steve Green <steve.green@testpartners.co.uk>
>> *Sent:* Monday, 17 December 2018 6:44 AM
>> *To:* 'W3C WAI ig' <w3c-wai-ig@w3.org>
>> *Subject:* RE: Disabled form fields
>>
>>
>>
>> Whilst I would not necessarily disagree, it is worth noting that Dragon
>> voice recognition software can actually write to read-only textboxes.
>> Depending on the context, this may or may not be a problem.
>>
>>
>>
>> It certainly was a problem on a timesheet website we were testing
>> recently. The hours in the timesheet should not be editable by a manager,
>> but they did need to fill in other fields and submit the form. If they were
>> using Dragon, they could modify the hours too. A server-side solution was
>> used to ignore the changes to the hours, although other approaches may work.
>>
>>
>>
>> Steve Green
>>
>> Managing Director
>>
>> Test Partners Ltd
>>
>>
>>
>>
>>
>> *From:* Adam Cooper <cooperad@bigpond.com>
>> *Sent:* 14 December 2018 23:00
>> *To:* 'Harry Loots' <harry.loots@ieee.org>; 'W3C WAI ig' <
>> w3c-wai-ig@w3.org>
>> *Subject:* RE: Disabled form fields
>>
>>
>>
>> The subject of this thread is ‘disabled form fields’.
>>
>>
>>
>> Is this a question about colour contrast or the appropriate use of the
>> disabled attribute?
>>
>>
>>
>> In my view, the disabled attribute should never be used on a text field –
>> only the readonly attribute.
>>
>>
>>
>> And, conversely, the readonly attribute shouldn’t be used on radio or
>> push buttons or select elements etc.
>>
>>
>>
>> This at least makes the problematic user agent styling go away for
>> inactive text fields …
>>
>>
>>
>> With regards to disabled elements with activation behaviours, however,
>> there is tension in my mind between:
>>
>>    - Colour being the only visual conveyor of information (i.e. success
>>    criterion 1.4.1) and this exception
>>    - There being a blanket exception for disabled controls
>>
>>
>>
>> These seem to me to be glitches, though I can understand that changing
>> this requirement could be problematic both then and now.
>>
>>
>>
>>
>>
>>
>>
>> *From:* Harry Loots [mailto:harry.loots@ieee.org <harry.loots@ieee.org>]
>> *Sent:* Friday, December 14, 2018 9:20 PM
>> *To:* W3C WAI ig
>> *Subject:* Disabled form fields
>>
>>
>>
>> Dear all
>>
>>
>>
>> My understanding of SC 1.4.3 (Contrast) is that disabled form fields
>> should also be subject to minimum contrast levels, since these fields may
>> provide pertinent information to the user.
>>
>>
>>
>> Example from Google Material Design assets:
>>
>> [image: image.png]
>>
>>
>>
>> What is the view of this group?
>>
>>
>>
>> Kindest regards
>>
>> Harry
>>
>>
>>
>