Skip to content

feat(): add interaction service for a11y #305

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed

Conversation

devversion
Copy link
Member

Closes #289.

@googlebot googlebot added the cla: yes PR author has agreed to Google's Contributor License Agreement label Apr 14, 2016
@devversion devversion force-pushed the feat/interaction-service branch from c967286 to e4a58f1 Compare April 14, 2016 19:29
@devversion devversion force-pushed the feat/interaction-service branch from e4a58f1 to b983bc4 Compare April 14, 2016 20:51
@kara
Copy link
Contributor

kara commented Apr 18, 2016

We're working on a fastclick solution in core that should make some of this easier (handling touch delay, possibly new APIs for global event listeners, etc). It would probably make sense to wait on this functionality a bit and re-visit after.

cc @jelbourn

@devversion
Copy link
Member Author

devversion commented Apr 18, 2016

@kara I'm fine with that - this PR can wait for the fastclick solution, but it should be also able to land, because once the Fastclick Solution is landed, we just need to remove the buffer, which is really small effort.

@jelbourn
Copy link
Member

@devversion I chatted with @kara about this and we agreed that it would be better to wait for the fastclick to land because it will make this service simpler.

@devversion
Copy link
Member Author

@jelbourn Okay cool, just come back if fastclick is available and I will rebase on top of that ;)

@jelbourn jelbourn added the in progress This issue is currently in progress label Apr 19, 2016
@kara kara added the blocked This issue is blocked by some external factor, such as a prerequisite PR label Apr 21, 2016
@jelbourn
Copy link
Member

@marcysutton do you have any thoughts about the combination "progressbar" / "button" from any a11y standpoint?

I would guess that you'd want the two to be siblings in the DOM rather than one inside of the other. I'd also think that you'd want the "progressbar" to be aria-hidden until the button interaction, meaning you might want it to seem like the progress bar is "inserted" after the button is clicked. Not sure if it would make any sense whatsoever to manipulate focus during this interaction.

@jelbourn
Copy link
Member

jelbourn commented Jun 1, 2016

Just realized my previous comment was on the wrong issue. It should have been on #290

@jelbourn
Copy link
Member

@devversion, we're going to try to approach this instead by adding a feature to Zones that can tell you the type of the most recent event was, and then only show if it was a KeyboardEvent. Going to close this.

@jelbourn jelbourn closed this Jun 13, 2016
@marcysutton
Copy link

I'll be very curious to see what that feature looks like. Differentiating between keydown and click can get tricky depending on the element's role.

@devversion
Copy link
Member Author

@jelbourn Sounds interesting. Also wouldn't that mean that the events have to be triggered inside of a zone?

@jelbourn
Copy link
Member

@devversion not sure, depends on how @robertmesserle implements it.

@marcysutton I can CC you on the PR once it exists (and if we validate that the idea works in general).

@devversion devversion deleted the feat/interaction-service branch November 1, 2016 14:25
andrewseguin pushed a commit to andrewseguin/components that referenced this pull request Oct 15, 2018
@angular-automatic-lock-bot
Copy link

This issue has been automatically locked due to inactivity.
Please file a new issue if you are encountering a similar or related problem.

Read more about our automatic conversation locking policy.

This action has been performed automatically by a bot.

@angular-automatic-lock-bot angular-automatic-lock-bot bot locked and limited conversation to collaborators Sep 6, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
blocked This issue is blocked by some external factor, such as a prerequisite PR cla: yes PR author has agreed to Google's Contributor License Agreement in progress This issue is currently in progress
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Service for handling keyboard vs. mouse focus behavior
5 participants