Skip to content
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

Improve accessibility #99

Closed
1 of 3 tasks
krystalcampioni opened this issue Oct 19, 2018 · 13 comments
Closed
1 of 3 tasks

Improve accessibility #99

krystalcampioni opened this issue Oct 19, 2018 · 13 comments

Comments

@krystalcampioni
Copy link
Member

krystalcampioni commented Oct 19, 2018

Roadmap

  • Replace the dummy inputs and buttons for actual input and button tags, so the user can interact with the elements using the tab/enter keys
  • Include ARIA attributes
  • Improve keyboard navigation, by allowing the user to navigate between days with the arrow keys
@amulchinock
Copy link
Contributor

I really like this issue. It actually brings to light some interesting challenges with web technology and accessible UX, and is something I'm quite passionate about.

For example - many years ago, I worked as a carer for a major care provider in the UK. I saw clients using computers on a daily basis, many of whom had some form of impairment that required them to use a form of assistive technology.

Some of the things I witnessed were:

  • Clients using the machine OS' magnification tool to zoom in on UI elements.
  • Clients using the browser's built in webpage zooming functionality to increase font size
  • Clients using screen readers to have content read out to them
  • Clients using assistive hardware to enable them to use their computer for simple tasks (pressure pads, joysticks .etc)

In all of the above examples - the web experience was not always amazing. Sometimes I would be asked to assist someone with filling out a simple web form (that may or may not have included a datepicker), because it wasn't designed with assistive technologies in mind.

In one particular instance, I remember a client getting very frustrated trying to simply log into their bank account. They couldn't do it - their screen reader couldn't tell them where to enter their login credentials, despite previously being able to do it on their own. Turns out their bank decided to drop accessibility in favour of "security".

I've done some Googling on the use case you've described - and I think we could potentially solve this with Vue's refs attribute (I'm not going to write pseudo code at this stage), if added to each calendar day (and other interactive UI elements), although I'm sure there are other ways to achieve this.

Thinking about UX though - we should probably accommodate screen readers, by using appropriate ARIA attributes on each day, so screen readers can read out the day information (including whether a day is disabled .etc)

Can we extend the scope of this issue?

@krystalcampioni
Copy link
Member Author

krystalcampioni commented Oct 21, 2018

@amulchinock it's great that you've had experience as a carer, I'd really appreciate your feedback on this topic for sure.
We can surely expand the scope of the issue. Maybe we can follow a little roadmap on this topic, so we can release smaller improvements, while moving towards an overall better accessibility. Something like:

  • Replace the dummy inputs and buttons for actual input and button tags, so the user can interact with the elements using the tab/enter keys
  • Include ARIA attributes
  • Improve keyboard navigation, by allowing the user to navigate between days with the arrow keys

What do you think?

@chrisrenga
Copy link
Contributor

@krystalcampioni just an FYI. Changing the buttons back into input fields might bring back the IOS focus issue #57

@krystalcampioni
Copy link
Member Author

Thanks @chrisrenga I'll keep that in mind. We can keep the button approach for the "inputs" as they are not a problem since buttons are focusable 👍

@amulchinock
Copy link
Contributor

amulchinock commented Oct 21, 2018

@krystalcampioni @chrisrenga I agree with the roadmap approach.

I suppose if we needed to start anywhere, keyboard navigation would be a good place, as it assists accessibility for almost all users - whereas ARIA attributes (for example) would be a much smaller subset of users.

@krystalcampioni
Copy link
Member Author

@amulchinock I've just finished implementing the basic keyboard navigation on the PR above. The solution is a bit hacky since the dayClass computed property grew quite organically to accommodate new features and currently allows for a couple of different types/situations where a date can be disabled by CSS only ( e.g days before the min amount of nights, out of range, etc ) I'm going to work on refactoring this property to better handle all the different conditions in a follow up PR.

I'd like your feedback and suggestions on how to handle the ARIA attributes. If you're not too busy maybe you could create a PR for that?

@chrisrenga your feedback is also welcome if feel like reviewing the PR :)

@amulchinock
Copy link
Contributor

@krystalcampioni I'll come back to you in a few days on the ARIA attributes. Swamped right now! 🤓

@krystalcampioni
Copy link
Member Author

Perfect, no rush! thanks 😬

krystalcampioni added a commit that referenced this issue Oct 25, 2018
krystalcampioni added a commit that referenced this issue Oct 25, 2018
- Step 1 of the roadmap defined at #99
@stale
Copy link

stale bot commented Nov 25, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

@matiasperrone
Copy link
Collaborator

This topic should be addressed, but seem complex. I neebie now as a collaborator.

@matiasperrone matiasperrone added this to the v3.0.0 milestone Feb 17, 2020
@matiasperrone
Copy link
Collaborator

Check v4.0.0-beta.2

@matiasperrone matiasperrone modified the milestones: v3.0.0, v4 Aug 27, 2020
@matiasperrone matiasperrone removed this from the v4 milestone Sep 24, 2020
@matiasperrone matiasperrone added this to the v5 milestone Oct 9, 2020
@matiasperrone
Copy link
Collaborator

@amulchinock Did you have the chance to look at the new 4.x version?

@matiasperrone
Copy link
Collaborator

Closed for lack of activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants