RE: Disabled form fields

Usually disabled items on a form will be enabled via JavaScript when appropriate conditions are met. For example, an "other" radio button with a text field that gets enabled when "other" is selected. Or a download button that gets activated when you have checked the "I agree to the terms of the license agreement." 

Sometimes, these fields will also be hidden which is probably better for cognitive disabilities, but can confuse some screen reading software, especially if focus control is not properly managed as the item is shown and hidden.
Of course, there are additional risks with disabled forms if the browser in use does not support JavaScript.
Jonathan Cohn

-----Original Message-----
From: Karen Lewellen <klewellen@shellworld.net> 
Sent: Sunday, December 16, 2018 7:44 PM
To: Steve Green <steve.green@testpartners.co.uk>
Cc: 'W3C WAI ig' <w3c-wai-ig@w3.org>
Subject: RE: Disabled form fields

what I find interesting about this thread is how others write of disabled form fields as if they serve a productive purpose.  Speaking personally, a read only field, one my browser identifies  as such may be one thing. 
The disabled form  buttons, those which prevent  in my personal experience me from moving forward at all, are another animal all together.
Just encountered one trying to order a product, you cannot even start the buying process because the button is a disabled form one.
am I confusing the examples here with something else?
As expressed when I find a read only  form button, one that cannot be modified it  is usually understandable.  but a disabled form field with an alt tag suggesting it should work?
Cheers,
Karen



On Mon, 17 Dec 2018, Steve Green 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?
>
> [https://www.cisco.com/c/dam/m/en_us/signaturetool/images/banners/stan

> dard/02_standard_ciscoblue02.png]
>
>
>
>
> Sean Murphy
> SR ENGINEER.SOFTWARE ENGINEERING
> seanmmur@cisco.com<mailto:seanmmur@cisco.com>
> Tel: +61 2 8446 7751
>
>
>
>
>
>
>
>
>
>
> Cisco Systems, Inc.
> The Forum 201 Pacific Highway
> ST LEONARDS
> 2065
> Australia
> cisco.com
>
>
>
> [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<mailto:steve.green@testpartners.co.uk>
> >
> Sent: Monday, 17 December 2018 6:44 AM
> To: 'W3C WAI ig' <w3c-wai-ig@w3.org<mailto: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<mailto:cooperad@bigpond.com>>
> Sent: 14 December 2018 23:00
> To: 'Harry Loots' <harry.loots@ieee.org<mailto:harry.loots@ieee.org>>; 
> 'W3C WAI ig' <w3c-wai-ig@w3.org<mailto: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]
> 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.png]
>
> What is the view of this group?
>
> Kindest regards
> Harry
>
>

Received on Monday, 17 December 2018 15:19:28 UTC