Skip to content
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

Update UIA aria-readonly mappings #203

Merged
merged 2 commits into from
Oct 31, 2023
Merged
Changes from 1 commit
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
8 changes: 6 additions & 2 deletions index.html
Original file line number Diff line number Diff line change
Expand Up @@ -7486,7 +7486,9 @@ <h4 id=ariaReadonlyTrue><code>aria-readonly</code>=<code>true</code></h4>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Property: <code>Value.IsReadOnly</code>: <code>true</code></span>
<span class="property">Property: <code>Value.IsReadOnly</code>: <code>true</code>, if the element implements <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.ivalueprovider?view=windowsdesktop-7.0"><code>IValueProvider</code></a>.</span><br>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: Can we remove the "?view=windowsdesktop-7.0" parameters from the URLs? I counted 8 instances.

<span class="property">Property: <code>RangeValue.IsReadOnly</code>: <code>true</code>, if the element implements <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.irangevalueprovider?view=windowsdesktop-7.0"><code>IRangeValueProvider</code></a>.</span><br>
<span class="property">Property: <code>AriaProperties.readonly</code>: <code>true</code>, if the element implements neither <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.ivalueprovider?view=windowsdesktop-7.0"><code>IValueProvider</code></a> or <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.irangevalueprovider?view=windowsdesktop-7.0"><code>IRangeValueProvider</code></a>.</span>
</td>
</tr>
<tr>
Expand Down Expand Up @@ -7525,7 +7527,9 @@ <h4 id=ariaReadonlyFalse><code>aria-readonly</code>=<code>false</code></h4>
<tr>
<th><abbr title="User Interface Automation">UIA</abbr></th>
<td>
<span class="property">Property: <code>Value.IsReadOnly</code>: <code>false</code></span>
<span class="property">Property: <code>Value.IsReadOnly</code>: <code>false</code>, if the element implements <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.ivalueprovider?view=windowsdesktop-7.0"><code>IValueProvider</code></a>.</span><br>
<span class="property">Property: <code>RangeValue.IsReadOnly</code>: <code>false</code>, if the element implements <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.irangevalueprovider?view=windowsdesktop-7.0"><code>IRangeValueProvider</code></a>.</span><br>
<span class="property">Property: <code>AriaProperties.readonly</code>: <code>false</code>, if the element implements neither <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.ivalueprovider?view=windowsdesktop-7.0"><code>IValueProvider</code></a> or <a href="https://learn.microsoft.com/en-us/dotnet/api/system.windows.automation.provider.irangevalueprovider?view=windowsdesktop-7.0"><code>IRangeValueProvider</code></a>.</span>
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Are we absolutely certain about this? Our approach in Chromium is to always expose the AriaProperties in this property, regardless of whether it is already exposed in other more relevant UIA properties. I believe this is also what the documentation indicates as well: https://learn.microsoft.com/en-us/windows/win32/winauto/uiauto-ariaspecification#w3c-aria-states-and-properties-mapped-to-microsoft-active-accessibility-and-ui-automation.

Copy link
Contributor Author

@sivakusayan sivakusayan Oct 23, 2023

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks for that link - I got the impression from 4.3 Exposing attributes that do not directly map to accessibility API properties that AriaProperties is supposed to be used purely to expose unsupported semantics. I guess I would be curious why these properties are exposed in AriaProperties when there are UIAutomation mappings that described them just as well, but in any case it's probably best to just align with the with the UIAutomation documentation.

As an aside, I notice that there are a lot of properties in that link that seem to need AriaProperties exposure, but aren't documented in the Core-AAM as such. I guess that's an issue we can address separately.

Edit: Ahh, I see - this is the problem you brought up here.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Your interpretation of it is not wrong. 4.3 specifically says

When WAI-ARIA roles, states and properties do not directly map to an accessibility API, and there is a mechanism in the API to expose the WAI-ARIA role, states, and properties and their values, user agents MUST expose the WAI-ARIA data using that mechanism as follows

and later says

User agents MUST also expose the entire role string through this mechanism and MAY also expose WAI-ARIA attributes and values through this mechanism even when there is a direct mapping to an accessibility API.

In this case, I believe the UIA documentation is more restrictive than the Core-AAM one, but both can be respected if we add AriaProperties on all aria attributes.

</td>
</tr>
<tr>
Expand Down
Loading