Anchor Accessibility

[GiantRobots]

I see that onClick is a documented part of the Anchor component but I don't see onKeyPress being documented. It looks like it spreads props so it should pass through but part of supporting Accessibility is documenting it as well.

https://www.w3.org/WAI/GL/wiki/Making_actions_keyboard_accessible_by_using_keyboard_event_handlers_with_WAI-ARIA_controls

Suggests that we should be adding keyboard events in addition to click handlers. Should we update the documentation for the anchor/button component to include recommendations for how to support keyboard navigation/use with these components?

There's also the space + enter or just enter for using these components with keypresses. I'm unsure of how this all works together and the standards for Paste (don't want different approaches ie billing can use space but messaging can only use enter)

[TheSisb]

Hey @GiantRobots, good suggestion we should definitely at least mention when we spread HTMLAnchorElement props down.

I would like to note specifically for Anchor though, that by default a tags respect the space and enter keydowns to trigger the href as it is inbuilt browser behavior. Were you looking to handle some other keydown event and if so, could you provide an example of what you were trying to do?

[GiantRobots]

I guess the first thing is that in the API docs it only has onClick and not onKeyPress so if a user is looking to use the onClick method for something they wouldn't be immediately aware that onKeyPress exists.

The other part for space + enter vs enter. Enter works by default (in chrome) and space does not as seen in the video below.

Screen Recording 2020-12-15 at 1.44.32 PM.zip

I guess I'm just looking for accessibility notes for when people create Anchors and what best practices are.

Were you looking to handle some other keydown event and if so, could you provide an example of what you were trying to do?

I was actually rebuilding something else for funzies and came across anchor a11y stuff and figured I'd check in to see what docs we have and suggestions so I could steal the suggestion and do the least amount of work :D

[TheSisb]

Thanks for reporting back with the example, this is very helpful! I didn't know that space/enter only worked on some browsers... I'll need to check in and get back to you on that one.
I've also added a ticket in our backlog to update the docs to reflect the props

[GiantRobots]

Yeah, Enter works but Space just moved down the screen. I didn't check with some of the accessibility options turned on for the browser however.

[SiTaggart]

Hi @GiantRobots, this is a good question that'll I'll try and cover as best I can.

So the first part is that the Anchor component was one of the first components we documented. We've since added forwarding the ref and spreading props to make it act as if it's just a native HTML anchor element but forgot to update the docs to reflect that. We should really be only documenting APIs that aren't covered by the HTML element itself though, mainly because global HTML attributes and events are pretty exhaustive, and are now extended from in most component type interfaces (we mostly extend a native html elements typings when creating a components interface).

The second part is about how to handle keyboard events. On the whole, if you use the correct native HTML element underneath, and we expose the API correctly, you don't really need to do anything specific for keyboard events, outside of handling the click event. The browser handles the default action of an element, and its event triggering for you.

So what does that even mean?

Let's take a button element. By default, the browser will fire an action for the button based on a pointer click and an enter or space key press. But what it will also do, is treat the click event almost as the super event for the default action. So if you press enter or space, it'll fire a keypress and the click event for you.

That's the same for an anchor element. By default it'll perform its action based on a click or the enter key press. Click is the default, so pressing the enter key all also fires the click event.

So when I say you don't really need to handle keyboard events for native HTML elements, it's because the browser will fire the click event as a result, and you can just handle it in one place.

I created a Code sandbox to demonstrate what I am trying to explain. https://codesandbox.io/s/native-html-element-even-triggering-r6tnu

The only time you need to specifically handle keyboard interaction is when you can't use a native HTML element or you are supplimenting HTML with ARIA and creating an interactive widget like a menu or listbox. Because these are custom, the browser doesn't know what the default action is as it's not built into the spec, so you have to make sure you handle the click and keypress events separately to the fire the default action.

So when it comes to documenting the accessibility of certain components, we don't really need to pay too much attention to special considerations outside of using the correct semantic HTML element for the job, as we know the keyboard event handling will be handled by the browser for us, when handling a click event.