Thanks for filing the issue!

Tried testing the issue on reported chrome version 69.0.3497.81 using Windows 10 with the below mentioned steps.
1. Launched Chrome
2. Enabled NVDA -> Navigated to a random webpage
We observed that the content is being read by NVDA, without any issues.

@Reporter: As we are not very sure about the point no.3 in comment#0, could you please elaborate on it. Does "Accessibility features should be automatically enabled" means the Screen-reader should read the content? Any further inputs from your end may be helpful.

I don't have details on exactly what NVDA is doing, so I can't comment on what further steps they may have taken to force Chrome to enable accessibility features. Working from a minimal test case just following the documented system for allowing Chrome to detect a screen-reader that I mentioned in the report, it does not work.

To elaborate as requested, when Chrome detects a screen reader it should enable the "Native accessibility API support" and "Web accessibility" Accessibility features as shown on "chrome://accessibility". Whether the screen reader then actually reads the content or not is outside Chrome's control, but without those checkboxes enabled a screen reader cannot read the content even if it wants to.

The bug is that, prior to 69, following the documented detection mechanism, those accessibility checkboxes would be automatically enabled. In 69, they are not.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Unable to reproduce the issue on reported chrome version 69.0.3497.81 using Windows 10 with the below mentioned steps.
1. Launched chrome
2. Enabled NVDA
3. Navigated to chrome://accessibility
Observed that "Native accessibility API support" and "Web accessibility" are enabled i.e., checked. Attaching the screen cast of the same for reference.

@Reporter: Could you please have a look at the screen cast and let us know if we have missed anything in the process. Requesting you to check the same on a new profile without any apps & extensions and let us know if the issue still persists.

Deleted: 881753.mp4 1.5 MB

	881753.mp4 1.5 MB View Download

As I mentioned before, I can't comment on what NVDA is doing.

