Re: Disabled form fields

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