Skip to content
This repository has been archived by the owner on Sep 11, 2024. It is now read-only.

Refactor MessageActionBar w/ARIA Toolbar pattern #4827

Closed

Conversation

jugglinmike
Copy link
Contributor

@jugglinmike jugglinmike commented Jun 25, 2020

This is intended to resolve element-hq/element-web#11316

Signed-off-by: Mike Pennisi [email protected]

Copy link
Member

@t3chguy t3chguy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good otherwise, will test it once you make these changes. Thanks!

src/components/views/messages/MessageActionBar.js Outdated Show resolved Hide resolved
src/components/views/messages/MessageActionBar.js Outdated Show resolved Hide resolved
@t3chguy
Copy link
Member

t3chguy commented Jul 5, 2020

Can you do a DCO sign-off in the PR description as one of your commits lacks one, thanks :)

Copy link
Member

@t3chguy t3chguy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks pretty good other than the query

const current = buttonNames.indexOf(this.state.focused);
let newIndex = null;

if (key === Key.ARROW_UP || key === Key.ARROW_DOWN) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@jugglinmike
Copy link
Contributor Author

Hmm, this seems to disagree with https://www.w3.org/TR/wai-aria-practices-1.1/examples/toolbar/toolbar.html

Looks like the "up" and "down" arrows should only perform a click for targets with aria-haspopup. In other words: those keys should have no effect for "Reply" and "Edit." Is that what you had in mind?

@t3chguy
Copy link
Member

t3chguy commented Jul 7, 2020

So the codebase already has some classes to help out with keeping track of RovingTabIndex. It'd be nice to use that and make a generic Toolbar component which would handle the keypresses between all of its direct children so that we can have one backing solution for both this and #4799

In other words: those keys should have no effect for "Reply" and "Edit." Is that what you had in mind?

Yes, that's what the aria authoring practices say

@jugglinmike
Copy link
Contributor Author

Are you saying we should do that work before implementing this feature?

@t3chguy
Copy link
Member

t3chguy commented Jul 7, 2020

I am saying it'd be nice to write a component which does this for all Toolbars rather than manually having to add these keyboard handlers to every toolbar component manually, means a lot more repeated work like this PR

@jugglinmike
Copy link
Contributor Author

Totally! I just can't tell if you consider that improvement to be blocking this one.

@t3chguy
Copy link
Member

t3chguy commented Jul 7, 2020

It'd be a replacement which would replace this one, so whilst this could land, it'd be replaced by this generic toolbar thing

componentDidMount() {
this.props.mxEvent.on("Event.decrypted", this.onDecrypted);
this.props.mxEvent.on("Event.beforeRedaction", this.onBeforeRedaction);
this.elRef.current.addEventListener("keydown", this.onKeyDown, true);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

we should really be using react keydown handlers for this

(note to self mostly, as I am trying to make a generic Toolbar component now)

@t3chguy
Copy link
Member

t3chguy commented Jul 17, 2020

Superseded by above. Thank you for your effort though!

@t3chguy t3chguy closed this Jul 17, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

improve toolbar accessibility pattern for message actions
2 participants