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
Comments
Is CkEditor contained in an "application"? That is, can you get to the
editable content in browse mode with the arrow keys or do you only hear
application? If so, browse mode will never be able to get to this, since
applications are very intentionally not exposed in browse mode.
Note that there are still some rich text edit fields that aren't inside
applications and quick navigation doesn't currently move to those, but
it should.
|
STR:
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). |
A lot of rich text editors use role=aplication around the editor and
controls.
…On 1/4/2017 4:14 PM, James Teh wrote:
|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).
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#5534 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AFGiverKL7AplQU3IgLCGqWtJd-mTI8xks5rPCftgaJpZM4GoD6G>.
--
------------------------------------------------------------------------
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
|
That we can't cover here, I'm afraid. If something is an application, it's
not included in browse mode unless the user focuses the application and
forces it.
|
@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. |
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) |
As well as the normal editableText role, We will look for the editable state, but only on document, textFrame, section and paragraph. |
@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. |
Seconded.
…On 8/29/17, Derek Riemer ***@***.***> wrote:
@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)
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
#5534 (comment)
--
Best Regards
Bhavya Shah
Blogger at Hiking Across Horizons: https://bhavyashah125.wordpress.com/
Contacting Me
E-mail Address: bhavya.shah125@gmail.com
Follow me on Twitter @BhavyaShah125 or www.twitter.com/BhavyaShah125
Mobile Number: +91 7506221750
|
Whether this is actually a grammatical "fix" is IMO highly debatable. I'm not strictly for or against the Oxford comma; there are times it's useful and times when it's not. In this case, this is a very simple list and the "and" seems to be a pretty clear separator.
|
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.
The text was updated successfully, but these errors were encountered: