New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Single letter navigation to editable text fields should include rich text editors #5534

Closed
khsbory opened this Issue Nov 24, 2015 · 10 comments

Comments

Projects
None yet
7 participants
@khsbory

khsbory commented Nov 24, 2015

Hello, I’m Hyongsop Kim in Korea and NVDA 2015.4 user.
In web browser and BrowseMode is on, if I press e, NVDA jump to the next edit field.
By the way, if the edit field is RichText edit such as CkEditor, NVDA can’t recognize it as a edit field.
So to go to this field, I have to go by pressing tab or arrow keys.
So please consider about recognizing such field with BrowseMode quick navigation key.

Thank you.

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Nov 24, 2015

Contributor
Contributor

jcsteh commented Nov 24, 2015

@jcsteh jcsteh changed the title from BrowseMode and RichText edit field recognizing to Single letter navigation to editable text fields should include rich text editors Jan 4, 2017

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jan 4, 2017

Contributor

data:text/html,<p>Before</p><div contentEditable="true">Content</div><p>After</p>

STR:

  1. Open the above URL in Firefox and focus the document.
  2. Press control+home to move to the top.
  3. Press e.
  • Expected: NVDA should jump to the editor containing "Content".
  • Actual: It doesn't.

This should also work for the "f" form field navigation command.

Note that the role in this case is section, but the role is irrelevant. The key point in Firefox is that it has the editable state. In IE, the key point is that the element is contentEditable.

P2 because this makes getting to many rich text editors less efficient and because as far as a user is concerned, this is an editor (even though it reports differently).

Contributor

jcsteh commented Jan 4, 2017

data:text/html,<p>Before</p><div contentEditable="true">Content</div><p>After</p>

STR:

  1. Open the above URL in Firefox and focus the document.
  2. Press control+home to move to the top.
  3. Press e.
  • Expected: NVDA should jump to the editor containing "Content".
  • Actual: It doesn't.

This should also work for the "f" form field navigation command.

Note that the role in this case is section, but the role is irrelevant. The key point in Firefox is that it has the editable state. In IE, the key point is that the element is contentEditable.

P2 because this makes getting to many rich text editors less efficient and because as far as a user is concerned, this is an editor (even though it reports differently).

@jcsteh jcsteh added the p2 label Jan 4, 2017

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Jan 4, 2017

Collaborator
Collaborator

derekriemer commented Jan 4, 2017

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Jan 4, 2017

Contributor
Contributor

jcsteh commented Jan 4, 2017

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran Jul 21, 2017

Contributor

@jcsteh: as discussed by voice, not only will the editable container have the editable state, but all descendants within it. This includes say a button for instance, which can be focused and has the focusable state. So editable+focusable is not enough here. However, when before an editable, quicknav to editable will find the correct one because it will be the highest parent. When in, we could some how jump out of the current highest editable ancestor before searching again (though our infrastructure does not quite handle that yet). And searching backward, the parents would have to be searched before children, which I can't remember if we do that or not.

Contributor

michaelDCurran commented Jul 21, 2017

@jcsteh: as discussed by voice, not only will the editable container have the editable state, but all descendants within it. This includes say a button for instance, which can be focused and has the focusable state. So editable+focusable is not enough here. However, when before an editable, quicknav to editable will find the correct one because it will be the highest parent. When in, we could some how jump out of the current highest editable ancestor before searching again (though our infrastructure does not quite handle that yet). And searching backward, the parents would have to be searched before children, which I can't remember if we do that or not.

@leonardder

This comment has been minimized.

Show comment
Hide comment
@leonardder

leonardder Jul 21, 2017

Collaborator

Note that #7290 is a pr that will at least be of help for application based editors. Strictly spoken, @khsbory explicitly mentioned CkEditor, and as that seems to be application embedded from my last findings, that can't be fixed. See #5534 (comment)

Collaborator

leonardder commented Jul 21, 2017

Note that #7290 is a pr that will at least be of help for application based editors. Strictly spoken, @khsbory explicitly mentioned CkEditor, and as that seems to be application embedded from my last findings, that can't be fixed. See #5534 (comment)

@michaelDCurran

This comment has been minimized.

Show comment
Hide comment
@michaelDCurran

michaelDCurran Jul 28, 2017

Contributor

As well as the normal editableText role, We will look for the editable state, but only on document, textFrame, section and paragraph.

Contributor

michaelDCurran commented Jul 28, 2017

As well as the normal editableText role, We will look for the editable state, but only on document, textFrame, section and paragraph.

@derekriemer

This comment has been minimized.

Show comment
Hide comment
@derekriemer

derekriemer Aug 29, 2017

Collaborator

@michaelDCurran slight grammar fix for the what's new for this. Technically, the oxford comma doesn't really matter, but since there's a comma after the list it seems to make the sentence flow better.
In Firefox, Chrome and Internet Explorer, quick navigation to edit fields and form fields now includes editable rich text content (I.e. contentEditable). (#5534)
Needs to be
In Firefox, Chrome, and Internet Explorer, quick navigation to edit fields and form fields now includes editable rich text content (I.e. contentEditable). (#5534)

Collaborator

derekriemer commented Aug 29, 2017

@michaelDCurran slight grammar fix for the what's new for this. Technically, the oxford comma doesn't really matter, but since there's a comma after the list it seems to make the sentence flow better.
In Firefox, Chrome and Internet Explorer, quick navigation to edit fields and form fields now includes editable rich text content (I.e. contentEditable). (#5534)
Needs to be
In Firefox, Chrome, and Internet Explorer, quick navigation to edit fields and form fields now includes editable rich text content (I.e. contentEditable). (#5534)

@bhavyashah

This comment has been minimized.

Show comment
Hide comment
@bhavyashah

bhavyashah Aug 29, 2017

bhavyashah commented Aug 29, 2017

@jcsteh

This comment has been minimized.

Show comment
Hide comment
@jcsteh

jcsteh Aug 29, 2017

Contributor
Contributor

jcsteh commented Aug 29, 2017

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment