Improve accessibility

[krystalcampioni]

Roadmap

• [x] 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]

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]

@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:

• [x] 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]

@krystalcampioni just an FYI. Changing the buttons back into input fields might bring back the IOS focus issue https://github.com/krystalcampioni/vue-hotel-datepicker/issues/57

[krystalcampioni]

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]

@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]

@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]

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

[krystalcampioni]

Perfect, no rush! thanks 😬

[stale[bot]]

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]

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

[matiasperrone]

Check v4.0.0-beta.2

[matiasperrone]

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

[matiasperrone]

Closed for lack of activity