WebAIM - Web Accessibility In Mind

E-mail List Archives

Thread: A question about content editable attribute with screen readers in HTML

for

Number of posts in this thread: 20 (In chronological order)

From:
Date: Wed, Jan 30 2019 6:20AM
Subject: A question about content editable attribute with screen readers in HTML
No previous message | Next message →

Hello, I’m Hyongsop Kim in Korea and accessibility tester.
May I ask your help regarding smart editable content with accessibility issue?
In Korea one company developed smart editor based on block navigation with contenteditable attribute.
By the way, even if I type several lines within edit area, screen readers doesn’t detect any text.
So in order to report this issue, I looked into Google Docs.
Because if I give similar cases, I think they will get clue more easily.
Of course Google Docs is not based on block navigation.
But if screen reader support is disabled, it also doesn’t support screen reader that enable reads the text inside of editable area.
So I supposed that if I find the difference markup with HTML OR JS between screen reader support is enabled or not, it will have a clue to report to our developers to solve this problem.
But because Google docs source code is too complicated, I can’t find how difference between screen reader support is enabled and not.
So below is my question.
If screen readers, like NVDA, can’t read the contents of editable area, how to fix the problem that let screen readers enables the text?
In Google Docs, why screen readers can’t detect text while screen reader support is disabled?
If you share the knowledge, it will be a lot of helpful to improve our Korean smart editor accessibility issues.

Thank you.

From:
Date: Wed, Jan 30 2019 6:36AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

Hello Hyongsop Kim.

Can you share an example of your code?

Screen readers should be able to read the contents of an element with
contenteditable, but it will depend on which screen reader and browser
you are using. Which screen readers and browsers are you testing with?

Léonie.



On 30/01/2019 13:20, 김형섭 wrote:
> Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> May I ask your help regarding smart editable content with accessibility issue?
> In Korea one company developed smart editor based on block navigation with contenteditable attribute.
> By the way, even if I type several lines within edit area, screen readers doesn’t detect any text.
> So in order to report this issue, I looked into Google Docs.
> Because if I give similar cases, I think they will get clue more easily.
> Of course Google Docs is not based on block navigation.
> But if screen reader support is disabled, it also doesn’t support screen reader that enable reads the text inside of editable area.
> So I supposed that if I find the difference markup with HTML OR JS between screen reader support is enabled or not, it will have a clue to report to our developers to solve this problem.
> But because Google docs source code is too complicated, I can’t find how difference between screen reader support is enabled and not.
> So below is my question.
> If screen readers, like NVDA, can’t read the contents of editable area, how to fix the problem that let screen readers enables the text?
> In Google Docs, why screen readers can’t detect text while screen reader support is disabled?
> If you share the knowledge, it will be a lot of helpful to improve our Korean smart editor accessibility issues.
>
> Thank you.
> > > > >

--
@LeonieWatson tink.uk Carpe diem

From:
Date: Wed, Jan 30 2019 6:48AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

Thank you so much for your email.
I tested with NVDA and JAWS with Chrome and Firefox with latest screen reader version.
And I know that general content editable is read by screen readers.
For example, in my wordpress hompage with Gutenberg, there is no problem to read.
But in our Korean homepage smart editor with block navigation, even if there are many lines, screen readers say just blank.
I really want to share the code, but I have no code, because I’m a accessibility tester.
Also I saved the editor in my local PC, but the behavior is different.
Of course if you cannot the original page, you might give me hard to advice, but if you have a guess and clue how to solve, please let me know.

Thank you.

김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장

서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996

http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark


-----Original Message-----
From: "Léonie Watson"< = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >; "김형섭"< = EMAIL ADDRESS REMOVED = >;
Cc:
Sent: 2019-01-30 (수) 22:36:16
Subject: Re: [WebAIM] A question about content editable attribute with screen readers in HTML

Hello Hyongsop Kim.

Can you share an example of your code?

Screen readers should be able to read the contents of an element with
contenteditable, but it will depend on which screen reader and browser
you are using. Which screen readers and browsers are you testing with?

Léonie.



