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

Accessibility issues on Ab-Datpicker #72

Open
madhavonebcg opened this issue Jul 9, 2021 · 0 comments
Open

Accessibility issues on Ab-Datpicker #72

madhavonebcg opened this issue Jul 9, 2021 · 0 comments

Comments

@madhavonebcg
Copy link

Type of report

Hi team,
We are using Ab-Datepicker v2.1.19 in our web application as a date picker. We are compliant with HTML5 standards and guidelines and also providing Accessibility support to our clients in all the projects. There some issues raised by the clients regarding the accessibility. If these issues are fixed then they can enhance the overall experience for visually impaired users. So as a loyal and responsible user of Ab-Datepicker, we are requesting the devs at Ab-Datepicker to add these issues as soon as possible and when we can expect these issues to be fixed and even these issues are in the roadmap for development as these issues are becoming the bottleneck the project delivery.

issues needed to be fixed

  1. Expected result: When selecting a page element that opens a dropdown, the focus will remain locked inside the dropdown until a selection is made.
    Actual result: When selecting the ‘Calendar’ page element and navigating through the dropdown with the sideswipe method, the focus will not remain locked inside the calendar.

  2. Expected Result: When swiping through the calendar widget, the date will be announced with the corresponding day of the week.
    Actual Result: When swiping through the calendar widget, the assistive technology reads it as a table and will announce the date with the corresponding row and column number.

  3. Expected Result: The label for the calendar button would be simple to understand. It is recommended that it simply be called “calendar” or “date picker”. Alternatively, if the calendar is closed the button might say “open calendar” and when open it might read “close calendar”.
    Actual Result: The user is given verbose instructions to open the calendar button. The label of the button does not change when the calendar is open to let the user know the calendar may be closed by activating the button again.

  4. Expected Result: It is recommended that the arrow and the instructions on how to activate it be removed or hidden. It would be helpful if the user encountered the heading titled the name of the selected month with an indication that this is a control such as a button.
    Actual Result: VoiceOver announces the arrow in the heading of the calendar widget as unpronounceable. The instructions “Click or press the enter key or the spacebar to change the month.” are confusing such as they are. It is not clear that the control to select a month is within the heading.

  5. Expected Result: When the calendar fields have expanded or collapsed, this should include text in relation to their status. This will ensure that the controls provide important information via the screen reader. With that information being announced, it can be perceived that a change in the context or status of the widgets has taken place in these fields.
    Actual Result: When the calendar fields have expanded or collapsed, visually the date picker expands on the screen however the screen reader does not announce the UI controls when the expansion has happened. This causes the change of context to not be perceived via the screen reader.

Other details

  • Browser: All major browsers
  • OS: Windows, macOS, Android, and iOS
  • Ab-Datepicker version: 2.1.19
  • Screen readers: NVDA, JAWS, Talkback, VoiceOver (macOS and iOS)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant