ariaSelected and ariaExpanded properties are not mapping to the correct attributes. ariaInvalid missing
Reported by
ab...@abdulmhamid.com,
Dec 12
|
||||
Issue description
UserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_6) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/71.0.3578.80 Safari/537.36
Steps to reproduce the problem:
1. Create an HTMLElement (a button is used in the test case)
2. Set ariaSelected on the element using the property.
3. Run getAttribute('aria-selected') on the element and see that it is still null.
4. Repeat steps 2 and 3 for ariaExpanded/aria-expanded and ariaInvalid/aria-invalid
What is the expected behavior?
The aria-selected, aria-expanded, and aria-invalid attributes should reflect the values of their properties. Equivalent properties such as ariaControls and ariaHasPopup work correctly.
What went wrong?
The ariaSelected and ariaExpanded properties appear to map to attributes that are adjacent to them alphabetically; ariaSelected maps to the aria-setsize attribute and ariaExpanded maps to the aria-flowto attribute.
ariaInvalid does not appear to be a named property but the attribute that it would map to works as expected when set directly.
Did this work before? No
Does this work in other browsers? Yes
Chrome version: 71.0.3578.80 Channel: stable
OS Version: OS X 10.13.6
Flash Version:
Other browsers do not appear to map aria- attributes to properties so the issue seems to be unique to Chromium.
We came across this issue in the development of web-components to allow appropriate aria mappings to the elements. This issue and the previous comment have led us to set all aria- attributes as the specified attributes instead of properties.
,
Dec 12
The other issues appear to present themselves in the same file. ariaDisabled, ariaHidden and the previously named properties also appear to be mismatched.
,
Dec 13
,
Dec 13
Tried testing the issue on chrome reported version# 71.0.3578.80 using Mac 10.13.6 with steps mentioned below: 1) Launched chrome reported version, dragged and dropped the file provided in comment# 0 2) Entered the text in the text field and clicked on Test button, didn't observed any change in the behavior @Reporter: Please find above mentioned information and screencast for your reference and let us know if we missed anything in reproducing the issue. If possible provide alternate steps to reproduce the issue and screencast of it which help in better understanding and further triaging it in better way. Thanks!
,
Dec 13
The button and input are not meant to be interacted with in this case; they are present as elements that these properties would be used on. There is JavaScript that runs on load to set the ariaSelected, ariaExpanded, and ariaInvalid properties so the finished state should be visible on load. I have attached what I see when I open the original HTML file. I have also made some adjustments to the file to help you reproduce the issue. I added some details about how I set up the reproduction and removed ES2015 and later JS. I have also attached a screenshot of the new file. The real information to glean here is that when ariaSelected and certain other properties are set, they are incorrectly reflected as attributes. Another way to reproduce this is to inspect a page with elements (http://nativeformelements.com is very useful here), select an element in the 'Elements' tab in devtools, and set $0.ariaSelected = true in the console. After this you should see that the selected element has had the aria-setsize attribute set instead of aria-selected. Similar behavior is seen for ariaExpanded, ariaInvalid, ariaDisabled, and ariaHidden.
,
Dec 13
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 |
||||
►
Sign in to add a comment |
||||
Comment 1 by woxxom@gmail.com
, Dec 12