We need to update this list as many things have changed:

> General
>  - Can't access QS panel in shelf with CV

What is 'QS'? I think Shelf looks fully accessible now.


> Welcome Page
>  - Main image needs descriptive label or no label
>  - No default focus (announce heading)

Main image is not focusable, so I guess it does not need any label.

Default focus was implemented some time ago and looks correct.

> 
> Accessibility Page
>  - Buttons should have a11y labels: when TABing onto them, CV just reads
> "Button, (not) pressed".

Fixed.

> Language
>  - Pressing enter does not exit list item with CV (Menus don't close when
> focus leaves the list.  In fact, you can TAB to the other list, open it
> with an arrow key, close it with an ESC, and the other list is STILL open.)

I cannot reproduce this, I guess it was ChromeVox issue.

> Network
> - Need CV alert when "connecting"

This sounds complicate, so I filed a separate issue 700647 for this.

I am going to close this as fixed, let's reopen of file a different issue on "QS".

I did a quick test of these screens on 59.0.3041.0.  All the original issues seem to be fixed.  Since this seems to be a catch-all issue for minor MD-OOBE a11y bugs, here's what else I've observed:

1. On the Welcome screen, default focus is on language button.  I don't know if this is deliberate, but it seems (to me) that focus on "Let's go" would make more sense, since the majority of Chromebook users are US and not using a11y features.  As a developer who frequently starts on blank devices / wipes my local data folder, I know it would be preferable to have it here so I can move forward with a single key stroke.  But if there's a half-decent reason for focusing the language button, that's fine.

2. Switching languages silences CV.  Usually (although not every time), when I switch languages, CV appears to reset.  When it does, it no longer speaks, although the orange CV highlights still work.  This may be an issue with CV itself, and not something that can be fixed in OOBE code.  Stopping and starting CV fixes it.

3. The "System security setting" dialog is not modal, even within OOBE.  When it appears, OK button has focus (correct).  Now press TAB repeatedly.  Focus moves SysTray -> Terms textbox -> "System security setting" link -> [other OOBE page elements].  For example, you can TAB onto and ENTER the Back button.  OOBE goes back to Network page, but dialog is still present.

4. CV can't read the content of the "System security setting" dialog.  The text is static, so you can't TAB to it (which is fine).  But CV navigation can't seem to get to it either.  When OK button is focused, and I press Search+arrow (any), CV bounces back onto and reads OK button.  Left and Up arrows look like they're trying to access the TPM password, but it bounces right back to OK instead.

5. Default focus on Terms page is on the big Terms textbox.  This may be deliberate; maybe we don't want default focus on "Accept and continue" (i) to make it a little harder to accept the terms (just as some terms dialogs are unchecked by default), or (ii) to start focus on content for the benefit of CV users.  However,  as in #1 above, it's a little tedious to speed through.  If it hasn't been already, we should at least consider having the Accept and Continue (i.e. OK / Next) button be the default.  (Note that default focus on the network list makes sense on that page, since the user can't move forward until that selection is made.)

For what it's worth, I don't consider any of these a11y blockers, except probably #4 (#1 and #5 are really just suggestions), but lpalmaro@ should make the final call on them.

Thanks, Greg! Some thoughts inline. 

1. On the Welcome screen, default focus is on language button.  I don't know if this is deliberate, but it seems (to me) that focus on "Let's go" would make more sense, since the majority of Chromebook users are US and not using a11y features.  As a developer who frequently starts on blank devices / wipes my local data folder, I know it would be preferable to have it here so I can move forward with a single key stroke.  But if there's a half-decent reason for focusing the language button, that's fine.

>> that makes sense to me 

2. Switching languages silences CV.  Usually (although not every time), when I switch languages, CV appears to reset.  When it does, it no longer speaks, although the orange CV highlights still work.  This may be an issue with CV itself, and not something that can be fixed in OOBE code.  Stopping and starting CV fixes it.

>> strange -- we should definitely look into this further.

3. The "System security setting" dialog is not modal, even within OOBE.  When it appears, OK button has focus (correct).  Now press TAB repeatedly.  Focus moves SysTray -> Terms textbox -> "System security setting" link -> [other OOBE page elements].  For example, you can TAB onto and ENTER the Back button.  OOBE goes back to Network page, but dialog is still present.

>> Does the user *have* to take action on this dialog before moving forward? If so, we should make it modal and make the user take action and then move forward. 

4. CV can't read the content of the "System security setting" dialog.  The text is static, so you can't TAB to it (which is fine).  But CV navigation can't seem to get to it either.  When OK button is focused, and I press Search+arrow (any), CV bounces back onto and reads OK button.  Left and Up arrows look like they're trying to access the TPM password, but it bounces right back to OK instead.

>> also strange, and we should look into this further 

5. Default focus on Terms page is on the big Terms textbox.  This may be deliberate; maybe we don't want default focus on "Accept and continue" (i) to make it a little harder to accept the terms (just as some terms dialogs are unchecked by default), or (ii) to start focus on content for the benefit of CV users.  However,  as in #1 above, it's a little tedious to speed through.  If it hasn't been already, we should at least consider having the Accept and Continue (i.e. OK / Next) button be the default.  (Note that default focus on the network list makes sense on that page, since the user can't move forward until that selection is made.)

>> Zach, any issues with putting the default on the accept and continue? Or does this bring up issues since we want to ensure that people have fully read the terms before accepting? 

For what it's worth, I don't consider any of these a11y blockers, except probably #4 (#1 and #5 are really just suggestions), but lpalmaro@ should make the final call on them.

