With regard to "5. For forward compatibility with new WAI-ARIA properties in future versions, user agents should expose all properties not in the table below as a text string, removing the "aria-" prefix from the name, if the API supports it. For example, aria-foo="bar" would be exposed with a text string foo=bar in UIA Express, since aria-foo is not a currently known WAI-ARIA property".
Comment: Why should user agents make such an assumption and present the aria-foo attribute without 'aria-' ...itmay lead to validation errors and is something best brought to the author's attention for correction. The foo="bar" should not trip up future AT unless they are made to ignore attributes that do not appear to make sense. User agents should simply ignore aria-foo and such.
Developers do have access to Nu Html Checker which flags incorrect use of role and ARIA attributes too I believe.
With regard to "6. Some WAI-ARIA properties are not global, and are only supported on certain roles. If a non-global WAI-ARIA state or property is used where it is not supported, user agents should not map the given WAI-ARIA property to the platform accessibility API. For example, if aria-checked="true" is specified on
, it should not be exposed in MSAA implementations as STATE_SYSTEM_CHECKED. User agents may expose non-relevant attributes as a text string if the API supports it as described above".
Comment:
What is the benefit of user agents exposing a given ARIA property as a text string when it cannot be mapped to the platform API?
It may trip up AT and confuse users.
Perhaps the above mapping rule# 5 and 6 are inconsistent with the goal stated in the abstract?:
"This helps users with disabilities to obtain and interact with information using assistive technologies. ... and helps to ensure that this information appears in a manner consistent with author intent".
IMHO we don't want 5 in there. In addition to the concerns raised in the opening report:
Having every last ARIA property exposed as a name-value pair rather than first-class mappings on each platform is not desired.
The text suggests to user agents that even when there is a proper first-class mapping, these name-value pairs should also be done. I see no good reason for that duplication.
When name-value pair mappings are desired -- or the only solution due to lack of a better mapping -- we explicitly state that in the mapping tables. In other words, we already have support for name-value pairs when that is needed on one or more platforms.
Not all platforms do it. For instance, item 5 doesn't say anything about AXAPI. And if we tried to insist Apple do so unconditionally, I suspect we'd get pushback. And while MSAA is arguably not a stand-alone accessibility API, the current content says this approach is not supported in MSAA. So this isn't a universal solution for future proofing.
There is nothing stopping implementors from doing it if they really want to do so; removing the content in question doesn't prevent or forbid it; it merely stops encouraging it -- and stops suggesting to authors that this is a way to expose more stuff to ATs which might not want stuff exposed that way in the first place.
Regarding item 6, I disagree with what is stated in the opening report: The name-value pair exposure is in some cases the only viable/appropriate mapping on a given accessibility API. In those cases, we explicitly include that mapping in the table associated with the role, state, or property. That said, I do have a problem with "User agents MAY expose non-relevant attributes as a text string if the API supports it as described above." The one thing worse than unneeded and unasked for, but arguably technically correct, attribute spam is irrelevant/incorrect attribute spam. Personally, I think the statement should be a MUST NOT expose non-relevant attributes. But I suspect Mozilla will state that it is not performant for them to sanity-check attributes. The compromise between the two views is to remove that statement.
https://www.w3.org/Bugs/Public/show_bug.cgi?id=29215
IMHO we don't want 5 in there. In addition to the concerns raised in the opening report:
Regarding item 6, I disagree with what is stated in the opening report: The name-value pair exposure is in some cases the only viable/appropriate mapping on a given accessibility API. In those cases, we explicitly include that mapping in the table associated with the role, state, or property. That said, I do have a problem with "User agents MAY expose non-relevant attributes as a text string if the API supports it as described above." The one thing worse than unneeded and unasked for, but arguably technically correct, attribute spam is irrelevant/incorrect attribute spam. Personally, I think the statement should be a MUST NOT expose non-relevant attributes. But I suspect Mozilla will state that it is not performant for them to sanity-check attributes. The compromise between the two views is to remove that statement.