label member

[johnfoliot]

The current draft of the specification states that providing an Accessible Name via the label member is a SHOULD requirement (while allowing for an embedded accessible name).

The label of an ImageResource is a string that provides an accessible name for the associated image.

Authors are strongly encouraged to add a label unless the ImageResource's label can be inferred from an external label in its context. For example, the name can act as the label for any member of the icons array.

If an explicit label is not provided, but the type supports providing an embedded accessible name, implementors MAY choose to infer the label until the src has been downloaded and parsed. If the src is found to provide an embedded accessible name, implementors may choose to update the label to match that value.

• It is recommended that the provision of an Accessible Name become a MUST requirement (using either method) to return a valid resource.
• While there is already precedent for 'inferred contextual' labels in HTML, it is recommended that labels instead be programmatically associated to the resource (strong binding), rather than just a contextual association (weak binding).
• As an open question, has a conflict resolution mechanism been envisioned here? What happens if a resource has BOTH an explicit label member AND and an embedded accessible name with differing values - which takes precedence?
• Finally, is there evidence of support that user-agents have mapped the label member to Accessible Name in the accessibility tree?

[aarongustafson]

Thanks for this @johnfoliot!

It is recommended that the provision of an Accessible Name become a MUST requirement (using either method) to return a valid resource.

Can do. I’m still a little fuzzy on all of the conformance language.

While there is already precedent for 'inferred contextual' labels in HTML, it is recommended that labels instead be programmatically associated to the resource (strong binding), rather than just a contextual association (weak binding).

Agreed. Would it help make this clearer in the example if I specifically highlight that in the context of the Manifest, the name (or short_name) is the default label value for all members of the icons array, but that it may be overridden by a local label on any specific ImageResource in that array?

As an open question, has a conflict resolution mechanism been envisioned here? What happens if a resource has BOTH an explicit label member AND an embedded accessible name with differing values - which takes precedence?

I can clarify this. As I mentioned above, the explicit label in the ImageResource would trump all inferred or embedded accessible names.

Finally, is there evidence of support that user-agents have mapped the label member to Accessible Name in the accessibility tree?

This is a good question. It likely depends on context. In terms of the Manifest usage, ImageResources are exposed at the OS level, so the accessibility tree in question is at that level (as opposed to within the UA itself). I don’t know enough about the Payment Request API to be able to speak to it’s implementation of ImageResource there. Perhaps @rayankans can provide feedback on that.

[johnfoliot]

@aarongustafson

I’m still a little fuzzy on all of the conformance language.

No worries, that's why I do reviews :-)
To be clear, I was thinking of MUST in the RFC2119 sense, although that is not an obligation on any W3C spec to use those fixed and defined terms (AFAIK). As long as the criticality is preserved, use whatever editorial mechanism you want.

Would it help make this clearer in the example if...

Yes (please).

I can clarify this. ...

Cool, thanks.

This is a good question. It likely depends on context. In terms of the Manifest usage, ImageResources are exposed at the OS level, so the accessibility tree in question is at that level (as opposed to within the UA itself)...

Hmmm... beyond my skills level as well. However it is critical that any graphical artifact has some type of accessible name for screen reader usage. Failing to provide that will make this inaccessible, but I am unsure of specific implementation guidance (sorry). From my vantage point, all I can do is focus on the criticality.

[aarongustafson]

@johnfoliot Take a look at #40 and let me know how that language looks. For simplicity, I broke out the accessible name calculation to its own algorithm. Please not that for the worst-case scenario of no accessible name being defined, I have set up the algorithm to return an empty string as the accessible name which—if OSes act similarly to the web at least—should preclude the image from being announced by screen readers in a useless/distracting way.

[aarongustafson]

@johnfoliot ::gentle nudge::

If this looks good, I’ll get it merged today.

[johnfoliot]

Sorry Aaron, WFM - thanks for seeing this through. JF

…

On Mon, Mar 29, 2021 at 2:45 PM Aaron Gustafson ***@***.***> wrote: @johnfoliot <https://github.com/johnfoliot> ::gentle nudge:: If this looks good, I’ll get it merged today. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#39 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAJL44ZVCU5CWDVKMCTM2L3TGDDDTANCNFSM4ZTDCNXA> .

-- *​John Foliot* | Principal Accessibility Specialist "I made this so long because I did not have time to make it shorter." - Pascal "links go places, buttons do things"

[michael-n-cooper]

APA just confirming ok with this, just shifting labels around accordingly.

[aarongustafson]

@michael-n-cooper Any idea why the w3c bot reverted your change?

[michael-n-cooper]

no :(