I have attached a minimal implementation of the documented (http://dev.chromium.org/developers/design-documents/accessibility#TOC-API-support) mechanism for being detected by Chrome as a screen-reader. With this running, Chrome 68 enables the accessibility checkboxes, Chrome 69 does not.

Deleted: ChromeAccessibilityTest.cs 1.5 KB

ChromeAccessibilityTest.cs 1.5 KB View Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

@Reporter: As we do not have setup to test .cs file(s), could you please help us by providing a .exe/.html file which helps to triage this further in a better way.

Requesting someone from "UI>Accessibility>Compatibility" team to have a look into this and help us further.

Thanks!

Sure, I figured a .cs would be more acceptable than a .exe, but here's the compiled version.

Deleted: ChromeAccessibilityTest.exe 8.0 KB

ChromeAccessibilityTest.exe 8.0 KB Download

Thank you for providing more feedback. Adding the requester to the cc list.

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

We've encountered the same issue. In addition after reading this https://bugs.chromium.org/p/chromium/issues/detail?id=881753&can=1&q=accessibility&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified


The first solution we've tried is calling get_accName right afer sending the event SendMessage(hwnd, WM_GETOBJECT, 0, 1); with no efect though. Here is the code snippet we've used


SendMessage(hwnd, WM_GETOBJECT, 0, 1);

IAccessible *pAcc;
CreateStdAccessibleObject(hwnd, OBJID_CLIENT, IID_IAccessible, (void **)&pAcc);
if (pAcc == NULL)
	return false;

BSTR bstrName;
VARIANT varChild;
varChild.vt = VT_I4;
varChild.lVal = CHILDID_SELF;
HRESULT hr = pAcc->get_accName(varChild, &bstrName);
printf("Name: %S ", bstrName);
SysFreeString(bstrName);


The second solution was calling QueryService with IID_IAccessible2, but the call allways returns E_INVALIDARGS.



SendMessage(hwnd, WM_GETOBJECT, 0, 1);

IAccessible *pIA;
HRESULT hr = AccessibleObjectFromWindow(hwnd, OBJID_CLIENT, IID_IAccessible, (void**)&pIA);
if (!SUCCEEDED(hr))
	return false;

const IID IID_IAccessible2 = { 0xE89F726E, 0xC4F4, 0x4c19, 0xbb, 0x19, 0xb6, 0x47, 0xd7, 0xfa, 0x84, 0x78 };
::IServiceProvider *pService = NULL;
hr = pIA->QueryInterface(IID_IServiceProvider, (void **)&pService);
if (SUCCEEDED(hr))
{
	IAccessible2 *pIA2 = NULL;
	hr = pService->QueryService(IID_IAccessible, IID_IAccessible2, (void**)&pIA2);
	if (SUCCEEDED(hr) && pIA2)
	{
		// this always fails with E_INVALIDARG
		pIA2->Release();
	}
	pService->Release();
}

Tried testing the issue with the '.exe' file provided in comment# 9, on launching the file Command Prompt got opened and we didn't find anything to test and confirm the issue.

@Reporter: If possible could you please provide screencast of the issue which helps us in understanding it and triaging in better way.

Thanks!

The repro tests are:

1. Run Chrome 68, verify that chrome://accessibility "Native accessibility API support" and "Web accessibility" checkboxes are unchecked.
2. Run the ChromeAccessibilityTest.exe, then run Chrome 68, verify that the checkboxes are now checked.
3. Run Chrome 69, verify that checkboxes are unchecked.
4. Run the ChromeAccessibilityTest.exe, then run Chrome 69, observe that the checkboxes are *not* now checked, and they should be.

Thank you for providing more feedback. Adding the requester to the cc list.

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

Sorry this got bounced around a lot.

I'm the right owner and point of contact for this issue.

To alexvallat@gmail.com, could you explain more about what your application does and what it uses accessibility APIs for?

We deliberately tried to cut down on enabling accessibility due to some serious abuse. I'll be happy to help you figure out a good workaround but long-term I'd like to better understand the purpose and make sure we can meet your needs.

Thanks.

Primarily, my application uses the accessibility APIs to determine the URL of the page with the active keyboard focus. Secondarily, it detects whether the focussed element is a password input box or not. The application will work without this secondary functionality, but can offer additional user convenience if it can.

The application is a plugin to the KeePass password manager called WebAutoType which allows KeePass to determine which password to use based on the URL of the page.

I would be happy to fix my application to use whatever the new way to identify to Chrome as an application that requires accessibility features is, if the documentation is updated to reflect it. Unless the requirement is "be NVDA", which of course I cannot comply with.

Or, if it is Chrome's policy to no longer automatically enable accessibility features when third party applications request it, is that documented anywhere so I can provide a link to my users explaining why, if they want to use Chrome, they have to manually enable accessibility from v69?

This is really helpful information.

First, you should always be able to access the url in the omnibox. It's always accessible and should be easy to identify. Maybe consider looking there?

Determining if the focused element is a password field is pretty reasonable, but unfortunately right now it's pretty inefficient. I'd like to work on making it more efficient.

Please try the latest Chrome Canary, it should be working with your app again without any changes on your part. Let me know.

Thanks, I can confirm that Chrome Canary appears to be working again now.

Yes, I can fall back to using the omnibox, but this has a couple of major disadvantages. Firstly, it does not include the http:// or https:// part of the url (and, I believe, may elide other initial parts of the url under certain circumstances). Secondly, it is not necessarily the URL for the frame with the focused input box. This can sometimes be an issue if the login page is embedded in a frame within another site.

Determining if the input element is a password box can be tricky currently, yes! Ideally it would just be a case of AutomationElement.FocusedElement.GetCurrentPropertyValue(AutomationElement.IsPasswordProperty), but I've had to add special-case code for Chrome not actually returning the input element from AutomationElement.FocusedElement.

If you are interested, the logic I use is:
1. Get the focused element. If it is not an Edit control, and it has the KeyboardFocus property set false, then attempt refocusing:
2. Add a focus change event handler, and force a focus change by bringing another invisible window (very briefly) to the foreground and then dismissing it.
3. In the event handler, check the source element. This will be the actual input element, and the IsPassword property can be read from it.
4. Remove the handler