Comment 1 by briang1 on 2014-05-30 19:18
I am not quite sure what you mean exactly here. Do you have a page in mind. does it not see all kinds of changable controls like buttons, combo boxes etc?

Comment 2 by ABuffEr (in reply to comment 1) on 2014-05-30 19:59
Replying to briang1:
Hi Brian,
for example, see here:
http://www.cs.tut.fi/~jkorpela/forms/readonly.html
Try to move pressing "e" or "f"; in almost all cases, read-only fields (that are after "normal field") are not intercepted using these shortcuts.
I noticed now that this not happens in Chrome, but I suspect it's a Chrome problem, exposition of some HTML attribute.

Comment 3 by ABuffEr (in reply to comment 2) on 2014-05-30 20:04
Note: to be definitely clear, last consideration about Chrome doesn't concern this ticket.

Comment 4 by briang1 on 2014-05-31 07:12
OK, I'm not totally sure what you mean, but then I'm no html expert. I generally encounter fields that under certain circumstances of previous input to a form, would allow choices, but due to the current inputs are fixed at a default. sometimes these can be tabbed to, and sometimes not. I've always assumed that this behaviour was at the discretion of the site builders.

In effect read only edit areas are just controls with just the one choice, if they are in the editable list or act as non functioning buttons.
Are you asking for them to have a specific control key to find them then?
sorry if I'm being thick, but to me there are more important issues with some forms, such as the ones created in Survey Monkey for example, than the treatment of items you are no allowed to change under some circumstances.

Comment 5 by Brendon22 on 2014-05-31 10:05
Hello,

I think this person wants the letter E to move to edit fields. Please try this on the website and report back if this resolves your issue.

Comment 6 by ABuffEr (in reply to comment 5) on 2014-05-31 13:29
Ok, last attempt to clarify my request:

1. using Firefox or Internet Explorer, open this link:
   http://www.cs.tut.fi/~jkorpela/forms/readonly.html
2. press "E" to move to field containing "Normal field" text; this is a normal editable field, and it's ok;
3. press down arrow to move to a second field, containing "read-only" text; is it a field? Yes, but it's in read-only;
4. return to the first field containing "Normal field" with up arrow;
5. press "E"; you are not able to reach the second field, because it's in read-only.
   And this is the problem.
   In addition, the link contains various examples of these couple of fields, and in some cases NVDA intercepts fields in read-only as normal editable fields, but this is not a NVDA defect, maybe, or it's another defect anyway.

Comment 7 by Brendon22 on 2014-06-01 09:12
Abuffer,

Thank you for your reply. Confirmed you should be able to press Shift+E to move back to the read only edit field. But this doesn't seem to work? I was using IE 11 on Windows 7 64-Bit.

Comment 8 by jteh on 2014-06-01 09:21
The reporter is simply asking for the e and f quick navigation keys to include read-only fields. They don't currently do this in most browsers. Whether they should is an open question.

Comment 9 by ABuffEr (in reply to comment 8) on 2014-09-07 10:30
Sorry for the delay. Well, read-only fields are reasonably rare, in my experience, but, when present, they contain useful information (address for cloning repositories, short link, and so on); so, I think their inclusion (eventually controlled by a checkbox in settings) should be more useful than annoying.

Comment 10 by beqa on 2014-09-07 11:13
hi.
i checked this site, and looked at elements.

the problem i think is that it isROLE_SYSTEM_DOCUMENT, but it is just a thought.

if you agree i can try to implement it.

Comment 11 by ABuffEr (in reply to comment 10) on 2014-09-07 13:17
Hi Beqa,
I agree, of course :) the site linked above is an example (found expressly for this ticket), but it's a good example, containing probably all types of edit fields.

Comment 12 by jteh on 2014-09-07 21:39
A read-only edit field has a role of ROLE_SYSTEM_TEXT, not ROLE_SYSTEM_DOCUMENT. It has STATE_SYSTEM_READONLY and IA2_STATE_EDITABLE.

