Acessible Dropdown Menus Options

[tsrplatelayer]

I am in the process of creating a website, it is not yet live so the only link is to a version on my own desktop, it will only work if I am home and the computer is turned on My Webpage
I have the nav menus working as I want, but they only work with a mouse. Using a keyboatd to nav I can step around but not activate or move down into the dropdowns. Also I would like to make them properly aria ready.
See Aria Menus
Please can someone help with the coding. Here are two of the 6 dropdowns

CODE

<nav class="row">
    <div class="dropdown">
          <button class="dropbtn">About<br>Us</button>
          <div class="dropdown-content">
           <a title="Return to the Homepage" href="index.php">Homepage</a>
            <a title="Link to a page outlining the aims of the Caughley Society" href="aims.php">The Society's Aims</a>
            <a title="Link to a page explaining how the Caughley Society handles your data" href="privacy.php">Privacy Policy</a>
            <a title="Link to a page containing a list of links to other porcelain related sites" href="links.php">Links to other Sites</a>
          </div>
    </div>
    <div class="dropdown">
          <button class="dropbtn">Publications</button>
          <div class="dropdown-content">
            <a title="Link to page about the Blue and White Pattern Book and how to order it" href="pattern_book.php">The Blue and White Pattern Book</a>
           <a title="Link to page about the Polychrome Book and how to order it" href="poly_book.php">The Polychrome Book</a>
            <a title="Link for details of our next meeting" href="meeting.php">Our next Meeting</a>
            <a title="LInk to details of our quarterly newsletter" href="newsletters.php">Our Newsletter</a>
            <a title="Link to an index of the contents of all our published newsletters from issue number 1" href="mag_index.php">Index of Newsletters to-date</a>
            <a title="Link to deatils about how to submit an article for inclusion in our newsletter" href="authors.php">Guidance for Authors</a>
        </div>
    </div>

Here is the CSS

CODE

.dropbtn {
  background-color: #04806D;
  color: white;
  padding: 12px;
  font-size: 15px;
  border: none;
}

.dropdown {
  position: relative;
  display: inline-block;
}

.dropdown-content {
  display: none;
  position: absolute;
  background-color: #f1f1f1;
  min-width: 150px;
  box-shadow: 0px 8px 16px 0px rgba(0,0,0,0.2);
  z-index: 1;
}

.dropdown-content a {
  color: black;
  padding: 12px 16px;
  text-decoration: none;
  display: block;
}

