Bug 226534 - iOS - VoiceOver reads the programmatically associated label instead of the accessible name provided via the aria-label or aria-labelledby attribute
Summary: iOS - VoiceOver reads the programmatically associated label instead of the ac...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Accessibility (show other bugs)
Version: WebKit Nightly Build
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Andres Gonzalez
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2021-06-02 07:37 PDT by Andres Gonzalez
Modified: 2021-06-10 12:09 PDT (History)
9 users (show)

See Also:


Attachments
Patch (13.77 KB, patch)
2021-06-02 08:02 PDT, Andres Gonzalez
no flags Details | Formatted Diff | Diff
Patch (13.77 KB, patch)
2021-06-10 06:20 PDT, Andres Gonzalez
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andres Gonzalez 2021-06-02 07:37:54 PDT
iOS - VoiceOver reads the programmatically associated label instead of the accessible name provided via the aria-label or aria-labelledby attribute
Comment 1 Radar WebKit Bug Importer 2021-06-02 07:38:04 PDT
<rdar://problem/78762510>
Comment 2 Andres Gonzalez 2021-06-02 07:41:45 PDT
rdar://65935211
Comment 3 Andres Gonzalez 2021-06-02 07:45:08 PDT
Expected:
When an input has a programmatically associated label and an aria-label attribute or aria-labelledby attribute, based on the accessible name computation the aria-label or aria-labelledby attribute should take precedence over the programmatically associated label. 

Actual:
VoiceOver on iOS, reads the programmatically associated label instead of the accessible name provided via the aria-label or aria-labelledby attribute
Applies to input types: text, password, search, tel, email and url

On macOS Catalina Version 10.15.5 works as expected - aria-label or aria-labelledby attribute takes precedence over the programmatically associated label.
Comment 4 Andres Gonzalez 2021-06-02 08:02:11 PDT
Created attachment 430350 [details]
Patch
Comment 5 chris fleizach 2021-06-07 20:40:08 PDT
Comment on attachment 430350 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=430350&action=review

> Source/WebCore/ChangeLog:10
> +        given objet, and using the label of that title element as the label of

object

> Source/WebCore/accessibility/atk/WebKitAccessibleUtil.cpp:111
> +        if (text.textSource == AccessibilityTextSource::LabelByElement && !coreObject->titleUIElement())

if we don't expose the titleUIElement, should it even be in the accessibilityText that's generated?
Comment 6 Andres Gonzalez 2021-06-10 06:20:49 PDT
Created attachment 431069 [details]
Patch
Comment 7 Andres Gonzalez 2021-06-10 06:28:57 PDT
(In reply to chris fleizach from comment #5)
> Comment on attachment 430350 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=430350&action=review
> 
> > Source/WebCore/ChangeLog:10
> > +        given objet, and using the label of that title element as the label of
> 
> object

Fixed.
> 
> > Source/WebCore/accessibility/atk/WebKitAccessibleUtil.cpp:111
> > +        if (text.textSource == AccessibilityTextSource::LabelByElement && !coreObject->titleUIElement())
> 
> if we don't expose the titleUIElement, should it even be in the
> accessibilityText that's generated?

This is used for aria-label, so you can have a form field, for instance, with aria-label="blah" and we want to return "blah" if there is no titleUIElement. It seems that the precedence of titleUIElement over aria-label was established at some point, but I have not check what the aria spec says about this, if any thing.
Comment 8 EWS 2021-06-10 12:08:59 PDT
Committed r278718 (238686@main): <https://commits.webkit.org/238686@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 431069 [details].