On 30/01/2019 13:20, 김형섭 wrote:
> Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> May I ask your help regarding smart editable content with accessibility issue?
> In Korea one company developed smart editor based on block navigation with contenteditable attribute.
> By the way, even if I type several lines within edit area, screen readers doesn’t detect any text.
> So in order to report this issue, I looked into Google Docs.
> Because if I give similar cases, I think they will get clue more easily.
> Of course Google Docs is not based on block navigation.
> But if screen reader support is disabled, it also doesn’t support screen reader that enable reads the text inside of editable area.
> So I supposed that if I find the difference markup with HTML OR JS between screen reader support is enabled or not, it will have a clue to report to our developers to solve this problem.
> But because Google docs source code is too complicated, I can’t find how difference between screen reader support is enabled and not.
> So below is my question.
> If screen readers, like NVDA, can’t read the contents of editable area, how to fix the problem that let screen readers enables the text?
> In Google Docs, why screen readers can’t detect text while screen reader support is disabled?
> If you share the knowledge, it will be a lot of helpful to improve our Korean smart editor accessibility issues.
>
> Thank you.
> > > > >

--
@LeonieWatson tink.uk Carpe diem

From: Graham Armfield
Date: Wed, Jan 30 2019 7:20AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

Not sure if I've understood the situation fully, but if this works OK in
one language, but not in another language, maybe it's the absence of a
suitable lang attribute in the page, or locally in the content in question?

Also, does your screen reader have the necessary language 'packs' installed?

Regards
Graham Armfield

coolfields.co.uk <http://www.coolfields.co.uk/>;
M:07905 590026
T: 01483 856613
@coolfields <https://twitter.com/coolfields>

From: Jim Allan
Date: Wed, Jan 30 2019 8:00AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

Hello,
see https://hongkiat.github.io/html5-editable-content/ I tried it in Chrome
with NVDA and it works fine. Perhaps this will help.
can you send a link to the page you were taking about so we can try to
duplicate the problems you are having?

Jim

On Wed, Jan 30, 2019 at 7:20 AM 김형섭 < = EMAIL ADDRESS REMOVED = > wrote:

> Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> May I ask your help regarding smart editable content with accessibility
> issue?
> In Korea one company developed smart editor based on block navigation with
> contenteditable attribute.
> By the way, even if I type several lines within edit area, screen readers
> doesn’t detect any text.
> So in order to report this issue, I looked into Google Docs.
> Because if I give similar cases, I think they will get clue more easily.
> Of course Google Docs is not based on block navigation.
> But if screen reader support is disabled, it also doesn’t support screen
> reader that enable reads the text inside of editable area.
> So I supposed that if I find the difference markup with HTML OR JS between
> screen reader support is enabled or not, it will have a clue to report to
> our developers to solve this problem.
> But because Google docs source code is too complicated, I can’t find how
> difference between screen reader support is enabled and not.
> So below is my question.
> If screen readers, like NVDA, can’t read the contents of editable area,
> how to fix the problem that let screen readers enables the text?
> In Google Docs, why screen readers can’t detect text while screen reader
> support is disabled?
> If you share the knowledge, it will be a lot of helpful to improve our
> Korean smart editor accessibility issues.
>
> Thank you.
> > > > >


--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Jonathan Cohn
Date: Wed, Jan 30 2019 8:13AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

Is the screen reader not detecting the text, or is it not echoing while typing? I believe that Google Docs uses a live region to put phonetics of typed characters into so that typed characters are echoed. So after typing in content, can you review it with the arrow keys or word navigation?

> On Jan 30, 2019, at 8:20 AM, 김형섭 < = EMAIL ADDRESS REMOVED = > wrote:
>
> Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> May I ask your help regarding smart editable content with accessibility issue?
> In Korea one company developed smart editor based on block navigation with contenteditable attribute.
> By the way, even if I type several lines within edit area, screen readers doesn’t detect any text.
> So in order to report this issue, I looked into Google Docs.
> Because if I give similar cases, I think they will get clue more easily.
> Of course Google Docs is not based on block navigation.
> But if screen reader support is disabled, it also doesn’t support screen reader that enable reads the text inside of editable area.
> So I supposed that if I find the difference markup with HTML OR JS between screen reader support is enabled or not, it will have a clue to report to our developers to solve this problem.
> But because Google docs source code is too complicated, I can’t find how difference between screen reader support is enabled and not.
> So below is my question.
> If screen readers, like NVDA, can’t read the contents of editable area, how to fix the problem that let screen readers enables the text?
> In Google Docs, why screen readers can’t detect text while screen reader support is disabled?
> If you share the knowledge, it will be a lot of helpful to improve our Korean smart editor accessibility issues.
>
> Thank you.
> > > >

From:
Date: Wed, Jan 30 2019 9:06AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

If you were able to use the local copy of the editor you saved to your
PC, there must be something in the website where the editor is being
used that is causing the problem. Unfortunately, without access to it,
it's impossible to suggest any possible solutions, sorry.

The only thing I can suggest, is that you work with one of the
developers to try and isolate the problem.



