You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Good question. The mappings for aria-readonly=true appear a match for all platforms/APIs but AXAPI.
Currently the HTML-AAM has AXEnabled: NO for readonly, but "AXValue: the AXUIElementIsAttributeSettable method returns NO" for aria-readonly=true.
AXEnabled:NO seems wrong, and doesn't match what webkit is doing. But I can't confirm if the AXUIElementIsAttributeSettable method returns NO with AXValue. @cookiecrook or @fleizach, are we safe to map HTML readonly to aria-readonly="true" where AXAPI is concerned?
are we safe to map HTML readonly to aria-readonly="true" where AXAPI is concerned?
Yes. I believe so.
AXEnabled:NO seems wrong, and doesn't match what webkit is doing. But I can't confirm if the AXUIElementIsAttributeSettable method returns NO with AXValue.
Yeah, I agree that seems wrong. AXEnabled should map inversely to disabled/aria-disabled rather than readonly but perhaps some piece of the chain assumes that readonly is a superset of disabled? @fleizach may know.
bb106b9: Have updated all mappings for readonly to use CORE-AAM mappings for aria-readonly=true. If there are any issues, particularly with AXAPI (ping @fleizach?), can reopen.
The 'readonly' attribute should be mapped to ATK_STATE_READ_ONLY.
The text was updated successfully, but these errors were encountered: