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 a simple forms test 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.
This entry was posted on February 21st, 2010, and filed under Web life.
Everett Zufelt said on February 21st 2010 at 4:42 pm:
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
Tink said on February 21st 2010 at 5:36 pm:
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 :)
graste said on February 21st 2010 at 5:46 pm:
When screenreaders allow selecting of readonly radio buttons, does this mean that those _changes_ are eventually submitted by the user agent?
LĂ©onie Watson said on February 21st 2010 at 6:10 pm:
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.
James Teh said on February 22nd 2010 at 10:10 pm:
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. :)
James Teh said on February 22nd 2010 at 10:13 pm:
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>
LĂ©onie Watson said on February 23rd 2010 at 8:12 pm:
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?
Joanna Wall said on December 23rd 2010 at 10:21 pm:
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. :)
James Nurthen said on June 20th 2012 at 5:10 pm:
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.