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

[a11y] Disabled dates aren't actually disabled in markup #713

Open
backwardok opened this issue Sep 14, 2017 · 4 comments
Open

[a11y] Disabled dates aren't actually disabled in markup #713

backwardok opened this issue Sep 14, 2017 · 4 comments
Labels
accessibility Anything related to ensuring *everybody* can use react-dates <3 bug Oh no, something's broken :-(

Comments

@backwardok
Copy link
Contributor

When a date is disabled, CSS is applied to make it look disabled (CalendarDay--blocked-calendar, CalendarDay--blocked-out-of-range):
image

However, this date is still clickable with a mouse (even if the mouse click doesn't do anything in the UI), can be navigated to with a keyboard (you can arrow through disabled dates), and doesn't indicate that those dates are disabled to a screen reader user (because the button itself is not actually disabled).

Example where you can see this: http://airbnb.io/react-dates/?selectedKind=DRP%20-%20Day%20Props&selectedStory=blocks%20fridays&full=0&down=1&left=1&panelRight=0&downPanel=storybook%2Factions%2Factions-panel

@backwardok backwardok added the bug Oh no, something's broken :-( label Sep 14, 2017
@backwardok
Copy link
Contributor Author

@majapw can you think of a reason why someone would not want to have the disabled attribute on the button underlying the date?

Note: this likely means messing with how next/previous day handling works for months (and what does this mean if you open a month in the past where the past is disabled? Or should you just not be allowed to do that either?

@majapw
Copy link
Collaborator

majapw commented Sep 14, 2017

I think a couple of things are being conflated here.

  1. I am surprised that the VO does not read out that the date is unavailable. That's like specifically what https://github.com/airbnb/react-dates/blob/master/src/components/CalendarDay.jsx#L113 is for. So that is a bug.

  2. We can definitely disable the button for a disabled date. That was just an oversight on my part.

this likely means messing with how next/previous day handling works for months

  1. I don't understand why these things would be related. We have talked about possibly disabling month navigation when it would take you to exclusively blocked dates (Limited months range navigation (add min / max date props) #339 and I think there's another issue as well), but that seems a separate discussion from disabling the blocked buttons?

@erin-doyle
Copy link
Collaborator

So I've submitted a PR to address the unavailable dates not being read as such by screen readers.

I did also locally code the disabling of the buttons for the unavailable dates. However, upon testing, it occurred to me that if the buttons are disabled then those users depending on screen readers would be blocked from being able to navigate over those dates and nothing would read to them why they were being blocked from moving back or forward any further. It works great for sighted people but I wonder if it would be a confusing user experience for those that are not.

majapw added a commit that referenced this issue Oct 13, 2017
For for Issue #713 Unavailable Date phrase not reading on Screen Readers
@majapw
Copy link
Collaborator

majapw commented Oct 13, 2017

@erin-doyle Yeah this was a concern of mine as well. I think we should maybe think more deeply on whether or not to disable blocked buttons for this reason.

@backwardok backwardok added the accessibility Anything related to ensuring *everybody* can use react-dates <3 label Jan 3, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
accessibility Anything related to ensuring *everybody* can use react-dates <3 bug Oh no, something's broken :-(
Projects
None yet
Development

No branches or pull requests

3 participants