Continuing to flesh out the ADR

The ADR text was written with various supplementary URLs in mind, which I'm
now going through and adding while I do a bit of wordsmithing. There are
still some sections of the document which need to be written.

Author: matt-bernhardt

docs/architecture-decisions/0005-implement-an-accessible-navigation-system.md

@@ -36,14 +36,15 @@ The markup which the user finally interacts with looks like this:
 ```
 
 The issue is that the element triggering the flyout menu (the 
-`<span class="sub-arrow"></span>` tag) is inside the anchor element, making it
+`<span class="sub-arrow"></span>` tag) is _inside_ the anchor element, making it
 challenging for users of assistive technologies to separate their interactions
 with the menu link and the submenu toggle.
 
 The current release of SmartMenus (1.2.1) does not support placing this toggle
 element outside of the link element, so it will be necessary to replace it with
 a library which does support this behavior.
 
+
 ### Option 1: SmartMenus 2
 
 The maintainer for SmartMenus is aware of this problem in the library, as we and
@@ -59,23 +60,24 @@ system yet](https://github.com/vadikom/smartmenus/issues/245).
 * Pros: Just upgrading our existing menu library as it improves over time is a
   good philosophy to follow.
 
-* Cons: The timeline for the release of SmartMenus 2 is not clear, and so
-  cannot be guaranteed to happen. Additionally, the significant changes to the
-  library with version 2 will likely require a significant level of effort - so
-  the benefits of a simple upgrade are not likely to accrue based on the
-  materials published so far.
+* Cons: The timeline for the release of SmartMenus 2 is not clear, and cannot
+  be guaranteed to happen. Additionally, the significant changes to the library
+  with version 2 will likely require a significant level of effort - so the
+  benefits of a simple upgrade may not accrue based on the materials published
+  so far.
+
 
 ### Option 2: Accessible Menu
 
-One alternative to SmartMenus is the Accessible Menu library, which takes as its
-starting point the ARIA Authoring Practices Guide for navigation menus. One of
-the supported patterns is the Disclosure Navigation Menu with Top-Level Links,
+One alternative to SmartMenus is the [Accessible Menu](https://accessible-menu.dev/) library, which takes as its
+starting point the [ARIA Authoring Practices Guide](https://www.w3.org/WAI/ARIA/apg/) for navigation menus. One of
+the supported patterns is the [Disclosure Navigation Menu with Top-Level Links](https://www.w3.org/WAI/ARIA/apg/patterns/disclosure/examples/disclosure-navigation-hybrid/),
 which includes the needed separation between navigation links and submenu
 toggles.
 
 While the provided example includes this separation only at the top level of the
-menu, the pattern can be extended to all levels - as demonstrated in this
-CodePen.
+menu, the pattern can be extended to all levels - [as demonstrated in this
+CodePen](https://codepen.io/matt-bernhardt/pen/poBRKrY).
 
 #### Benefits of Accessible Menu
 
@@ -88,32 +90,35 @@ There are several significant drawbacks to using this menu library.
 
 * The most significant drawback is that it imposes some operating costs on users
   of assistive technology that are not ideal. Our recent accessibility testing
-  included some details about this problem while we discussed this menu issue.
+  [included some details about this problem](https://github.mit.edu/Accessibility-FY2024/omeka/issues/4#issuecomment-182190) while we discussed this menu issue.
 
 * The markup requirements for this library do not immediately align with the
-  markup generated by Omeka. This is manageable by either maintaining a set of
-  custom navigation templates or by writing some javascript to manipulate the
-  DOM prior to instantiating the menu.
+  markup generated by Omeka. While this is manageable by either maintaining a
+  set of custom navigation templates (which other themes also do) or by writing
+  some javascript to manipulate the DOM prior to instantiating the menu, it does
+  mean that using this library increases the maintenance burden of the theme.
 
 * The library is javascript-only, and is not distributed with any CSS rules.
   While we can develop and maintain these rules ourselves, it makes this library
   less of a turnkey solution.
 
+
 ### Option 3: CSS-only menu libraries
 
 A third option would be to pursue a "pure CSS" navigation menu, which can be
-found described in several articles around the web.
+found described in [several](https://purecss.io/menus/) [places](https://devsnap.me/css-menu) around the web.
 
 * Pros: A navigation menu which uses only CSS styles is technically much
   simpler, lacking the javascript that would need to be maintained (either by
   ourselves or by a dependency maintainer).
 
-* Cons: These types of navigation systems are likely not going to be fully
-  accessible. There are elements of the WCAG standards which cannot be satisfied
-  by stylesheets alone. An example is WCAG 1.4.13, which requires that revealed
+* Cons: [These types of navigation systems are likely not going to be fully
+  accessible](https://moderncss.dev/css-only-accessible-dropdown-navigation-menu/). There are elements of the WCAG standards which cannot be satisfied
+  by stylesheets alone. An example is [WCAG 1.4.13](https://www.w3.org/WAI/WCAG21/Understanding/content-on-hover-or-focus.html), which requires that revealed
   content like a submenu must be dismissable without changing the focus on a
   page.
 
+
 ### Option 4: A bespoke solution
 
 While attempting to implement the Accessible Menu library, we asked for feedback