If you saved the editor locally, then it must be something in the

Léonie.
On 30/01/2019 13:48, 김형섭 wrote:
> Thank you so much for your email.
>
> I tested with NVDA and JAWS with Chrome and Firefox with latest screen
> reader version.
>
> And I know that general content editable is read by screen readers.
>
> For example, in my wordpress hompage with Gutenberg, there is no problem
> to read.
>
> But in our Korean homepage smart editor with block navigation, even if
> there are many lines, screen readers say just blank.
>
> I really want to share the code, but I have no code, because I’m a
> accessibility tester.
>
> Also I saved the editor in my local PC, but the behavior is different.
>
> Of course if you cannot the original page, you might give me hard to
> advice, but if you have a guess and clue how to solve, please let me know.
>
> Thank you.
>
> *김형섭* / Hyongsop Kim
> *(주)엔비전스* / 웹접근성사업팀 팀장
>
> 서울시 종로구 가회동 1-29
> 1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
> *T.* +82 2 313 9977 *F.* +82 2 313 3645 *M.* +82 10 3316 5996
>
> http://dialogueinthedark.co.kr
> http://cafe.naver.com/dialogueinthedark
>
> 기업로고
>
> -----Original Message-----
> *From:* "Léonie Watson"< = EMAIL ADDRESS REMOVED = >
> *To:* "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >; "김형섭"
> < = EMAIL ADDRESS REMOVED = >;
> *Cc:*
> *Sent:* 2019-01-30 (수) 22:36:16
> *Subject:* Re: [WebAIM] A question about content editable attribute with
> screen readers in HTML
>
> Hello Hyongsop Kim.
>
> Can you share an example of your code?
>
> Screen readers should be able to read the contents of an element with
> contenteditable, but it will depend on which screen reader and browser
> you are using. Which screen readers and browsers are you testing with?
>
> Léonie.
>
>
>
> On 30/01/2019 13:20, 김형섭 wrote:
> > Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> > May I ask your help regarding smart editable content with
> accessibility issue?
> > In Korea one company developed smart editor based on block navigation
> with contenteditable attribute.
> > By the way, even if I type several lines within edit area, screen
> readers doesn’t detect any text.
> > So in order to report this issue, I looked into Google Docs.
> > Because if I give similar cases, I think they will get clue more easily.
> > Of course Google Docs is not based on block navigation.
> > But if screen reader support is disabled, it also doesn’t support
> screen reader that enable reads the text inside of editable area.
> > So I supposed that if I find the difference markup with HTML OR JS
> between screen reader support is enabled or not, it will have a clue to
> report to our developers to solve this problem.
> > But because Google docs source code is too complicated, I can’t find
> how difference between screen reader support is enabled and not.
> > So below is my question.
> > If screen readers, like NVDA, can’t read the contents of editable
> area, how to fix the problem that let screen readers enables the text?
> > In Google Docs, why screen readers can’t detect text while screen
> reader support is disabled?
> > If you share the knowledge, it will be a lot of helpful to improve
> our Korean smart editor accessibility issues.
> >
> > Thank you.
> > > > > > > > > >
>
> --
> @LeonieWatson tink.uk Carpe diem
>

--
@LeonieWatson tink.uk Carpe diem

From:
Date: Wed, Jan 30 2019 11:18AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

Thank you for your advice.
Lastly, could you explain me why screen readers can’t recognize editable text within google docs that screen reader support is not enabled?
It will give me a lot of clues.
And in case of codepen edit box or W3c school try it edit box, screen readers can’t read the editable text.

Thank you.

김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장

서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996

http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark


-----Original Message-----
From: "Léonie Watson"< = EMAIL ADDRESS REMOVED = >
To: "김형섭"< = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >;
Cc:
Sent: 2019-01-31 (목) 01:06:28
Subject: Re: [WebAIM] A question about content editable attribute with screen readers in HTML

If you were able to use the local copy of the editor you saved to your
PC, there must be something in the website where the editor is being
used that is causing the problem. Unfortunately, without access to it,
it's impossible to suggest any possible solutions, sorry.

The only thing I can suggest, is that you work with one of the
developers to try and isolate the problem.



If you saved the editor locally, then it must be something in the

