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
Copy file name to clipboardExpand all lines: docs/architecture-decisions/0005-implement-an-accessible-navigation-system.md
+17-5Lines changed: 17 additions & 5 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -89,8 +89,19 @@ for an accessible navigation menu for web application.
89
89
There are several significant drawbacks to using this menu library.
90
90
91
91
* The most significant drawback is that it imposes some operating costs on users
92
-
of assistive technology that are not ideal. Our recent accessibility testing
93
-
[included some details about this problem](https://github.mit.edu/Accessibility-FY2024/omeka/issues/4#issuecomment-182190) while we discussed this menu issue.
92
+
of assistive technology that are not ideal. The library forces the screen
93
+
reader user to explicitly switch operating mode to interact with the menu, and
94
+
does not listen for the type of interaction events which users naturally
95
+
generate while navigating a page.
96
+
97
+
> However, the library is not listening for click events; it seems they are
98
+
> only listening for explicit pointer events. This means you need to switch
99
+
> into forms mode, then press enter or space, to activate a menu ... It also
100
+
> seems they are handling keyboard events explicitly for keys that should
101
+
> normally be handled by the browser like tab and shift+tab.
102
+
103
+
(The above comment comes from [our discussion of the navigation menu after
0 commit comments