Read only state announcement for edit fields when changing focus

[nvaccessAuto]

Reported by oaron on 2011-03-28 13:09
NVDA does not provide state information, i.e. if an edit field is read only when changing focus, e.g. with the tab/shift+tab keys. The state can be seen with NVDA+tab.
Expected: When NVDA encounters an edit field, it should also announce that the edit field is read only, along with multi-line, etc.
Affected: All applications with read only standard or rtf controls, such as Miranda with its scriver plugin.

[nvaccessAuto]

Comment 1 by jteh on 2011-03-28 21:11
This is by design. There is no real user visible difference between a read-only control and one that isn't read-only until the user tries to enter text, at which point it will become obvious that it is read-only. Also, the fact that a control is read-only is usually fairly obvious from the content. Therefore, stating that it is read-only is unnecessary verbosity. Finally, as I understand it, there's no visual difference between a read-only control and one that isn't read-only, which suggests that the designers didn't see the need for users to know about this immediately. If I'm incorrect about this, we should change the behaviour so that screen reader users have an equivalent experience.
Changes:
Added labels: wontfix
State: closed

[nvaccessAuto]

Comment 2 by fatma.mehanna (in reply to comment description) on 2011-04-01 20:48
Replying to oaron:

NVDA does not provide state information, i.e. if an edit field is read only when changing focus, e.g. with the tab/shift+tab keys. The state can be seen with NVDA+tab.

Expected: When NVDA encounters an edit field, it should also announce that the edit field is read only, along with multi-line, etc.

Affected: All applications with read only standard or rtf controls, such as Miranda with its scriver plugin.

where as there's no visibility difference between the read only edit field and which is not a read only one,
how can the other screen readers differentiate between them?
Changes:
Removed labels: wontfix
State: reopened

[nvaccessAuto]

Comment 3 by jteh on 2011-04-01 21:00
See my comment above. We can differentiate between them. However, we don't see any reason to do so.
Changes:
Added labels: wontfix
State: closed

[nvaccessAuto]

Comment 4 by oaron (in reply to comment 3) on 2011-04-02 09:54
Replying to jteh:

See my comment above. We can differentiate between them. However, we don't see any reason to do so.

From this point of view, saying that a menu item is currently not available (grayed) is also not quite reasonable, since a user can press enter on the item and see if it has any result afterwards. Similarly with a checkbox a user can press space to toggle it and see what it was on, previously.
My main argument here is why should a user interact with a control, in this case start typing, or perform various editing operations, etc, just to find out that an edit field is read only?
It all depends on verbosity. I could argue that the state of a checkbox, radio button, etc, is not as important as the control and its role, thus these information could also be moved and requested upon a nvda+tab keypress. From a verbose point of view it is excellent, but letting a user know about it in order of importance can become helpful.

[nvaccessAuto]

Comment 5 by jteh (in reply to comment 4) on 2011-04-02 10:09
Replying to oaron:

From this point of view, saying that a menu item is currently not available (grayed) is also not quite reasonable, since a user can press enter on the item and see if it has any result afterwards.

There's one big difference. An unavailable menu item is very clearly distinguished as unavailable for other users as well. For sighted users, it's greyed out. My understanding (in consultation with a sighted user) was that you can't visually differentiate between a read-only editable text field and one that isn't read-only. However, another sighted user on the list says you can differentiate with default styling. If we can confirm that this is definitely the case, we should consider reopening and fixing this.

[nvaccessAuto]

Comment 6 by jteh on 2011-04-02 19:06
From a sighted developer on the list:

In addition to the Enabled property, text edit controls have a ReadOnly property.  When ReadOnly = true, the text stays the same color (black) but the background color turns to the same shade of grey as when Enabled is set to true.  You can still tab to and click on the control, and even select the text and copy to the clipboard.  There is indeed a visual difference, although the average user is often confused by the two.

Now this is all in the Windows world, but it has been "standard" behavior (again, for what that's worth) since at least Windows 3.0.  OS/2 behaved the same, and KDE and Gnome in Linux did the same at least around 10 years ago when I was last using them regularly.

So we should be announcing read-only on focus for editable text controls.
Changes:
Milestone changed from None to near-term
Removed labels: wontfix
State: reopened

[nvaccessAuto]

Comment 7 by jteh on 2011-05-13 06:13
0a048fe
Changes:
Milestone changed from near-term to 2011.2
State: closed