Comment 13 by nvdakor on 2014-10-15 05:41
Hi,
A quick fix would be to check the state of the edit field and let the browse mode implementation move the user to the read-only field. As a previous comment suggests, it should be a setting from within browse mode to control whether E/Shift+E will detect read-only controls, similar to how one can ask NVDA to ignore layout tables. A similar scenario to what Alberto is asking was discussed on the Korean users forum where it was stated that many Korean websites use read-only fields to present information such as postal addresses and remaining time for filling out forms (I'll ask over there to provide an example website).
As for the fix, it raises some questions:

• Do you want this to be global (apply to all sites) or to specific ones? This was the same question that was asked a few weeks ago and the answer was that this is a global setting that'll affect all sites.
• Can't the webmaster use ARIA to alert a blind user about notifications such as time remaining and what not, the kind of info that would normally be found in read-only edit boxes? The issue is that in some countries, ARIA hasn't gained a foothole where it is something to be followed (South Korean websites examplify this problem, as they emphasize mouse-based navigation and control manipulation, according to users and web accessibility specialists there).
• Will our fix be stable over time? Web is changing rapidly (more so now; a good example is Google). Who knows when majority of sites may move away from read-only controls to display status information, use ARIA more, use sophisticated code designed for touch users, etc. As such, although the inclusion of read-only edit boxes may resolve the issue raised here, it may not be a good long-term solution (in my opinion). However, I do understand that some users may need this feature, so I'd say let's give it a try at least and see what happens next.
  Thanks.

Comment 14 by nvdakor on 2014-10-19 15:36
Hi,
Someone from Korean users forum sent me the following steps. Note you need to use Korean IME to use it.
STR:

1. Go to http://member.gmarket.co.kr/challenge/neo_member/default.asp.
2. Open NVDA Find dialog, switch to Korean input method, then type the following using native input mode: rkdlqgkrl, then press ENTER to search.
3. Once the form loads, press C to move to the first combo box, then press TAB several times until you land at the read-only field - this is the address input field.
   Thanks.

We decided the e and f single letter navigation keys should include read-only editable text fields.

A read-only edit field has a role of ROLE_SYSTEM_TEXT, not ROLE_SYSTEM_DOCUMENT. It has STATE_SYSTEM_READONLY and IA2_STATE_EDITABLE.

It seems read only edit fields now have ROLE_EDITABLETEXT, according to my observations in Firefox.
Also note that in Chrome, a read only edit field like in this attachment can be reached with e and is not identified as a read only field. However, it is not possible to input anything in the field of course.

This is probably a chromeium bug. should this be reported?

On 7/6/2016 8:58 AM, Leonard de Ruijter wrote:

A read-only edit field has a role of ROLE_SYSTEM_TEXT, not
ROLE_SYSTEM_DOCUMENT. It has STATE_SYSTEM_READONLY and
IA2_STATE_EDITABLE.

It seems read only edit fields now have ROLE_EDITABLETEXT, according
to my observations in Firefox.
Also note that in Chrome, a read only edit field like in this
attachment
https://github.com/nvaccess/nvda/files/350143/edit.html.txt can be
reached with e and is not identified as a read only field. However, it
is not possible to input anything in the field of course.

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#4164 (comment),
or mute the thread
https://github.com/notifications/unsubscribe/AFGivT4HWu5cDC9YBP49OP3A94FU49ipks5qS8KfgaJpZM4JFrCm.

Derek Riemer

• Department of computer science, third year undergraduate student.
• Proud user of the NVDA screen reader.
• Open source enthusiast.
• Member of Bridge Cu
• Avid skiier.

Websites:
Honors portfolio http://derekriemer.com
Awesome little hand built weather app!
http://django.derekriemer.com/weather/

email me at derek.riemer@colorado.edu mailto:derek.riemer@colorado.edu
Phone: (303) 906-2194

I realised Jamie, sorry for that.
In this commit, we have a fix for Mozilla documents. Is this the right way to do this, or am I overlooking something? For example, does ignoring the read only state in form field navigation have any impact on elements other than edit boxes?

Ouch, you're very true indeed. Fixed.

This is probably a chromeium bug. should this be reported?

I'm not sure:

• Read only field: IAccessible2 attributes: u'display:inline-block;tag:input;explicit-name:true;id:readonly;text-input-type:text;'
• Read/write field: IAccessible2 attributes: u'display:inline-block;tag:input;explicit-name:true;id:readwrite;text-input-type:text;'

In other words, it should be possible for NVDA to distinguish those, but that's something for another ticket.