Léonie.
On 30/01/2019 13:48, 김형섭 wrote:
> Thank you so much for your email.
>
> I tested with NVDA and JAWS with Chrome and Firefox with latest screen
> reader version.
>
> And I know that general content editable is read by screen readers.
>
> For example, in my wordpress hompage with Gutenberg, there is no problem
> to read.
>
> But in our Korean homepage smart editor with block navigation, even if
> there are many lines, screen readers say just blank.
>
> I really want to share the code, but I have no code, because I’m a
> accessibility tester.
>
> Also I saved the editor in my local PC, but the behavior is different.
>
> Of course if you cannot the original page, you might give me hard to
> advice, but if you have a guess and clue how to solve, please let me know.
>
> Thank you.
>
> *김형섭* / Hyongsop Kim
> *(주)엔비전스* / 웹접근성사업팀 팀장
>
> 서울시 종로구 가회동 1-29
> 1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
> *T.* +82 2 313 9977 *F.* +82 2 313 3645 *M.* +82 10 3316 5996
>
> http://dialogueinthedark.co.kr
> http://cafe.naver.com/dialogueinthedark
>
> 기업로고
>
> -----Original Message-----
> *From:* "Léonie Watson"< = EMAIL ADDRESS REMOVED = >
> *To:* "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >; "김형섭"
> < = EMAIL ADDRESS REMOVED = >;
> *Cc:*
> *Sent:* 2019-01-30 (수) 22:36:16
> *Subject:* Re: [WebAIM] A question about content editable attribute with
> screen readers in HTML
>
> Hello Hyongsop Kim.
>
> Can you share an example of your code?
>
> Screen readers should be able to read the contents of an element with
> contenteditable, but it will depend on which screen reader and browser
> you are using. Which screen readers and browsers are you testing with?
>
> Léonie.
>
>
>
> On 30/01/2019 13:20, 김형섭 wrote:
> > Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> > May I ask your help regarding smart editable content with
> accessibility issue?
> > In Korea one company developed smart editor based on block navigation
> with contenteditable attribute.
> > By the way, even if I type several lines within edit area, screen
> readers doesn’t detect any text.
> > So in order to report this issue, I looked into Google Docs.
> > Because if I give similar cases, I think they will get clue more easily.
> > Of course Google Docs is not based on block navigation.
> > But if screen reader support is disabled, it also doesn’t support
> screen reader that enable reads the text inside of editable area.
> > So I supposed that if I find the difference markup with HTML OR JS
> between screen reader support is enabled or not, it will have a clue to
> report to our developers to solve this problem.
> > But because Google docs source code is too complicated, I can’t find
> how difference between screen reader support is enabled and not.
> > So below is my question.
> > If screen readers, like NVDA, can’t read the contents of editable
> area, how to fix the problem that let screen readers enables the text?
> > In Google Docs, why screen readers can’t detect text while screen
> reader support is disabled?
> > If you share the knowledge, it will be a lot of helpful to improve
> our Korean smart editor accessibility issues.
> >
> > Thank you.
> > > > > > > > > >
>
> --
> @LeonieWatson tink.uk Carpe diem
>

--
@LeonieWatson tink.uk Carpe diem

From:
Date: Wed, Jan 30 2019 11:35AM
Subject: Re: A question about content editable attribute with screen readers in HTML
← Previous message | Next message →

And the answer of the another person’s question is after typing some lines, if I try to read the contents, it will just say blank.
And if Google docs produce live region contents for screen readers that let screen reader read the edited text, may I ask how difference between enable braille support or not?
As you know, in google docs has a option that enable braille or not.
Lastly, it is not the issue with my language pack with screen reader.
Because if I select all text and paste in notepad, it will read correctly.
Thank you.

김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장

서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996

http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark


-----Original Message-----
From: "김형섭"< = EMAIL ADDRESS REMOVED = >
To: < = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >;
Cc:
Sent: 2019-01-31 (목) 03:18:02
Subject: Re: [WebAIM] A question about content editable attribute with screen readers in HTML

Thank you for your advice.
Lastly, could you explain me why screen readers can’t recognize editable text within google docs that screen reader support is not enabled?
It will give me a lot of clues.
And in case of codepen edit box or W3c school try it edit box, screen readers can’t read the editable text.

Thank you.

김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장

서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996

http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark


-----Original Message-----
From: "Léonie Watson"< = EMAIL ADDRESS REMOVED = >
To: "김형섭"< = EMAIL ADDRESS REMOVED = >; "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >;
Cc:
Sent: 2019-01-31 (목) 01:06:28
Subject: Re: [WebAIM] A question about content editable attribute with screen readers in HTML

If you were able to use the local copy of the editor you saved to your
PC, there must be something in the website where the editor is being
used that is causing the problem. Unfortunately, without access to it,
it's impossible to suggest any possible solutions, sorry.

The only thing I can suggest, is that you work with one of the
developers to try and isolate the problem.



If you saved the editor locally, then it must be something in the

Léonie.
On 30/01/2019 13:48, 김형섭 wrote:
> Thank you so much for your email.
>
> I tested with NVDA and JAWS with Chrome and Firefox with latest screen
> reader version.
>
> And I know that general content editable is read by screen readers.
>
> For example, in my wordpress hompage with Gutenberg, there is no problem
> to read.
>
> But in our Korean homepage smart editor with block navigation, even if
> there are many lines, screen readers say just blank.
>
> I really want to share the code, but I have no code, because I’m a
> accessibility tester.
>
> Also I saved the editor in my local PC, but the behavior is different.
>
> Of course if you cannot the original page, you might give me hard to
> advice, but if you have a guess and clue how to solve, please let me know.
>
> Thank you.
>
> *김형섭* / Hyongsop Kim
> *(주)엔비전스* / 웹접근성사업팀 팀장
>
> 서울시 종로구 가회동 1-29
> 1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
> *T.* +82 2 313 9977 *F.* +82 2 313 3645 *M.* +82 10 3316 5996
>
> http://dialogueinthedark.co.kr
> http://cafe.naver.com/dialogueinthedark
>
> 기업로고
>
> -----Original Message-----
> *From:* "Léonie Watson"< = EMAIL ADDRESS REMOVED = >
> *To:* "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >; "김형섭"
> < = EMAIL ADDRESS REMOVED = >;
> *Cc:*
> *Sent:* 2019-01-30 (수) 22:36:16
> *Subject:* Re: [WebAIM] A question about content editable attribute with
> screen readers in HTML
>
> Hello Hyongsop Kim.
>
> Can you share an example of your code?
>
> Screen readers should be able to read the contents of an element with
> contenteditable, but it will depend on which screen reader and browser
> you are using. Which screen readers and browsers are you testing with?
>
> Léonie.
>
>
>
> On 30/01/2019 13:20, 김형섭 wrote:
> > Hello, I’m Hyongsop Kim in Korea and accessibility tester.
> > May I ask your help regarding smart editable content with
> accessibility issue?
> > In Korea one company developed smart editor based on block navigation
> with contenteditable attribute.
> > By the way, even if I type several lines within edit area, screen
> readers doesn’t detect any text.
> > So in order to report this issue, I looked into Google Docs.
> > Because if I give similar cases, I think they will get clue more easily.
> > Of course Google Docs is not based on block navigation.
> > But if screen reader support is disabled, it also doesn’t support
> screen reader that enable reads the text inside of editable area.
> > So I supposed that if I find the difference markup with HTML OR JS
> between screen reader support is enabled or not, it will have a clue to
> report to our developers to solve this problem.
> > But because Google docs source code is too complicated, I can’t find
> how difference between screen reader support is enabled and not.
> > So below is my question.
> > If screen readers, like NVDA, can’t read the contents of editable
> area, how to fix the problem that let screen readers enables the text?
> > In Google Docs, why screen readers can’t detect text while screen
> reader support is disabled?
> > If you share the knowledge, it will be a lot of helpful to improve
> our Korean smart editor accessibility issues.
> >
> > Thank you.
> > > > > > > > > >
>
> --
> @LeonieWatson tink.uk Carpe diem
>

--
@LeonieWatson tink.uk Carpe diem

From:
Date: Mon, Feb 11 2019 7:58PM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

Hello, I’m Hyongsop Kim in Korea and screen reader user.
May I ask your help regarding chrome devTools undock function?
Because I’m testing many accessibility issues with my screen readers, such as NVDA or JAWS, I have to use chrome devTools.
By the way, if I open devTools, it opens in same window, not separated.
So in case of screen reader users’ perspective, it is hard to check between original web page and source viewer, because it is not window separated.
So I want to undock devTools, but I don’t know how to do.
Could you help me how to solve this?
Of course I’m screen reader user, so I have to use just keyboard, not mouse.

Thank you so much.

From: Steve Green
Date: Mon, Feb 11 2019 9:39PM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

I have spent about half an hour trying to find a way to do it and I don't think it is possible. By tabbing around the dev tools you will probably have found the Customise and Control Dev Tools button. This opens a dropdown menu that contains the controls for undocking the dev tools panel.

If you operate the button, JAWS will go into forms mode and say "Menu, to navigate press up or down arrow". The virtual focus is actually on the docking controls but you can't interact with them in forms mode. If you use the up and down arrow keys, JAWS navigates between all the other options in the menu except the docking controls.

The following steps will allow you to identify where the docking controls are:

