Screen Reader Support For Disabled & Read Only Form Fields

Some while ago I was asked how screen readers handle disabled and read only form fields. Despite forms being commonplace on most websites, there’s remarkably little information available on the subject. It turns out that there’s also very little consistency in the way different screen readers behave either.

The HTML 4.01 specification defines two attributes that can be used to prevent people from interacting with form fields:

  • disabled
  • readonly

Both attributes are boolean, meaning they can either be on or off.

Disabled Form Fields

The disabled attribute can be applied to button, input, optgroup, option, select and submit form fields. For example:

<input type=”text” disabled=”disabled” />

When applied to a form field, the disabled attribute means that the field:

  • Should not receive focus.
  • Should be skipped in the tab order.
  • Should not successfully submit data.

Read Only Form Fields

The readonly attribute can be applied to input and textarea form fields. For example:

<input type=”text” readonly=”readonly” />

When applied to a form field, the readonly attribute means that a field:

  • Should receive focus, but cannot be modified by the user.
  • Should be included in the tab order.
  • Should successfully submit data.

Screen Reader Results

Using these disabled form fields and readonly form fields test cases,
page, I looked at the way three popular screen readers dealt with disabled and read only form fields. It wasn’t meant to be an exhaustive investigation, but more a chance to get a flavour of screen reader support. The screen readers in question were:

  • Jaws 11.
  • NVDA 2009.1.
  • Window Eyes 7.11.

To keep things even, I put each screen reader through its paces in two different browsers:

  • Firefox 3.6.
  • Internet Explorer 8.

The results were extremely varied, with little consistency across either screen readers or browsers.

All three screen readers correctly reported when a form field was disabled, except for Jaws in Firefox. For some reason, Jaws treats disabled textboxes and textareas as though they weren’t there in Firefox at all.

There are slight differences in the way each screen reader reports a disabled form field. Jaws and NVDA both indicate the field is “Unavailable”, whilst Window Eyes reports that the field is “Disabled”.

Things get a little more complicated with read only form fields. NVDA and Window Eyes treat read only textboxes and textareas as plain text, so don’t report them as read only fields. Jaws does treat them as form fields and reports them as “Read only”, with the exception of textareas in Firefox.

Read only radio buttons are recognised as form fields by all three screen readers, but none of them correctly report them as “Read only”. To add to the confusion, read only buttons could be selected using all three screen readers.

Jaws and NVDA both exclude disabled form fields from the tab order, whilst Window Eyes does not. Bear in mind that Jaws completely ignores disabled textboxes and textareas in Firefox, which isn’t quite the same as skipping them in the tab order.

All three screen readers include read only radio buttons in the page tab order. In a reversal of the way disabled form fields are treated, Jaws and NVDA both include read only textboxes and textareas in the tab order, whilst Window Eyes does not.

Generally speaking, NVDA treated disabled and read only form fields most consistently. It was also the most accurate in terms of following the HTML 4.01 specification.

Window Eyes was reasonably consistent across both browsers, but didn’t follow the specification for disabled and read only fields particularly well. Jaws on the other hand seemed a little more true to the specification, but gave the most inconsistent results overall.

If anyone would like to contribute results for other screen readers or can add more information to the above results, please drop me a line.

25 comments on “Screen Reader Support For Disabled & Read Only Form Fields”

