Expected behavior
As a Pharos consumer I want to be able to utilize ARIA appropriately while using the Pharos button. When used appropriately, these attributes add much needed context for users of assistive technology to interactive elements so they have clear purpose and behave as expected.
Actual behavior
Pharos consumer currently can pass in label attribute to add the aria-label as well as the pressed to pass in the aria-pressed attribute to the underlying <button> element when constructing the custom web component for a button.
However, there are additional uses of ARIA that are useful to convey various states of a button and their association with other bits of content on the page. Consumers are unable to apply the following commonly used ARIA attributes successfully to the Pharos button:
aria-expandedaria-haspopuparia-description (not fully supported by browsers but can be used)- Full list
The following rely on an ID reference that does not work from light to shadow DOM & vice versa:
aria-labelledbyaria-describedbyaria-controls
Consumers may attempt to apply aria attributes directly to the Pharos component itself however it is often not parsed correctly while using assistive technology and this context is lost.
Steps to reproduce the issue
- Apply the ARIA above directly to the Pharos button and validate in Chrome inspector it's accessibility properties.
Screenshots or code
<button
id="button-element"
name="${ifDefined(this.name)}"
value="${ifDefined(this.value)}"
?autofocus=${this.autofocus}
?disabled=${this.disabled}
type="${ifDefined(this.type)}"
aria-label=${ifDefined(this.label)}
aria-pressed=${ifDefined(this.pressed)}
>
${this.buttonContent}
</button>
;Pharos version
13.2.2
Your environment
- OS: macOS 13.6, Windows 10
- Browser: Chrome, Firefox, Safari
- Version: 118.0.5, 118.0.2, 17.0
Additional information
#628 for a non-breaking attempt at adding the ARIA attributes that do not rely on ID reference by introducing a naming convention
#594 for the breaking change making label and pressed no longer work.
Research and other workarounds are needed to include the attributes that do rely on ID references.
Resources
Expected behavior
As a Pharos consumer I want to be able to utilize ARIA appropriately while using the Pharos button. When used appropriately, these attributes add much needed context for users of assistive technology to interactive elements so they have clear purpose and behave as expected.
Actual behavior
Pharos consumer currently can pass in
labelattribute to add thearia-labelas well as thepressedto pass in thearia-pressedattribute to the underlying<button>element when constructing the custom web component for a button.However, there are additional uses of ARIA that are useful to convey various states of a button and their association with other bits of content on the page. Consumers are unable to apply the following commonly used ARIA attributes successfully to the Pharos button:
aria-expandedaria-haspopuparia-description(not fully supported by browsers but can be used)The following rely on an ID reference that does not work from light to shadow DOM & vice versa:
aria-labelledbyaria-describedbyaria-controlsConsumers may attempt to apply
ariaattributes directly to the Pharos component itself however it is often not parsed correctly while using assistive technology and this context is lost.Steps to reproduce the issue
Screenshots or code
Pharos version
13.2.2
Your environment
Additional information
#628 for a non-breaking attempt at adding the ARIA attributes that do not rely on ID reference by introducing a naming convention
#594 for the breaking change making
labelandpressedno longer work.Research and other workarounds are needed to include the attributes that do rely on ID references.
Resources