4 ms·

> the accessibility of what’s been made here is probably actually excellent It's not. The whole thing is in a <table>, there's no ARIA attributes let alone one

> the accessibility of what’s been made here is probably actually excellent It's not. The whole thing is in a <table>, there's no ARIA attributes let alone ones that reflect states, and the buttons are...<li>'s? > doing literally nothing for accessibility will probably be better in most instances than doing something This is a great example of why that's true. If the author had referenced any of the best practices for this, they wouldn't have ended up with such a bad result. https://www.w3.org/TR/wai-aria-practices-1.2/examples/combobox/combobox-datepicker.html https://www.w3.org/TR/wai-aria-practices-1.2/examples/combob...

chrismorgan 5y ago
You can add stuff like that, and it’s definitely a legitimate and reasonable approach, but the popup is not functionally necessary, and done fancily even properly stands a fair chance of being just a distraction. If the popup were the only interface then yes, it would be important to optimise accessibility on it, but as it stands I think also it’s a perfectly reasonable option to make the popup entirely inaccessible by keyboard or accessibility tool, and just work with the text box. (This would be paired with things like having Up/Down work to increase/decrease the year/month/date where the cursor is, rather than Up/Down/Left/Right navigating around the calendar table.) I’d be interested to see what a regular user of accessibility stuff would find of this stuff. I think both approaches are perfectly reasonable, with the don’t-expose-the-popup-at-all side possibly even preferable for some.
- TAKEMYMONEY 5y ago
  This is an unfortunately common attitude, "make the ____ entirely inaccessible by keyboard," and it leads to projects like these. A11y and web components are well studied, start from the best practices, and if you deviate, have a good reason why that's supported by testing.

chrismorgan 5y ago

You can add stuff like that, and it’s definitely a legitimate and reasonable approach, but the popup is not functionally necessary, and done fancily even properly stands a fair chance of being just a distraction. If the popup were the only interface then yes, it would be important to optimise accessibility on it, but as it stands I think also it’s a perfectly reasonable option to make the popup entirely inaccessible by keyboard or accessibility tool, and just work with the text box. (This would be paired with things like having Up/Down work to increase/decrease the year/month/date where the cursor is, rather than Up/Down/Left/Right navigating around the calendar table.) I’d be interested to see what a regular user of accessibility stuff would find of this stuff. I think both approaches are perfectly reasonable, with the don’t-expose-the-popup-at-all side possibly even preferable for some.

TAKEMYMONEY 5y ago
This is an unfortunately common attitude, "make the ____ entirely inaccessible by keyboard," and it leads to projects like these. A11y and web components are well studied, start from the best practices, and if you deviate, have a good reason why that's supported by testing.