Bug 196661 – AX: Automatically compute accessibility labels for Apple Pay buttons

• Status: RESOLVED
• Resolution: FIXED
• Component: Accessibility

[chris fleizach]

If a merchant doesn’t specify an aria-label on their Apple Pay buttons, WebKit should make a better effort at computing a good default accessibility label. For instance, it could take the -apple-pay-button-type CSS property into account to decide whether the button represents “buy”, “subscribe”, “book”, etc.

<rdar://problem/49646423>

[chris fleizach]

Created attachment 366868 [details]
patch

[EWS Watchlist]

Comment on attachment 366868 [details]
patch

Attachment 366868 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11787746

New failing tests:
accessibility/mac/apple-pay-labels.html

[EWS Watchlist]

Created attachment 366871 [details]
Archive of layout-test-results from ews103 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366868 [details]
patch

Attachment 366868 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/11787759

New failing tests:
accessibility/mac/apple-pay-labels.html

[EWS Watchlist]

Created attachment 366873 [details]
Archive of layout-test-results from ews104 for mac-highsierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-highsierra-wk2  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366868 [details]
patch

Attachment 366868 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/11787780

New failing tests:
accessibility/mac/apple-pay-labels.html

[EWS Watchlist]

Created attachment 366874 [details]
Archive of layout-test-results from ews112 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews112  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[chris fleizach]

Created attachment 366896 [details]
patch

[EWS Watchlist]

Comment on attachment 366896 [details]
patch

Attachment 366896 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11795001

New failing tests:
accessibility/mac/apple-pay-labels.html

[EWS Watchlist]

Created attachment 366898 [details]
Archive of layout-test-results from ews103 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews103  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366896 [details]
patch

Attachment 366896 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/11795012

New failing tests:
accessibility/mac/apple-pay-labels.html

[EWS Watchlist]

Created attachment 366899 [details]
Archive of layout-test-results from ews107 for mac-highsierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews107  Port: mac-highsierra-wk2  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366896 [details]
patch

Attachment 366896 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/11795037

New failing tests:
accessibility/mac/apple-pay-labels.html

[EWS Watchlist]

Created attachment 366901 [details]
Archive of layout-test-results from ews117 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews117  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[chris fleizach]

Created attachment 366938 [details]
patch

[EWS Watchlist]

Comment on attachment 366938 [details]
patch

Attachment 366938 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11806516

New failing tests:
accessibility/mac/apple-pay-session-v4.html

[EWS Watchlist]

Created attachment 366944 [details]
Archive of layout-test-results from ews100 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366938 [details]
patch

Attachment 366938 [details] did not pass mac-wk2-ews (mac-wk2):
Output: https://webkit-queues.webkit.org/results/11806704

New failing tests:
accessibility/mac/apple-pay-session-v4.html

[EWS Watchlist]

Created attachment 366947 [details]
Archive of layout-test-results from ews105 for mac-highsierra-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews105  Port: mac-highsierra-wk2  Platform: Mac OS X 10.13.6

[EWS Watchlist]

Comment on attachment 366938 [details]
patch

Attachment 366938 [details] did not pass mac-debug-ews (mac):
Output: https://webkit-queues.webkit.org/results/11806644

New failing tests:
accessibility/mac/apple-pay-session-v4.html

[EWS Watchlist]

Created attachment 366953 [details]
Archive of layout-test-results from ews115 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-debug-ews.
Bot: ews115  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[chris fleizach]

Created attachment 366964 [details]
patch

[EWS Watchlist]

Comment on attachment 366964 [details]
patch

Attachment 366964 [details] did not pass mac-ews (mac):
Output: https://webkit-queues.webkit.org/results/11808750

New failing tests:
accessibility/mac/apple-pay-session-v4.html

[EWS Watchlist]

Created attachment 366972 [details]
Archive of layout-test-results from ews100 for mac-highsierra

The attached test failures were seen while running run-webkit-tests on the mac-ews.
Bot: ews100  Port: mac-highsierra  Platform: Mac OS X 10.13.6

[chris fleizach]

Created attachment 366976 [details]
patch

[Andy Estes]

Comment on attachment 366976 [details]
patch

I wonder if we would get the same accessibility label, without having to keep our own set of localized strings, by calling +[PKPaymentButton buttonWithType:style:] and then querying its accessibility label?

[Joanmarie Diggs]

(In reply to chris fleizach from comment #0)
> If a merchant doesn’t specify an aria-label on their Apple Pay buttons,
> WebKit should make a better effort at computing a good default accessibility
> label. For instance, it could take the -apple-pay-button-type CSS property
> into account to decide whether the button represents “buy”, “subscribe”,
> “book”, etc.

Aside: I trust you reported this issue to the Apple Pay folks, and this is perhaps an interim fix?

Accessibility is, of course, my number one priority. That said, ideally either merchants would be strongly encouraged (e.g. through validation failures) to name their buttons and/or Apple Pay itself would provide the fallback.

(Disclaimer: I'm admittedly unfamiliar with being an Apple Pay merchant and what means Apple Pay has to validate and/or correct merchant failures.)

[chris fleizach]

(In reply to Andy Estes from comment #26)
> Comment on attachment 366976 [details]
> patch
> 
> I wonder if we would get the same accessibility label, without having to
> keep our own set of localized strings, by calling +[PKPaymentButton
> buttonWithType:style:] and then querying its accessibility label?

it's a bit risky. I'm not sure anything happens on Mac (At all right now) to provide the right labels. 

On iOS, those buttons only get their AX information if an AT is running, which will probably run into some issue

Feel safer having these labels unambiguously set here

[chris fleizach]

(In reply to Joanmarie Diggs (irc: joanie) from comment #27)
> (In reply to chris fleizach from comment #0)
> > If a merchant doesn’t specify an aria-label on their Apple Pay buttons,
> > WebKit should make a better effort at computing a good default accessibility
> > label. For instance, it could take the -apple-pay-button-type CSS property
> > into account to decide whether the button represents “buy”, “subscribe”,
> > “book”, etc.
> 
> Aside: I trust you reported this issue to the Apple Pay folks, and this is
> perhaps an interim fix?
> 

I'm the same folks in this case. 

> Accessibility is, of course, my number one priority. That said, ideally
> either merchants would be strongly encouraged (e.g. through validation
> failures) to name their buttons and/or Apple Pay itself would provide the
> fallback.

Since all of these buttons are named (there's not any free form buttons for Apple Pay), I feel better having WebKit always provide the label, just like it's always providing the image and text. That way we can be assured of

1) consistency of naming
2) correct localization

> 
> (Disclaimer: I'm admittedly unfamiliar with being an Apple Pay merchant and
> what means Apple Pay has to validate and/or correct merchant failures.)

[Joanmarie Diggs]

Comment on attachment 366976 [details]
patch

r+ = You know what's best in the particular case, but the little standards-centric voice inside me still thinks it feels a bit weird.

[chris fleizach]

(In reply to Joanmarie Diggs (irc: joanie) from comment #30)
> Comment on attachment 366976 [details]
> patch
> 
> r+ = You know what's best in the particular case, but the little
> standards-centric voice inside me still thinks it feels a bit weird.

Thanks! if it makes you feel better, -apple-pay buttons are not in any spec =)

[WebKit Commit Bot]

Comment on attachment 366976 [details]
patch

Clearing flags on attachment: 366976

Committed r244061: <https://trac.webkit.org/changeset/244061>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.