Skip to Post a comment
  1. Comment by Everett Zufelt

    Excellent post. I took a look at the test page with VoiceOver on OS X Snow Leopard (10.6.0) and Safari 4.0.3.

    1. The Disabled form fields are not part of the tab order.

    2. Disabled form fields are identified as “dimmed”, essentially meaning grayed out or disabled.

    3. Nothing was announced by VoiceOver to indicate that a form field is read only.

    4. Users cannot type into text fields or text areas that are disabled or read only.

    5. Users cannot select radio buttons that are disabled.

    6. Users can select radio buttons that are read only.

    7. Users cannot make selections in select boxes that are disabled.

    Thanks again for the great article,
    Everett

  2. Comment by Tink

    Thanks Everett. I’m glad you’ve added some results from VoiceOver… It’s one platform I don’t have immediate access to at the moment 🙂

  3. Comment by graste

    When screenreaders allow selecting of readonly radio buttons, does this mean that those _changes_ are eventually submitted by the user agent?

  4. Comment by Léonie Watson

    I didn’t test this thoroughly, but it seems that if a read only radio button is selected then the selection is submitted with the rest of the form data.

  5. Comment by James Teh

    Just some (rather technical) thoughts from an NVDA developer. 🙂

    The problems with Windows screen readers and detecting read-only fields are partly caused by the way web browsers currently expose information to accessibility APIs. MSAA provides ROLE_SYSTEM_TEXT which is the role normally used for editable text fields. For some reason, a decision was historically made (probably by Microsoft) to expose normal text leaf nodes with ROLE_SYSTEM_TEXT, using the read-only state to differentiate them from editable text fields. This means that using MSAA, you can’t differentiate text leaf nodes from read-only editable text fields. For example:
    test
    looks the same in MSAA as:

    Screen readers don’t use MSAA alone to get their information from web browsers, so it’s theoretically possible to detect this, but it isn’t trivial and MSAA is still used as the primary source for some information.

    I can certainly look into fixing this for NVDA if someone wants it badly, but read-only editable text fields on the web tend to be quite rare, so there haven’t been any requests from our users to fix this. As I say, the fix isn’t trivial and there’s always plenty of other high priority work for us to do. 🙂

  6. Comment by James Teh

    Bah. WordPress clobbered my example. Let’s try this.

    <div>test</div>
    looks the same in MSAA as:
    <div><input type=”text” readonly=”readonly” value=”test”></div>

  7. Comment by Léonie Watson

    James, I guess that explains why screen readers seem to have trouble with these form fields. Do you think UI Automation will/has improve things at all?

  8. Comment by Joanna Wall

    Just some (rather technical) thoughts from an NVDA developer. 🙂 The problems with Windows screen readers and detecting read-only fields are partly caused by the way web browsers currently expose information to accessibility APIs. MSAA provides ROLE_SYSTEM_TEXT which is the role normally used for editable text fields. For some reason, a decision was historically made (probably by Microsoft) to expose normal text leaf nodes with ROLE_SYSTEM_TEXT, using the read-only state to differentiate them from editable text fields. This means that using MSAA, you can’t differentiate text leaf nodes from read-only editable text fields. For example: test looks the same in MSAA as: Screen readers don’t use MSAA alone to get their information from web browsers, so it’s theoretically possible to detect this, but it isn’t trivial and MSAA is still used as the primary source for some information. I can certainly look into fixing this for NVDA if someone wants it badly, but read-only editable text fields on the web tend to be quite rare, so there haven’t been any requests from our users to fix this. As I say, the fix isn’t trivial and there’s always plenty of other high priority work for us to do. 🙂

  9. Comment by James Nurthen

    Quick comment about readonly radio buttons (& checkboxes).

    Setting readonly on these controls doesn’t really work the way you would expect. All users can still check a checkbox or select a radio button even if it is marked as readonly.

    Indeed HTML5 forbids using readonly on input elements of type checkbox or radio.

  10. Comment by Robert

    I’m curious as to how this should be handled for Section 508 compliancy. If we present a form in a web application and only some fields are editable, but others are not, we cannot simply exclude those fields from the tab order and not read their values as this would be violating 508 rules. Showing information on screen that is not accessible is a violation of 508 rules. Thoughts?

    1. Comment by Léonie Watson

      When a field is disabled it cannot be interacted with, but it is still visible and its contents can still be accessed by ATs. It may be a usability problem, but I don’t think it constitutes a 508 fail – at least not as far as 1194.21L or 1194.22N go.

  11. Comment by Robert

    Not according to the spec noted above for Disabled fields. Only Read Only fields would function like you noted. But it seems JAWS does not recognize the Read Only fields, it skips right over them. Hence my question.

    1. Comment by Léonie Watson

      It only removes the field from the tab order. So if a screen reader user is tabbing through the form they will skip the field, but screen reader users are not constrained to using the tab key so they can access and read the field in other ways.

  12. Comment by Robert

    It could be our coder didn’t code something correctly. I’ll follow up.

  13. Comment by Robert

    I would argue that all information for the form should be presented in a logical order and they should be able to Tab through all fields and hear their values and also hear if the current field is editable.

  14. Comment by Sam

    As noted correctly in one of above notes, the Disabled fields are grayed out. However while it is useful while we are in Screen Reader mode, it is not needed in ‘Regular’ mode. Is it possible to bypass this, i.e. get rid of disabled field’s grey background in ‘Regular’ mode?

    1. Comment by Léonie Watson

      It’s possible to style disabled fields just like any other. You can use the input:disabled selector for example.

      That said, I don’t agree that the visual presentation of disabled fields is unimportant. For good UX it’s a good idea to make it clear that a field is disabled.

  15. Comment by Sam

    Thank you Léonie for prompt response.
    Could you please clarify?
    In my jsff file, I have

    And this code makes this field grayed out both in ‘Screen Reader’ and ‘Regular’ modes.
    What should I do to remove gray background in ‘Regular’ mode (as required by our design)?
    Replacing ‘disabled’ with ‘readOnly’ makes this field tabbable (i.e. receiving focus) in ‘Screen Reader’ mode (not in Regular mode).
    Any other solutions?

    1. Comment by Léonie Watson

      The design should make it obvious that the field is disabled. Removing the background colour is ok, providing the design uses other styles to visually indicate the field is disabled. You can style the field using the CSS mentioned before.

  16. Comment by Sam

    Sorry, my pseudo-code itself somehow was excluded from my post when I submitted it.
    this is the pseudo-code:
    af:inputText label=”…”
    value=”…”

    disabled=”yes”

  17. Comment by Miriam

    I came accross the following phenomenon:

    A checkbox gets read as readonly although neither via HTML nor ARIA the readonly property is applied.

    I’m using Chrome: 71.0.3578.98
    JAWS: 2019

    The HTML structure is as follows, once the field is invalid:

    Error Message
    Lorem *

    ipsum dolor sit amet.

    The thing I added was the aria-labelledby attribute so that both labels would be read in the order I wanted to. Without aria-labelledby the checkbox does not get read as readonly. Once I add aria-labelledby the checkbox is read as readonly. But only if I navigate to it forwards with the tab-key. If I navigate backwards with shift+tab, readonly is not read.

    The only hint I could find is that this seemed to be a bugg of JAWS with Chrome back in 2014. But it is marked as fixed.

    If this is still a bug, is there another way to have both labels applied to the checkbox in that very order?

    1. Comment by Léonie Watson

      Without seeing the code it’s hard to be sure, but I wrote a test case based on your description and I don’t experience the problem with Jaws 2019 and Chrome 71.

      If you think there is still a bug in Jaws though, it’s worth filing it on their issue tracker:
      https://github.com/FreedomScientific/VFO-standards-support/issues

      FWIW, I really caution against using a label either side of a checkbox. It will make the UX for screen reader users much more difficult.

      1. Comment by Miriam

        Error Message
        Lorem

        ipsum dolor sit amet.

  18. Comment by Miriam

    Ok, I see now the HTML-Tags I posted get deleted.

    I’ll post the structure like this:

    div id=’error’ Some Error Message /div
    label id=’label1′ for=’list’ Label text /label
    ul id=’list’
    li
    label id=’label2′ for=’checkbox’
    input type=’checkbox’ name=’xy’ id=’checkbox’ aria-required=’true’ aria-labelledby=’label1 label2′ aria-describedby=’error’
    Text for Label 2
    /label
    /li

    1. Comment by Léonie Watson

      Miriam, I still can’t reproduce the problem when I create a test case using your code.

      I did notice that you’re associating the first label with the ul. To the best of my knowledge, the for/id attribute pairing isn’t supported for the ul element. I don’t think this is relevant to the readonly problem you’re experiencing though.

      I really struggled to understand what my screen reader was telling me, when I was testing this. The two labels, plus the fact the field is inside a listitem but one of the labels is not, really confused things and made the experience very “noisy”. It’d be a shame to do all this accessibility hard work, only for the end result to be unusable anyway. Strongly recommend not having two labels, and also not putting the form inside a list.

Comment on this post

Will not be published
Optional

This site uses Akismet to reduce spam. Learn how your comment data is processed.