Created attachment 464344 [details] Screenshot displaying Role: No matching ARIA role for input type="text" Even though, using VoiceOver + Safari the input type="text" is properly announced as "$label, edit text" which properly convey the element semantic, from the inspector the role provided within the Accessibility section is "No matching ARIA role", which is not true. Even forcing the role="textbox" the role is still "No matching ARIA role". This contrasts with both the WAI-ARIA (https://www.w3.org/TR/wai-aria-1.2/#textbox) and HTML Accessibility API Mappings (https://www.w3.org/TR/html-aam-1.0/#el-input-text). Similarly, this happens for other input types: * email (Role: "No matching aria role" but it should be "textbox", as per html-aam-1.0 - https://www.w3.org/TR/html-aam-1.0/#el-input-email) * number (Role: "No matching aria role" but it should be "textbox", as per html-aam-1.0 - https://www.w3.org/TR/html-aam-1.0/#el-input-number) * tel (Role: "No matching aria role" but it should be "textbox", as per html-aam-1.0 - https://www.w3.org/TR/html-aam-1.0/#el-input-tel) * url (Role: "No matching aria role" but it should be "textbox", as per html-aam-1.0 - https://www.w3.org/TR/html-aam-1.0/#el-input-url) Differently, it's behaving as expected for input types like: * checkbox * search * button/reset/submit * image * range * color (Role: "No matching aria role" but it's correct, as per html-aam-1.0 - https://www.w3.org/TR/html-aam-1.0/#el-input-color) * etc.
<rdar://problem/103907008>
Created attachment 465187 [details] Patch
Created attachment 465190 [details] Patch
Created attachment 465191 [details] Patch
Created attachment 465192 [details] Patch
Committed 260868@main (5cd01f201aba): <https://commits.webkit.org/260868@main> All reviewed patches have been landed. Closing bug and clearing flags on attachment 465192 [details].