>> I agree, #4 should be fixed before launch. And #2 should be prioritized as well, but that might be on our team's end. The others are really good suggestions that should be implemented, but I wouldn't consider them blocking. Who would be able to own #4 and #2 to begin? 

>>> RE: 3. The "System security setting" dialog is not modal [...]
>> 
>> Does the user *have* to take action on this dialog before moving forward? If so, we should make it modal and make the user take
>> action and then move forward.

I'm not sure what the use case is for this dialog and the TPM password, but I believe most users would never need to open it.  Also, there is no action to be taken in the dialog (except dismissing it with "OK"); it is purely informational.  However, once the dialog has been opened, it can only be dismissed by pressing "OK" (Issue 693374 would allow ESC key to close it also).  Until it is closed, everything else on the screen is dimmed, and the dialog blocks most of it.  Allowing the user to do other things (go back to Network page, or even go forward to log in) seems harmless, I guess; it's just a weird experience.  If they open the dialog, they should have to close it before doing anything else.  See attached screenshot where I've TAB'ed onto "Accept and continue", and proceeded to login screen, with dialog still blocking it.

>> Who would be able to own #4 and #2 to begin?

For #4, I would think alemate@ could change the HTML of the dialog to make it CV accessible.
For #2... I just tried to reproduce it on a device, and couldn't.  So it may just be an issue with the Linux desktop version of Chrome OS (which can be a little flaky).  Unless someone can repro this on a device, I wouldn't worry about it.

Deleted: dialog_blocking_login.png 60.1 KB

	dialog_blocking_login.png 60.1 KB View Download

Greg, these two dialogs are native UI dialogs. We will replace them with WebUI but it won't happen now.

ChromeVoX is usually capable of navigating through native UI and I don't know what is broken there. But these dialogs have been there for many years.

#2 looks like a known bug (which is sometimes fixed and happens again) when you cannot use ChromeVoX on a device if you deployed Chrome using simple Chrome workflow.

The problem seems to be the 'focusout' listener in oobe_screen_eula.js:
https://cs.chromium.org/chromium/src/chrome/browser/resources/chromeos/login/oobe_screen_eula.js?type=cs&q=%22addEventListener(%27focusout%27%22&l=31

I assume in the past, this function actually fixed the "modal" problem (#3 in Comment 5 above).  Now it's (a) not solving that problem, and (b) preventing CV from highlighting text in this dialog.

(a) For whatever reason, this function doesn't prevent TAB from moving focus from the OK button to the SysTray.  It does prevent SHIFT+TAB from moving focus back on the "Shut down" button (weirdly, the OK button is between these two shelf items in the TAB order).

(b) The function *does* block CV navigation from moving off the OK button.  Deleting this function allows CV to work as expected.

If the function can't be fixed or replaced with something that (i) makes the dialog modal, and (ii) allows CV to work properly within the dialog, then it should just be removed, since at the moment, it's doing a lot of harm and very little good.

Alexander, can you remove this function if Greg's assessment is correct?
Then let's remove blocking on 621719 and add to Hotlist-auth-polish.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/f9baf94fc70de8725932d3421fafa85db3d3cfbf

commit f9baf94fc70de8725932d3421fafa85db3d3cfbf
Author: glevin <glevin@chromium.org>
Date: Thu Mar 30 21:54:27 2017

Remove broken focusout listener for System Security Setting OOBE dialog

BUG= 690726 
TEST=In new MD OOBE, advance to Chrome OS Terms page, click "System
security setting".  Turn on ChromeVox, check that CV nav keys can
highlight and read dialog contents.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2787033002
Cr-Commit-Position: refs/heads/master@{#460899}

[modify] https://crrev.com/f9baf94fc70de8725932d3421fafa85db3d3cfbf/chrome/browser/resources/chromeos/login/oobe_screen_eula.js

Your change meets the bar and is auto-approved for M58. Please go ahead and merge the CL to branch 3029 manually. Please contact milestone owner if you have questions.
Owners: amineer@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/fb6bae85ee85e1888233a8dcae61bc510c3d84b3

commit fb6bae85ee85e1888233a8dcae61bc510c3d84b3
Author: glevin <glevin@chromium.org>
Date: Sun Apr 02 22:21:18 2017

Remove broken focusout listener for System Security Setting OOBE dialog

BUG= 690726 
TEST=In new MD OOBE, advance to Chrome OS Terms page, click "System
security setting".  Turn on ChromeVox, check that CV nav keys can
highlight and read dialog contents.
CQ_INCLUDE_TRYBOTS=master.tryserver.chromium.linux:closure_compilation

Review-Url: https://codereview.chromium.org/2787033002
Cr-Commit-Position: refs/heads/master@{#460899}
(cherry picked from commit f9baf94fc70de8725932d3421fafa85db3d3cfbf)

Review-Url: https://codereview.chromium.org/2791113002 .
Cr-Commit-Position: refs/branch-heads/3029@{#533}
Cr-Branched-From: 939b32ee5ba05c396eef3fd992822fcca9a2e262-refs/heads/master@{#454471}

[modify] https://crrev.com/fb6bae85ee85e1888233a8dcae61bc510c3d84b3/chrome/browser/resources/chromeos/login/oobe_screen_eula.js

Of the 5 issues raised in Comment #5:

4. was the only blocker, and was fixed by CLs above.
1. & 5. are refiled as  Issue 707939  (default focus).
3. is refiled as Issue 707955 (modality of dialog).
2. wouldn't repro on a device, so probably isn't a concern.

Nothing left to do here, so closing bug.

As per #18