Closed ChristiaanScheermeijer closed 4 months ago
github-actions[bot]
commented
4 months ago Visit the preview URL for this PR (updated for commit f9eebb4):
https://ottwebapp--pr455-feat-accessibility-a-qqc0v4n1.web.app
(expires Sun, 14 Apr 2024 11:35:04 GMT)
🔥 via Firebase Hosting GitHub Action 🌎
Sign: c198f8a3a199ba8747819f7f1e45cf602b777529
ChristiaanScheermeijer
commented
4 months ago Hi @dbudzins @AntonLantukh, thank you again for reviewing this PR 😄
Correct me if I'm wrong, but after evaluating your feedback, these are the open points:
I've responded to each conversation respectively, let's keep the discussions there for the overview.
ChristiaanScheermeijer
commented
4 months ago @AntonLantukh @dbudzins this PR is ready for merge 😄
This PR results from many features and fixes done on the Videodock/ott-web-app fork.
We've mainly worked on accessibility, UI improvements and bug fixes.
From now on, we hope to submit smaller pull requests directly to the open-source repo. This should make reviewing more bearable for you guys 😅
Changelog
Features
Bug Fixes
Most notable changes
Form validation improvements for screen readers
We revamped the form validation by a lot. Most notably, we now announce form validation errors for screen reader users (while not presenting them visually), and we have made every submit button always enabled. This last one is a requirement from an a11y standpoint. For a full overview of improvements, see: Videodock/ott-web-app#107
Improved modals for accessibility
Even though we recently introduced and improved the use of ARIA modals and dialogs. We improved it even further. The most notable change is that the Cinema component (video player) is now wrapped in a Modal component. This has certain benefits:
inert, programmatically setting and resetting the focus consistently and listening to the Escape key to close)The Cinema component uses a grow/shrink animation instead of a fade in/out as an extra benefit.
We also improved the initial focus and restored the focus into and from the modal. Some edge cases were on some screen readers (iOS and Android).
Enhanced user menu & profile menu for accessibility
The user and profile menu contained a heading and horizontal rule within the
<li>elements. This caused the screen reader to announce the amount of list items incorrectly. Also, the HTML structure needs to be corrected.Because the Usermenu was previously merely used as a pass-through component, passing along a lot of props from
<UserMenu />to<ProfileMenu />, it felt logical to split them into separate components.We also applied some other ARIA attributes such as
role="button"to MenuButtons (actions instead of links) andaria-current="true"to the active elements (eg. currently selected profile).Shelf optimised for screen readers
We optimized navigation through the shelves for screen reader users. We looked at other examples online and applied the best practices. We also added a page indicator for screen readers. It announces the current state of the carrousel as pages. It gets read when you use the chevron buttons.
We also increased the hit area of the chevron (next/prev) buttons according to the WCAG specs.
Small accessibility improvements
These are small but could be of particular interest:
Offer refactor
We've moved most of the logics behind the Choose Offer step from the UI to the CheckoutController, using a similar approach as we recently did for the Registration and Checkout steps. This should make the UI more simple and make the useOffer hook reusable between containers and potential other platforms.
We also fixed a bug where after a PayPal payment the incorrect offer was checked for entitlement, and raised the delay in useCheckAccess to compensate for a delay in the Cleeng backend that results into an out-of-sync UI after buying a subscription.
Related WCAG 2.1 (AA) requirements