.dropdown-content a:hover {background-color: #ddd;}

.dropdown:hover .dropdown-content {display: block;}

.dropdown:hover .dropbtn {background-color: #8e41;}

.row {
  display: flex;
  flex-wrap: wrap;
  background-color: #191970;
  color: #ffffff;
}

[Christian J]

I have the nav menus working as I want, but they only work with a mouse. Using a keyboatd to nav I can step around but not activate or move down into the dropdowns.

The simplest way to do this might be with the DETAILS element. Such a menu opens by focusing it with the (Windows) Tab key and then pressing Enter, after which you need to Tab again to navigate the links inside it.

Also I would like to make them properly aria ready.
See Aria Menus

Alas I know nothing about ARIA. One requirement is: "When a menu opens, keyboard focus is placed on the first menu item". Do they mean the first menu item should receive focus automatically by opening the menu? That seems like overkill, but it might be possible with javascript. Or do they just mean that tabbing inside the menu will use the default tabbing order (as opposed to one with the order changed by TABINDEX)?

[pandy]

Isn't that misusing DETAILS though? I don't know. I'm asking.

[Christian J]

The spec sounds like it can be used for all sorts of things:

"The details element represents a disclosure widget from which the user can obtain additional information or controls."
https://html.spec.whatwg.org/multipage/inte...details-element

Then again I'd expect the spec to explicitly suggesting it for nav menus, considering how obvious that usage seems. On the other hand the spec doesn't explicitly discourage it either, like it does about using it for footnotes:

"The details element is not appropriate for footnotes. Please see the section on footnotes for details on how to mark up footnotes."

The HTML spec sometimes seems a bit vague about the semantic use of elements. If so that seems strange, because as a spec writer, you surely don't invent new elements before knowing what their intended purposes are?

[tsrplatelayer]

Thanks guys - didn't get anywhere with 'detail'.
I found a 'disclosure' method on W3C which has come closest to working. KYBD and Mouse navigable menus.
As this is not yet on a public facing server and I will be aaway for 2 weeks I have attached the files.  menu.zip ( 6.66k ) Number of downloads: 115

aims3.php (the top level page code), 'includes' css, menu and footer file. Temporarily (until I get it working) the JS and CSS associated with the menu are embedded in the menu file. (ignore the colours, they are just to help me see what area is what and can be fixed later

1. You will notice that the logo/banner shrinks/grows as the viewport is resized. However the nav bar does not. That isn't an issue but may be a route to a fix.
2. When the screen width get small the nav menu items wrap around - that's ok by me but..
3. When nav bar wrapped and an upper row menu is selected the dropdown appears behind the botton row nav items
4. The dropdowns are too narrow and I can't figure out why.

If any one has any time to take a look this 70 year old dog, struggling to learn new tricks, could sure use a hand!!

I have also attached my first version.  aims.zip ( 4.07k ) Number of downloads: 78
It works well with a mouse, wrapping and dropdowns not behind and are a good width. But I cant work out how to add the JS from the version above to make kybd nav work.

This post has been edited by tsrplatelayer: May 20 2023, 10:29 AM

[Christian J]

Thanks guys - didn't get anywhere with 'detail'.

What's wrong with it?

[pandy]

The HTML spec sometimes seems a bit vague about the semantic use of elements. If so that seems strange, because as a spec writer, you surely don't invent new elements before knowing what their intended purposes are?

Indeed. But intuitively I feel there should be a reason for the content to be hidden initially. Like if it's a spoiler. A reason other than layout, I mean.

[Christian J]

I suppose a large nav menu could be considered a distraction from the page's other content. But the same could be said for large footnotes, that the spec thinks DETAILS is inappropriate for.

However the reason DETAILS is inappropriate for footnotes could simply be because there are already layout conventions for footnotes, as mentioned on https://html.spec.whatwg.org/multipage/sema....html#footnotes --and not because there's anything semantically wrong with the DETAILS element itself. Similarly, one could argue that there's already a convention for hiding large nav menus, and that DETAILS fit that layout convention, while also providing a more convenient and consistent technical solution than the usual JS/CSS solutions.

[tsrplatelayer]

Ina queue at the airport - I'llget back when I get back

[pandy]

I suppose a large nav menu could be considered a distraction from the page's other content. But the same could be said for large footnotes, that the spec thinks DETAILS is inappropriate for.

Then it's definitely inappropriate for a menu.

However the reason DETAILS is inappropriate for footnotes could simply be because there are already layout conventions for footnotes, as mentioned on https://html.spec.whatwg.org/multipage/sema....html#footnotes --and not because there's anything semantically wrong with the DETAILS element itself. Similarly, one could argue that there's already a convention for hiding large nav menus, and that DETAILS fit that layout convention, while also providing a more convenient and consistent technical solution than the usual JS/CSS solutions.

Bah. That's just a bunch of Ps. It's not like there's an element FOOTNOTE. How on earth did they miss that, considering all the esoteric stuff they've come up with?

[Christian J]

Ina queue at the airport - I'llget back when I get back

Have a safe journey! In the meantime, apologies for our off-topic rantings.

[Christian J]

Bah. That's just a bunch of Ps.

Hence my phrase "layout convention" --no new HTML elements are required; just internal links pointing to the footnotes, and from them back to the main content again (like in Wikipedia articles, IIRC).

The first example with TITLE atributes seems like a bad idea though, --can you even copy text from a TITLE tooltip?

It's not like there's an element FOOTNOTE. How on earth did they miss that, considering all the esoteric stuff they've come up with?

Maybe they could repurpose the link REL attribute for the links, perhaps together with a custom link type. I'm sure that would help an AI bot match footnote and main text in Wikipedia articles.

[pandy]

It's a bunch of Ps. And I don't even see how that silly dialogue is typical footnote content. And footnotes are usually numbered. They must have been smoking something other than tobacco. And probably not just this once. And no, AFIK title content can't be copied.

[Christian J]

It's a bunch of Ps. And I don't even see how that silly dialogue is typical footnote content. And footnotes are usually numbered. They must have been smoking something other than tobacco. And probably not just this once. And no, AFIK title content can't be copied.

I was thinking more of the second HTML example --it does use the SUP element, numbering and a link to the footnote. I'm not even sure the first example is meant as a footnote example (they call it a short inline annotation).

---

Going back the DETAILS element, it's described as a "widget". Since it mostly seems to affect presentation, maybe it should ideally have been created as a CSS property (instead of as an HTML element), except that CSS can't handle mouse clicks or keyboard press events easily.

I wonder if the DETAILS "widget" gives any semantic meaning to its content? It's child elements certainly can have their own semantic meanings (like say a UL list inside DETAILS), but perhaps the DETAILS element de-emphasizes its content a little bit, similar to the SMALL or ASIDE elements? Speaking of which, ASIDE is actually suggested for "groups of NAV elements" (why would one use NAV groups?): https://html.spec.whatwg.org/multipage/sect...e-aside-element

This post has been edited by Christian J: May 23 2023, 06:24 AM

[pandy]

I didn't see there were more. But you must mean the third. When they came up with the second they must have been high as kites. 😂

[Christian J]

More specifically, the one with Mr Polevaulter. I think all the examples are suspicious!

[pandy]

Yeah, crazy text that I don't see why it would be in footnotes in the first place.

[Christian J]

I suppose they're trying to entertain themselves and their readers best they can.

[pandy]

Maybe they were hixied! 😂

[tsrplatelayer]

Well back fom my trip and done a bit more work on my original question.
this article about sums up why I didn't use <select>. I just couldn't get it to work and look like I wanted.

However I did find some helpful code at
W3 Aria Authoring Practice Guide
and here on the same website.

From this I now have a menu that does wnat I want, just have to finish developing the rest of the site before I can make it go live.