1. Immediately after opening the dropdown menu, press the plus key on the NumPad to exit forms mode and leave the dropdown menu open. Don't press the Escape key to exit forms mode because this closes the dropdown menu.
2. Press the down arrow key. JAWS will announce the Show Console Drawer option, which is the second one in the list.
3. Press the up arrow key. JAWS will announce the four docking controls as a single string. It actually says "Dock side undock into separate window dock to left dock to bottom doc to right".

Now that you know where the docking controls are, you would expect to be able to use the JAWS cursor to find and operate them. However, I cannot find a way to do that. After pressing the minus key on the NumPad to change to the JAWS cursor, I can use the arrow keys to move the cursor to almost anywhere in the dev tools except where the docking controls are.

It looks like you are going to need sighted help to do this. The good news is that the setting is persistent so you will only need help once on each machine you use.

Steve Green
Managing Director
Test Partners Ltd



-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of ???
Sent: 12 February 2019 02:59
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] A question about chrome devTool undock function for screen reader user

Hello, I’m Hyongsop Kim in Korea and screen reader user.
May I ask your help regarding chrome devTools undock function?
Because I’m testing many accessibility issues with my screen readers, such as NVDA or JAWS, I have to use chrome devTools.
By the way, if I open devTools, it opens in same window, not separated.
So in case of screen reader users’ perspective, it is hard to check between original web page and source viewer, because it is not window separated.
So I want to undock devTools, but I don’t know how to do.
Could you help me how to solve this?
Of course I’m screen reader user, so I have to use just keyboard, not mouse.

Thank you so much.

From:
Date: Mon, Feb 11 2019 10:52PM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

Thank you so much for your guide.
Because of your explanation, I solved the issue.
With NVDA, once I pressed dropdown menu, turned on browse mode through NVDA key plus space, and I could find docking option and it could be activated with browse mode.
Thank you again for your help and spending time.
I hope google chrome team will solve the accessibility issue.
Have a nice day.

김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장

서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996

http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark


-----Original Message-----
From: "Steve Green"< = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >;
Cc:
Sent: 2019-02-12 (화) 13:39:43
Subject: Re: [WebAIM] A question about chrome devTool undock function for screen reader user

I have spent about half an hour trying to find a way to do it and I don't think it is possible. By tabbing around the dev tools you will probably have found the Customise and Control Dev Tools button. This opens a dropdown menu that contains the controls for undocking the dev tools panel.

If you operate the button, JAWS will go into forms mode and say "Menu, to navigate press up or down arrow". The virtual focus is actually on the docking controls but you can't interact with them in forms mode. If you use the up and down arrow keys, JAWS navigates between all the other options in the menu except the docking controls.

The following steps will allow you to identify where the docking controls are:

1. Immediately after opening the dropdown menu, press the plus key on the NumPad to exit forms mode and leave the dropdown menu open. Don't press the Escape key to exit forms mode because this closes the dropdown menu.
2. Press the down arrow key. JAWS will announce the Show Console Drawer option, which is the second one in the list.
3. Press the up arrow key. JAWS will announce the four docking controls as a single string. It actually says "Dock side undock into separate window dock to left dock to bottom doc to right".

Now that you know where the docking controls are, you would expect to be able to use the JAWS cursor to find and operate them. However, I cannot find a way to do that. After pressing the minus key on the NumPad to change to the JAWS cursor, I can use the arrow keys to move the cursor to almost anywhere in the dev tools except where the docking controls are.

It looks like you are going to need sighted help to do this. The good news is that the setting is persistent so you will only need help once on each machine you use.

Steve Green
Managing Director
Test Partners Ltd



-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of ???
Sent: 12 February 2019 02:59
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] A question about chrome devTool undock function for screen reader user

Hello, I’m Hyongsop Kim in Korea and screen reader user.
May I ask your help regarding chrome devTools undock function?
Because I’m testing many accessibility issues with my screen readers, such as NVDA or JAWS, I have to use chrome devTools.
By the way, if I open devTools, it opens in same window, not separated.
So in case of screen reader users’ perspective, it is hard to check between original web page and source viewer, because it is not window separated.
So I want to undock devTools, but I don’t know how to do.
Could you help me how to solve this?
Of course I’m screen reader user, so I have to use just keyboard, not mouse.

Thank you so much.

From: glen walker
Date: Tue, Feb 12 2019 12:36AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

