You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
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.
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.
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.
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.
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)
The text was updated successfully, but these errors were encountered:
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
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.
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.
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.
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.
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
The text was updated successfully, but these errors were encountered: