docs(button): add href for Link Variant

[tejas161]

What I did

1. Add example of how to include href values to pf-button link variant.

Testing Instructions

1. Observe and Test the pf-button link variant with href value.

Notes to Reviewers

@adamjohnson I Had some questions regarding A11y:-

1. When I use TAB Key and try clicking the pf-button with a href link, the Focus gets inside the button. Would that be a Accessibility concern ?

Closes: #2769

[changeset-bot[bot]]

⚠️ No Changeset found

Latest commit: d1c954d0a55a6c2e7c42ade5e986c1a0dfa0f60f

Merging this PR will not cause a version bump for any packages. If these changes should not result in a new version, you're good to go. If these changes should result in a version bump, you need to add a changeset.

Click here to learn what changesets are, and how to add one.

Click here if you're a maintainer who wants to add a changeset to this PR

[adamjohnson]

When I use TAB Key and try clicking the pf-button with a href link, the Focus gets inside the button. Would that be a Accessibility concern ?

Yes. This will fail WCAG Success Criterion 4.1.2 Name, Role Value — Level A.

This is a commonly seen issue most often referred to as "nested interactive controls". When an interactive control has another interactive control as a child element, it disrupts how the child element is communicated to the accessibility tree. This issue can prevent users of assistive technology from finding the child element, getting its correct name and role information, or interacting with it.

The best way forward would be to not nest interactive controls.

It looks like Lumar, a QA and accessibility tool Red Hat uses, has a check for nested interactive controls.

[tejas161]

When I use TAB Key and try clicking the pf-button with a href link, the Focus gets inside the button. Would that be a Accessibility concern ?

Yes. This will fail WCAG Success Criterion 4.1.2 Name, Role Value — Level A.

This is a commonly seen issue most often referred to as "nested interactive controls". When an interactive control has another interactive control as a child element, it disrupts how the child element is communicated to the accessibility tree. This issue can prevent users of assistive technology from finding the child element, getting its correct name and role information, or interacting with it.

The best way forward would be to not nest interactive controls.

It looks like Lumar, a QA and accessibility tool Red Hat uses, has a check for nested interactive controls.

When I use TAB Key and try clicking the pf-button with a href link, the Focus gets inside the button. Would that be a Accessibility concern ?

Yes. This will fail WCAG Success Criterion 4.1.2 Name, Role Value — Level A.

This is a commonly seen issue most often referred to as "nested interactive controls". When an interactive control has another interactive control as a child element, it disrupts how the child element is communicated to the accessibility tree. This issue can prevent users of assistive technology from finding the child element, getting its correct name and role information, or interacting with it.

The best way forward would be to not nest interactive controls.

It looks like Lumar, a QA and accessibility tool Red Hat uses, has a check for nested interactive controls.

Thanks @adamjohnson for the information and guidance for the A11y on this issue.

Hi @bennypowers, Since I can't nest the anchor tag inside the pf-button. Should I try creating a href prop for pf-button "link-variant" for adding links ? Your thoughts on this.

[bennypowers]

yeah i think changing the template for pf-button depending on whether there's an href attribute makes sense

@adamjohnson, considering that pfv4 has a <Button component="a" href={}> component , and considering our mandate in this repo to reproduce as closely as possible upstream patterns, do you concur that we can have <pf-button href="...">, which would produce an anchor in shadow dom?

[adamjohnson]

@bennypowers As long as there are no nested interactive controls, that works for me. 👍