If you open devtools and it's docked, you can use the shortcut ctrl+shift+D
to undock it, which opens the devtools in a separate window. You have to
use that shortcut in the devtools panel after it's opened. If you try it
in chrome without devtools opened, it doesn't do anything. And as Steve
said, once you undock it, the setting is remembered. If you want to
re-dock it, just make sure the devtools window is active and hit
ctrl+shift+D again.

Glen

From:
Date: Tue, Feb 12 2019 12:43AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

Thank you for your advice.
By the way, in fact, I found the keyboard shortcut key, ctrl plus shift plus d in devTools window.
I tried it, but no work.
So as I said, in prior email, I resolved through NVDA browse mode, within customize toolbar.
Thank you again.

김형섭 / Hyongsop Kim
(주)엔비전스 / 웹접근성사업팀 팀장

서울시 종로구 가회동 1-29
1-29 Gahoe-dong, Jongno-gu, Seoul, Korea
T. +82 2 313 9977 F. +82 2 313 3645 M. +82 10 3316 5996

http://dialogueinthedark.co.kr
http://cafe.naver.com/dialogueinthedark


-----Original Message-----
From: "glen walker"< = EMAIL ADDRESS REMOVED = >
To: "WebAIM Discussion List"< = EMAIL ADDRESS REMOVED = >;
Cc:
Sent: 2019-02-12 (화) 16:36:55
Subject: Re: [WebAIM] A question about chrome devTool undock function for screen reader user

If you open devtools and it's docked, you can use the shortcut ctrl+shift+D
to undock it, which opens the devtools in a separate window. You have to
use that shortcut in the devtools panel after it's opened. If you try it
in chrome without devtools opened, it doesn't do anything. And as Steve
said, once you undock it, the setting is remembered. If you want to
re-dock it, just make sure the devtools window is active and hit
ctrl+shift+D again.

Glen

From: glen walker
Date: Tue, Feb 12 2019 1:07AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

I just tried it and it worked fine. I had NVDA running instead of JAWS so
perhaps that's the difference, although that would be weird.

I hit F12 first, to open devtools, then ctrl+shit+D and it undocked the
devtools.

From: Jim Allan
Date: Tue, Feb 12 2019 8:32AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

open devtools
ctrl+shift+p (opens command menu) all controls for devtools are in this menu
type "un" fuzzy search highlights "undock into a separate window"
hit enter.


On Tue, Feb 12, 2019 at 2:07 AM glen walker < = EMAIL ADDRESS REMOVED = > wrote:

> I just tried it and it worked fine. I had NVDA running instead of JAWS so
> perhaps that's the difference, although that would be weird.
>
> I hit F12 first, to open devtools, then ctrl+shit+D and it undocked the
> devtools.
> > > > >


--
Jim Allan, Accessibility Coordinator
Texas School for the Blind and Visually Impaired
1100 W. 45th St., Austin, Texas 78756
voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/
"We shape our tools and thereafter our tools shape us." McLuhan, 1964

From: Reinhard Stebner
Date: Tue, Feb 12 2019 9:59AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

This keyboard shortcut did the trick. Thanks for this.

On 2/12/19, Jim Allan < = EMAIL ADDRESS REMOVED = > wrote:
> open devtools
> ctrl+shift+p (opens command menu) all controls for devtools are in this
> menu
> type "un" fuzzy search highlights "undock into a separate window"
> hit enter.
>
>
> On Tue, Feb 12, 2019 at 2:07 AM glen walker < = EMAIL ADDRESS REMOVED = > wrote:
>
>> I just tried it and it worked fine. I had NVDA running instead of JAWS
>> so
>> perhaps that's the difference, although that would be weird.
>>
>> I hit F12 first, to open devtools, then ctrl+shit+D and it undocked the
>> devtools.
>> >> >> >> >>
>
>
> --
> Jim Allan, Accessibility Coordinator
> Texas School for the Blind and Visually Impaired
> 1100 W. 45th St., Austin, Texas 78756
> voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/
> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
> > > > >

From: Birkir R. Gunnarsson
Date: Wed, Feb 13 2019 12:50AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

On a slightly related question, do you guys know how to reorder the
tabs in chrome?
I want the aXe tab to show up first, or at least as close to the start
of the tabs as possible (the only way to activate it that I have found
is to open dev tools, locate the tabs at the top and repeatedly press
ctrl-] to move to the next tab, unfortunately this is a slow process
since opening at least some of the tabs automatically shifts focus
away from the tabs into the tab panel and you have to arrow back up to
the tabs area before pressing ctrl-] again).


On 2/12/19, Reinhard Stebner < = EMAIL ADDRESS REMOVED = > wrote:
> This keyboard shortcut did the trick. Thanks for this.
>
> On 2/12/19, Jim Allan < = EMAIL ADDRESS REMOVED = > wrote:
>> open devtools
>> ctrl+shift+p (opens command menu) all controls for devtools are in this
>> menu
>> type "un" fuzzy search highlights "undock into a separate window"
>> hit enter.
>>
>>
>> On Tue, Feb 12, 2019 at 2:07 AM glen walker < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> I just tried it and it worked fine. I had NVDA running instead of JAWS
>>> so
>>> perhaps that's the difference, although that would be weird.
>>>
>>> I hit F12 first, to open devtools, then ctrl+shit+D and it undocked the
>>> devtools.
>>> >>> >>> >>> >>>
>>
>>
>> --
>> Jim Allan, Accessibility Coordinator
>> Texas School for the Blind and Visually Impaired
>> 1100 W. 45th St., Austin, Texas 78756
>> voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/
>> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>> >> >> >> >>
> > > > >


--
Work hard. Have fun. Make history.

From: glen walker
Date: Wed, Feb 13 2019 8:00AM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | Next message →

I've moved the tabs in devtools around before (not with the keyboard) but
the tab order is not persisted. I just tried it again to make sure. I
moved aXe right after "elements", hit f12 to close the devtools, then f12
again to open devtools. The order was retained (yay). I then closed and
opened devtools again and the order went back to the original (boo). I was
going to poke around the chrome config files to see if it's in there
somewhere (seems like it might be if the order was persisted once). The
issue of non-persistence could be because of another plugin that is messing
things up so I'll try this again with plugins disabled. (In my devtools I
have "audits", "chromelens", "walnut", "adblock", and "aXe")

On Wed, Feb 13, 2019 at 12:50 AM Birkir R. Gunnarsson <
= EMAIL ADDRESS REMOVED = > wrote:

> On a slightly related question, do you guys know how to reorder the
> tabs in chrome?
>
>

From: mhysnm1964@gmail.com
Date: Wed, Feb 13 2019 8:51PM
Subject: Re: A question about chrome devTool undock function for screen reader user
← Previous message | No next message

This should be raised as an accessibility bug with Google. AS if you are in
a tab strip, focus should stay there unless you decide to move it.


-----Original Message-----
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > On Behalf Of
Birkir R. Gunnarsson
Sent: Wednesday, 13 February 2019 6:51 PM
To: WebAIM Discussion List < = EMAIL ADDRESS REMOVED = >
Subject: Re: [WebAIM] A question about chrome devTool undock function for
screen reader user

On a slightly related question, do you guys know how to reorder the tabs in
chrome?
I want the aXe tab to show up first, or at least as close to the start of
the tabs as possible (the only way to activate it that I have found is to
open dev tools, locate the tabs at the top and repeatedly press ctrl-] to
move to the next tab, unfortunately this is a slow process since opening at
least some of the tabs automatically shifts focus away from the tabs into
the tab panel and you have to arrow back up to the tabs area before pressing
ctrl-] again).


On 2/12/19, Reinhard Stebner < = EMAIL ADDRESS REMOVED = > wrote:
> This keyboard shortcut did the trick. Thanks for this.
>
> On 2/12/19, Jim Allan < = EMAIL ADDRESS REMOVED = > wrote:
>> open devtools
>> ctrl+shift+p (opens command menu) all controls for devtools are in
>> ctrl+shift+this
>> menu
>> type "un" fuzzy search highlights "undock into a separate window"
>> hit enter.
>>
>>
>> On Tue, Feb 12, 2019 at 2:07 AM glen walker < = EMAIL ADDRESS REMOVED = >
>> wrote:
>>
>>> I just tried it and it worked fine. I had NVDA running instead of
>>> JAWS so perhaps that's the difference, although that would be weird.
>>>
>>> I hit F12 first, to open devtools, then ctrl+shit+D and it undocked
>>> the devtools.
>>> >>> >>> archives at http://webaim.org/discussion/archives
>>> >>>
>>
>>
>> --
>> Jim Allan, Accessibility Coordinator
>> Texas School for the Blind and Visually Impaired
>> 1100 W. 45th St., Austin, Texas 78756
>> voice 512.206.9315 fax: 512.206.9452 http://www.tsbvi.edu/
>> "We shape our tools and thereafter our tools shape us." McLuhan, 1964
>> >> >> archives at http://webaim.org/discussion/archives
>> >>
> > > archives at http://webaim.org/discussion/archives
> >


--
Work hard. Have fun. Make history.
http://webaim.org/discussion/archives