1. Advertising
    y u no do it?

    Advertising (learn more)

    Advertise virtually anything here, with CPM banner ads, CPM email ads and CPC contextual links. You can target relevant areas of the site and show ads based on geographical location of the user if you wish.

    Starts at just $1 per CPM or $0.10 per CPC.

Aria issues with navigation menu bar

Discussion in 'HTML & Website Design' started by Soupi, Feb 13, 2020.

  1. #1
    I have a menu bar but
    It seems like I had the functionalilty wrong, according to this page https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

    the menu bar should open with the down arrows, and navigate via up and down keys, to go to the next tab you should be pressing left or right not TAB, tab should get out of the menu itself and on to the content... how can i do this with the given code i have above. thank you

    
    <!DOCTYPE html>
    <html lang="en">
    
    <head>
        <meta name="viewport" content="width=device-width, initial-scale=1">
        <!--Author URL: https://codepen.io/andornagy/pen/RNeydj
    Description: A Generic Hierarchical Menu Navigation
    Version: 1-->
        <style>
            /* CSS Document */
            body {
                background: #212121;
                font-size: 22px;
                line-height: 32px;
                color: #ffffff;
                margin: 0;
                padding: 0;
                word-wrap: break-word !important;
                font-family: 'Open Sans', sans-serif;
    
    
    
            height: 100vh;
            /*100% of the viewport*/
            display: flex;
            flex-direction: column;
        }
    
        main#content {
            flex: 1;
            overflow-y: scroll;
        }
    
        h1 {
            font-size: 60px;
            text-align: center;
            color: #FFF;
        }
    
        h3 {
            font-size: 30px;
            line-height: 34px;
            text-align: center;
            color: #FFF;
        }
    
        h3 a {
            color: #FFF;
        }
    
        ul {
            list-style-type: none;
        }
    
        nav>ul {
            display: flex;
        }
    
        nav>ul>li {
            position: relative;
        }
    
        nav>ul>li>ul {
            padding: 0;
            top: 100%;
            left: 0;
            position: absolute;
        }
    
        input:checked~ul {
            display: block;
        }
    
        button::after {
            content: '\25bc';
        }
    
        li:focus-within>button::after {
            content: '\25b2';
        }
    
        a {
            color: #FFF;
        }
    
        h1 {
            margin-top: 100px;
            text-align: center;
            font-size: 60px;
            line-height: 70px;
            font-family: 'Bree Serif', 'serif';
        }
    
        #container {
            margin: 0 auto;
            max-width: 890px;
        }
    
        p {
            text-align: center;
        }
    
        /* Giving a background-color to the nav container. */
        nav {
            margin: 0;
            padding: 0;
            background-color: #E64A19;
        }
    
        #logo {
            display: block;
            padding: 0 30px;
            float: left;
            font-size: 20px;
            line-height: 60px;
        }
    
        /* Since we'll have the "ul li" "float:left"
     * we need to add a clear after the container. */
    
    nav:after {
        content: "";
        display: table;
        clear: both;
    }
    
    /* Removing padding, margin and "list-style" from the "ul",
     * and adding "position:reltive" */
            nav ul {
                float: right;
                padding: 0;
                margin: 0;
                list-style: none;
                position: relative;
            }
    
    /* Positioning the navigation items inline */
    nav ul li {
        margin: 0px;
        display: inline-block;
        float: left;
    }
    
    nav button {
        border: none;
        height: 100%;
    }
    
    /* Styling the links */
    nav a,
    nav button {
        display: block;
        padding: 14px 20px;
        color: #FFF;
        font-size: 17px;
        text-decoration: none;
        background-color: #E64A19;
    }
    
    nav ul li ul li:hover {
        background: #000000;
    }
    
    /* Background color change on Hover */
    nav a:hover,
    nav button:hover {
        background-color: #000000;
        text-decoration: underline;
    
    }
    
    input#drop {
        display: none;
    }
    
    /* Hide Dropdowns by Default
     * and giving it a position of absolute */
            nav ul ul {
                display: none;
                position: absolute;
                /* has to be the same number as the "line-height" of "nav a" */
                top: 60px;
            }
    
    /* Display Dropdowns on focus */
    nav ul li:focus>ul {
        display: inherit;
    }
    
    /* Fisrt Tier Dropdown */
    nav ul ul li {
        width: 170px;
        float: none;
        display: list-item;
        position: relative;
    }
    
    /* Second, Third and more Tiers   
     * We move the 2nd and 3rd etc tier dropdowns to the left
     * by the amount of the width of the first tier.
    */
            nav ul ul ul li {
                position: relative;
                top: -60px;
                /* has to be the same number as the "width" of "nav ul ul li" */
                left: 170px;
            }
    
    
        /* Making dropdowns tabbable */
        li ul {
            display: none;
        }
    
        li:focus-within ul {
            display: block;
        }
    
        /* hamburger icon */
        label.hamburger {
            position: relative;
            display: none;
            height: 50px;
            width: 75px;
        }
    
        .line {
            position: absolute;
            left: 10px;
            height: 4px;
            width: 55px;
            background: #fff;
            border-radius: 2px;
            display: block;
            transition: 0.5s;
            transform-origin: center;
        }
    
        .line:nth-child(1) {
            top: 12px;
        }
    
        .line:nth-child(2) {
            top: 24px;
        }
    
        .line:nth-child(3) {
            top: 36px;
        }
    
        input#drop:checked~label.hamburger .line:nth-child(1) {
            transform: translateY(12px) rotate(-45deg);
        }
    
        input#drop:checked+label.hamburger .line:nth-child(2) {
            opacity: 0;
        }
    
        input#drop:checked+label.hamburger .line:nth-child(3) {
            transform: translateY(-12px) rotate(45deg);
        }
    
        /* Media Queries
    --------------------------------------------- */
    
        @media all and (max-width : 768px) {
    
            #logo {
                display: block;
                padding: 0;
                width: 100%;
                text-align: center;
                float: none;
            }
    
            nav>ul {
                display: none;
            }
    
            nav>ul>li>ul {
                position: static;
            }
    
            /* Styling the toggle lable */
            .toggle {
                display: block;
                height: 50px;
                background-color: #E64A19;
                /* padding: 14px 20px; */
                color: #FFF;
                font-size: 17px;
                text-decoration: none;
                border: none;
            }
    
            /* Display Dropdown when clicked on Parent Lable */
            input#drop:checked~ul {
                display: flex;
                flex-direction: column;
            }
    
            nav ul {
                float: none;
            }
    
            nav ul ul {
                margin-left: 1em;
            }
    
            label.hamburger {
                display: block;
            }
    
        }
    
    
    
        @media all and (max-width : 330px) {
    
            nav ul li {
                display: none;
                width: 94%;
            }
    
        }
    </style>
    <title>Menu Navigation Test</title>
    </head>
    
    <body>
        <header>
            <nav>
               <div role="tablist" aria-label="Menu" id="logo">Syracuse University Libraries</div>
            <input type="checkbox" id="drop" />
            <label for="drop" class="hamburger" tabindex="1">
                <span class="line"></span>
                <span class="line"></span>
                <span class="line"></span>
            </label>
            <ul class="menu">
                <li><a href="">Home</a></li>
                <li>
                    <!-- First Drop Down -->
                    <button role="tab" aria-selected="true" aria-controls="about-tab" id="about">About</button>
                    <ul>
                       <div tabindex="0" role="tabpanel" id="about-tab" aria-labelledby="about"> <li><a href="#">Departments</a></li> </div>
                       <div tabindex="0" role="tabpanel" id="about-tab" aria-labelledby="about"> <li><a href="#">News</a></li> </div>
                    </ul>
    
                </li>
                <li>
                    <!-- First Drop Down -->
                   <button role="tab" aria-selected="false" aria-controls="rooms-tab" id="rooms">Rooms</button>
                    <ul>
                        <div tabindex="0" role="tabpanel" id="rooms-tab" aria-labelledby="rooms"> <li><a href="#">Resources</a></li></div>
                        <div tabindex="0" role="tabpanel" id="rooms-tab" aria-labelledby="rooms"> <li><a href="#">Links</a></li></div>
                    </ul>
                </li>
                <li><a href="">Special Collections</a></li>
                <li><a href="">Giving</a></li>
                <li><a href="">More</a></li>
            </ul>
        </nav>
    </header>
    
    <!-- Sample Text -->
    <main class="scroll" id="content">
        <h1>
            <p>This is a Generic Hierarchical Menu Navigation.</p>
        </h1>
        <p>This is a sticky Hierarchical Menu Navigation. It contains a dropdown functionality when clicked on. <br>When tabbing through it the dropdown menu opens on focus. <br>When minimized it turns in to a animated hamburger menu.</p>
    
    </main>
    <nav>
        <footer>
    
            Copyright © 2020 Syracuse University Libraries
        </footer>
    </nav>
    <!-- Core Javascript Bottom -->
    <script src="/assets/plugins/jquery-1.12.3.min.js" type="text/javascript"></script>
    <script src="/assets/plugins/back-to-top.js" type="text/javascript"></script>
    </body>
    
    
    </html>
    
    Code (markup):
     
    Soupi, Feb 13, 2020 IP
  2. qwikad.com

    qwikad.com Illustrious Member Affiliate Manager

    Messages:
    7,151
    Likes Received:
    1,656
    Best Answers:
    29
    Trophy Points:
    475
    #2
    qwikad.com, Feb 13, 2020 IP
  3. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #3
    What are you even talking about? Aria roles have nothing to do with keyboard navigation since 99%+ of visual UA's flat out ignore them. In fact, they're pointless code bloat because the ONLY reason they seem to exist is for when in some bizarre case you're using non-semantic markup and are trying to correct the meaning of the wrong tags. In which case, just don't use the wrong markup.

    Something exacerbated by the use of JavaScript where you don't need it, the mentally enfeebled DISASTER of developer ineptitude known as jQuery, classes for nothing, the derpy NAV tag that you wouldn't need if you just used numbered headings properly, DIV inside a LI doing the job of a H1 before the UL, DIV wrapping LI and P inside an H1 where it's complete gibberish / invalid markup, said H1 with the P inside it should semantically be an H2, dicking around with tab-index making your sub-menu elements unable to be focused on screen readers / braille readers... etc, etc, etc.

    Gibberish semantics + aria bloat + bad development techniques... hardly a wonder it's blowing 2.5k of markup and 6k of CSS on 355 bytes of plaintext; not even 1.7k of HTML and maybe 4k of CSS' job for what it's currently doing.

    I think you need to back up a bit and learn semantic markup and the basic structural rules of HTML before you start diving for scripting and ARIA. Might sound harsh, but that's what I'm seeing here. When you're putting DIV around LI as children of UL and P inside numbered headings, and not using numbered headings properly, you're not ready to be playing with ARIA, JavaScript, or even CSS.

    Hence why you've got pixel metric media queries with dynamic font sizes, resulting in your queries not kicking in where needed on my machine with the non-standard font metric.

    Also you shouldn't "copyright copyright". Use the symbol OR the word, not both. Mistake I see all the time..

    Though I suspect your REAL problem is you didn't include the JavaScript that actually makes any of the keyboard stuff work, which in point of fact would/should have nothing to do with the aria roles... and the way it's implemented on those pages could be considered a WCAG violation.

    But as I've said several places, the entire ARIA thing and the stuff they're trying to do with them reeks of the folks working on it -- much like a good chunk of HTML 5 -- not knowing enough about accessibility or usability to be involved in much of anything. I'm not sure I'd trust these clowns to tie their own shoes.

    You're not including these:

    https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/js/MenubarItemLinks.js

    https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/js/MenubarLinks.js

    https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/js/PopupMenuItemLinks.js

    https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/js/PopupMenuLinks.js

    Hence you're not getting the scripting "enhancement" (that's a downgrade since it breaks conventional browser controls, again a possible WCAG violation, certainly a violation of many contractual requirements found in banking, public utilities, medical care, and the like)
     
    Last edited: Feb 13, 2020
    deathshadow, Feb 13, 2020 IP
  4. Soupi

    Soupi Greenhorn

    Messages:
    48
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    16
    #4
    I tried adding the java-scripts to my code and it didnt work.
     
    Soupi, Feb 14, 2020 IP
  5. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #5
    Again, given that your markup is broken and bears little if any resemblance to theirs is a likely contributor to that. When you have invalid nonsensical markup that doesn't match the examples in question, of course it doesn't work.
     
    deathshadow, Feb 14, 2020 IP
  6. Soupi

    Soupi Greenhorn

    Messages:
    48
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    16
    #6
    Can you help me update my code so my issues do work?
     
    Soupi, Feb 18, 2020 IP
  7. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #7
    Well let's see what I can do here...

    The first order of business is to gut it down to just the semantics. PROPER semantics should provide everything accessibility UA concerns require WITHOUT any of that aria role nonsense or HTML 5 "structural" garbage.

    
    	<h1>Syracuse University Libraries</h1>
    
    	<ul id="mainMenu">
    		<li><a href="#">Home</a></li>
    		<li>
    			About
    			<ul>
    				 <li><a href="#">Departments</a></li>
    				 <li><a href="#">News</a></li>
    			</ul>
    		</li>
    		<li>
    			Rooms
    			<ul>
    				<li><a href="#">Resources</a></li>
    				<li><a href="#">Links</a></li>
    			</ul>
    		</li>
    		<li><a href="#">Special Collections</a></li>
    		<li><a href="#">Giving</a></li>
    		<li><a href="#">More</a></li>
    	</ul>
    	
    	<h2>Heirarchal Menu Demo</h2>
    	<p>
    		This is a sticky Hierarchical Menu Navigation. It uses normal dropdown functionality on hover, tabbing opens the menu opens on focus, and on small displays it becomes a modal dialog launched by a hamburger icon. Tabbing when the mobile menu is active also triggers the menu on modern browsers. No JavaScript is needed for modern browsers, and scripting is provided to add support in IE 10 and 11. 
    	</p><p>
    		I currently recommend that for IE9/earlier you use the old "conditional comments" to not feed them any CSS or Scripting allowing your semantic markup to do their job.
    	</p>
    	
    	<hr>
    	&copy; 2020 Syracuse University Libraries
    
    Code (markup):
    That's our starting point for the HTML.

    THE H1 (singular) being THE heading (singular) that glues all pages of a site together, hence the site name being your best candidate. H2 mark the start of major subsections of the page, with the first H2 marking the start of the main content, hence everything between the H1 and H2 being the heading and the H2 making the MAIN tag a pointless redundancy. Of course EVERY Anchor is navigation, so the NAV tag serves no purpose. The HR indicates a change in topic/subject, basically saying "this content is not part of the H2 preceding it... which one can assume is the footer which -- nuduh -- makes the FOOTER tag pointless too.

    Now I personally wouldn't use the HTML 5 tags, but I don't know if you or your client (if any) "require" them because they don't realize how silly they are, so we'll add that. I would also add INPUT and LABEL for the main menu toggle, SPAN around the submenu titles so we can dynamically add the dropdown arrow indicators. I'd also add an outer wrapping DIV#top to provide for a "modal dialog fix" so as to allow for a more useful (and attractive) handling of the dropdown menu, as well as so you can just do href="#top" to add a "back to top" link if desired. An extra DIV inside the NAV can be leveraged as a double-wrapper to get around grid and/or flex compressing top/bottom margin/padding behavior... the reason this is a concern is I would make the mobile menu behavior be a modal dialog so it doesn't cover the entire display. An extra label inside the NAV > DIV could then be leveraged to close the modal.

    So with the HTML 5 pointless redundancies and all our required markup:

    <!DOCTYPE html><html lang="en"><head><meta charset="utf-8">
    <meta
    	name="viewport"
    	content="width=device-width,height=device-height,initial-scale=1"
    >
    <!--[if !IE]>-->
    <link
    	rel="stylesheet"
    	href="menu.screen.css"
    	media="screen,projection,tv"
    >
    <!--<![endif]-->
    <title>Menu Navigation Test</title>
    </head><body>
    
    <div id="top">
    
    	<header>
    
    		<h1>Syracuse University Libraries</h1>
    
    		<input type="checkbox" id="toggle_mainMenu" class="toggle" hidden>
    		<label for="toggle_mainMenu"></label>
    		<nav>
    			<div>
    				<label for="toggle_mainMenu"></label>
    				<ul id="mainMenu">
    					<li><a href="#">Home</a></li>
    					<li>
    						<span>About</span>
    						<ul>
    							 <li><a href="#">Departments</a></li>
    							 <li><a href="#">News</a></li>
    						</ul>
    					</li>
    					<li>
    						<span>Rooms</span>
    						<ul>
    							<li><a href="#">Resources</a></li>
    							<li><a href="#">Links</a></li>
    						</ul>
    					</li>
    					<li><a href="#">Special Collections</a></li>
    					<li><a href="#">Giving</a></li>
    					<li><a href="#">More</a></li>
    				</ul>
    			</div>
    		</nav>
    		
    	</header>
    
    	<main>
    		<h2>Heirarchal Menu Demo</h2>
    		<p>
    			This is a sticky Hierarchical Menu Navigation. It uses normal dropdown functionality on hover, tabbing opens the menu opens on focus, and on small displays it becomes a modal dialog launched by a hamburger icon. Tabbing when the mobile menu is active also triggers the menu on modern browsers. No JavaScript is needed for modern browsers, and scripting is provided to add support in IE 10 and 11. 
    		</p><p>
    			I currently recommend that for IE9/earlier you use the old "conditional comments" to not feed them any CSS or Scripting allowing your semantic markup to do their job.
    		</p>
    	</main>
    
    	<footer>
    		<hr>
    		&copy; 2020 Syracuse University Libraries
    	</footer>
    	
    <!-- #top --></div>
    
    <!--[if !IE]>--><script src="menu.js"></script><!--<![endif]-->
    
    </body></html>
    Code (markup):
    Note I use the old IE CC's to not send our screen media layout or scripting to IE9/earlier. We're going to be using a lot of techniques -- flex, grid, :focus-within -- that legacy IE just plain chokes on.

    I'll be putting live copies here:
    https://cutcodedown.com/for_others/soupi/

    That final markup +/- a few minor corrections that may come up during styling: elivers the content semantically. Without the CSS
    https://cutcodedown.com/for_others/soupi/menu.base.html

    We're looking at what search engines, IE9/earlier, braille readers, screen readers, and accessibility based users get. This baseline should be the objective of your HTML instead of your HTML mostly dicking around for appearance. That's where 90%+ of the worlds developers cock up on the accessibility front and why idiotic trash like Aria came into being; a general lack of proper accessible HTML.

    Gimme a few to toss together some CSS to make that all work, as well as any scripting that's required. There should be no more changes needed to the markup because my experience let me add the DIV and SPAN prematurely, but in practice in most cases semantically neutral tags (DIV, SPAN) don't get added until the CSS is being written.
     
    deathshadow, Feb 19, 2020 IP
  8. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #8
    Here it is live with the CSS:

    https://cutcodedown.com/for_others/soupi/menu.html

    Note, I did NOT try to implement the arrow navigation because that's nonsensical trash that doesn't make it better. The arrows in the browser are supposed to be for SCROLLING the page, and overriding that behavior is both an accessibility violation and pisisng on UX. Normal tabbing however will walk you right through the menu. Likewise I made it hover dropdowns instead of click to open because that too is more consistent with conventional navigation and what people expect.

    ... and check out how I handle it on small screen. Works back to IE 10 thanks to the tiny bit of scripting assistance. Instead of browser sniffing I used capabilities detection. I left the submenus open because again the click to open is more hindrance than help and a waste of code that could compromise accessibility.

    Later today I'll write a breakdown explaining the CSS and JS if I have the time.
     
    Last edited: Feb 19, 2020
    deathshadow, Feb 19, 2020 IP
  9. Soupi

    Soupi Greenhorn

    Messages:
    48
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    16
    #9
    https://www.w3.org/TR/wai-aria-practices/examples/menubar/menubar-1/menubar-1.html

    thats the only reason i wanted to add the arrow function because it is accesbility required unfortuntly.

    how can i add those functions to this nicely done page that you have created https://cutcodedown.com/for_others/soupi/menu.html
     
    Soupi, Feb 19, 2020 IP
  10. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #10
    Alright, here's the completed page of how I'd go about that:
    https://cutcodedown.com/for_others/soupi/menu.html

    The directory is the same and wide open for access to the gooey bits and pieces. I included several different versions of the markup so you can see various stages of it.

    The CSS:
    https://cutcodedown.com/for_others/soupi/menu.screen.css

    Let's go over that.

    The first thing I put into every CSS file is a reset. There are smaller resets like the so-called "universal" one of "* { margin:0; padding:0; border:0; }" but it can wreak havoc styling form elements cross browser since IE, FF, and "rest of world" all disagree with each-other on how input/select/textarea should be padded. There are larger resets like Eric Meyer's "reset reloaded", but that nearly borders on being a framework in size and gives the concept of a reset a bad name.

    The one I use is a nice safe middle-ground. Created by Dan Schulz (rest well my friend) a deceased member of these forums, it resets just what NEEDS to be targeted and doesnt' go wild setting up things you are likely to either override or have different needs for later.

    A reset means we don't have to sit there micromanaging how FF, IE, and Chrome/Webkit based all disagree on what the defeult margins/paddings should be... so I consider it worth the quarter K or so.

    Next I have a couple bugfixes and common config choices. I've started telling browsers to use the box-sizing:border-box; because it's just easier to manage. The laugh of this is for decades people ranted and raves about IE's "broken" non-standard box model, yet here we are in 2020 forcing that exact same behavior with people heaping praise on it.

    I then also fix that IE11's default for flex is 1 1 instead of 0 1 like the rest of the world.

    The comment in there says it all, horizoontal rules are for semantics and structure, NOT "I want a line drawn across the screen" so we hide them for our screen media layout.

    Oh, I forgot to mention above when discussing the markup, notice how the LINK has a MEDIA attribute on it. Yes, HTML 5 validation will bitch about TV and PROJECTION... the W3C can sit on it and spin so far as I'm concerned with said "validation". There are plenty of devices that still "need" those values -- kiosks, msn tV, Wii/WiiU/DS -- to not apply their own style rules over ours, and really media targets should be NONE of the blasted HTML specifications business as it defeats why they exist, for VENDORS to declare new targets as new types of devices come alone.

    A good rule of thumb, if you don't see a media="" on a rel="stylesheet" LINK or STYLE tag, or you see media="all", you're looking at developer ignorance, incompetence, and/or ineptitude.

    Next is some fixes for older Windows and iOS phones who don't know what the viewport META is. Thankfully all devices that need this are 480px or narrower so I add that as a trigger. Why? Because sending these values to desktop makes OSX Safari unable to zoom in/out, even though it doesn't break it on iOS Safari. (way to go crApple, there's a reason us web dev's are now calling Safari "the new IE")

    From here out I'll explain via selector. I always start by making my legacy desktop layer first. A LOT of people say "mobile first" and I consider that completely back-assward. Any mobile device we care about can be targeted with media queries. You know what can't be targeted? Legacy desktop. Now, we're not going back on legacy support so far it matters, but it still makes more sense as it's often easier to take away than it is to add.

    html, body -- if we don't set this, our child elements can't have heights on them.

    body, button, input, table, textarea, select -- our default font size and face. Note I do this in EM.

    Across the entire layout whenever possible you should be using EM, not PX. Pixels are an epic /FAIL/ at web development as they do not auto-size to the user's OS / Browser preference. They're accessibility trash and shouldn't really be used for font-size, line-height, widths, heights, paddings, or margins. EM scales to the user size so those who run non-standard metrics like the 24px default on my workstation aren't sent diving for the zoom.

    Note, in most cases using PX on fonts and media queries is an accessibility violation. People will try to claim it's not and misquote the WCAG out of context on this... the only time PX is not a violation is when you have complete control over what the device and browser is going to be and how scaling is set. This is for a website, that section of the WCAG allowing it DOES NOT APPLY!!! Hence those who try to defend PX metric layouts are talking out their collective asses.

    body -- 1.375 em is roughly equal to the 22px you were declaring for "normal / 96dpi / vga / 100% / 16px / windows small" users, but for "large / 120dpi / 8514 / 125% / 20px / windows medium / pick a huffing name already" users such as my laptop and garage rigs, it's 27.5px, whilst on my media center's 4k display, it's 44px. That's the power of using EM instead of derpy old PX.

    .toggle -- I often use a lot of checkboxes these days to toggle values on and off. The "hidden" attribute in the markup works great for modern UA's, but IE and Edge won't let their checked/unchecked state change with it set to hidden... well, "hidden" is implemented as display:none in offending browsers, so all we need to do is set it to display:block and slide if off screen, and boom it's working in IE again.

    label -- as PROPERLY coded labels should be FOR="" an INPUT/SELECT/TEXTAREA, and clicking on the label should be the same as clicking on said associated FORM elements, why the blazes aren't labels set to cursor:pointer by default? Simple line, major UX improvement.

    #top -- I absolute position this as 100% size with a scrollbar so that our modals (if any) can overlap it. This way we don't end up with two scrollbars on screen if the modal is too big to show. We then treat it as our flex container which dodges some bugs of flex in IE 11. That we can get triple duty out of one container -- hash target, scrollbar fix, flex-container -- WELL worth the extra DIV.

    On the next few I'm using the child combinator so should subsections have their own HEADER or FOOTER we're not targeting those by accident.

    #top > header,
    #top > footer
    -- Share the color? Declare them together. This is why I say things like LESS/SASS/SCSS are pointless nonsense.

    #top > header -- min-height as we'll use floats for the H1 and menu, and IE 10 can't flex. From there just padding and alignment.

    #top > footer -- padding and font-size. Nothing to write home about.

    main as a document should only ever have ONE MAIN tag marking the main content, there's no reason to give it an id, class, or fancy selectors. We tell it to grow and shrink with the scrolling behavior, and pad the top/sides so that content only has to worry about bottom margin.

    main:after -- flex wants to collapse any bottom padding or margins no matter what, so instead I use generated content to keep it pretty with an extra element.

    h1 -- just as with MAIN, a page should only ever have ONE H1 (unless you use HTML 5's dumbass SECTION tag, and even then due to legacy compatibility it's a bad idea. I float it, pad it, shrink the default text size.

    #mainMenu -- float the opposite direction, yank the bullets, shrink the font size.

    #mainMenu li -- float left so they're in one line in the right order, positoion:relative so we can position the dropdowns properly.

    #mainMenu li.jsFocusWithin -- z-index for when they are focused so they depth sort to top.

    #mainMenu li:focus-within -- It's part of the CSS specification that an unknown selector makes the UA completely discard the entire declaration. Becasue IE doesn't know how to focus-within if we put the class for JS in alongside the :focus-within pseudo-state, neither declaration would work.

    this SUCKS, it means a LOT of this CSS is going to have to repeat itself... but it's still better than having to use JS for everything since in modern browsers it gives us scripting off graceful degradation for normal tabbed keyboard access. If you don't care about supporting any versions of IE, you remove the .jsFocusWithin and scripting, then combine this into the previous declaration.

    #mainMenu a,
    #mainMenu span
    -- again these share a lot of values so combine them. Relative positioning aids in depth sorthing during child modals if any, inline-block lets us pad the top and bottom as appropriate, pad them, vertical align them so they don't jump around when hovered, strip off outlines and underscores since we'll have our out focus styles, color them, and set up some nice transitions too.

    #mainMenu span:after -- the down pointing triangle

    #mainMenu a:focus,
    #mainMenu a:hover,
    #mainMenu li:hover > span,
    #mainMenu li.jsFocusWithin > span
    -- depth sorting when active, color change.

    #mainMenu li:focus-within > span -- even though it's the same as the previous ones, again we have to declare it separate because CSS rules suck.

    #mainMenu ul -- kill the bullets, slide them off screen to hide, make them a hair wider than the parent, center their text contents, and a hint of transform so we can make our dropdowns centered.

    #mainMenu ul,
    #mainMenu ul li:last-child a
    -- round the bottom to make it purty.

    #mainMenu ul li -- strip off the floats on the child ones.

    #mainMenu li.jsFocusWithin > ul,
    #mainMenu li:hover > ul
    -- show them by sliding into view.

    #mainMenu li:focus-within > ul -- again, same thing but separate thanks to CSS' rules for "unknown" handling and IE.

    #mainMenu ul a -- set the dropdown ones to block and pad them differently.

    #mainMenu ul a:focus,
    #mainMenu ul a:hover
    -- hover state colors, yawn.

    main p -- I set a max-width on P so that long lines aren't hard to follow, then center it since we're centering their text.

    main h2 -- make it big and centered.

    ... and that's the desktop layout. Now to make it mobile friendly.

    ***** @media (max-width:54em) *****

    h1 - Kill the float, make sure the H1 text is aligned left and apply a right margin.

    #toggle_mainMenu + label our hamburger icon. Rather than a bunch of "span for nothing" in the markup, let's use generated content for this. Absoltue position it into place, pad the inside, border it, round the corners, and give it a background transition for hovering.

    #toggle_mainMenu + label:before,
    #toggle_mainMenu + label:after
    -- Using generated content we can build the inner lines. Just make them empty content, display:block so they're one over the other, set the width which will also size the parent, then height and top/bottom border makes the lines...

    #toggle_mainMenu + label:after -- then remove the top border off of the bottom one, and we get three borders acting as our lines.

    #toggle_mainMenu + label:hover -- background on hover. Yawn.

    #top > header > nav,
    #top > header > nav label
    -- these share the same full screen sizing and positioning. Whilst the nav won't be position:absolute I declare it here so I don't have to declare the label's selector again.

    This is where the magic starts to happen. For now remember that a LABEL with a FOR on it is the same as clicking on the INPUT that it's ... for.

    #top > header > nav I use grid for vertical centering because flex tends to not like to let you have scrollbars. The fixed positioning makes sure that as a modal container it will be present regardless of our scroll, then we slide it off the left-hand side of the screen to hide it. From there we just set up scrolling behavior and a transparent background with box-shadow to make it attractive. Look, our NAV tag is now a modal container.

    #top > header > nav > div -- again flex and grid love to collapse margins and padding at the top and bottom when the screen is small, so this container handles that for us.

    #toggle_mainMenu:checked ~ nav,
    #toggle_mainMenu ~ nav.jsFocusWithin
    -- and here's our magic! When the input is checked or the children of our modal menu are hovered, shwo the menu by sliding it into place. By playing with the transition we can even make it fade in/out of view.

    #toggle_mainMenu ~ nav:focus-within -- and as before we have to double-up on our scriptless declaration to support legacy IE.

    #top > header > nav label -- our inner label even though it's absolute positioned behaved oddly in IE 10, but display:block somehow fixes that. Don't ask me why. The center alignment makes adding our "up arrow" close hint easier to position. Finally a sneaky trick using SVG lets us use a UTF-8 up pointing triangle as our cursor on the close areas helping to tell the user that clicking anywhere outside the modal will close it.

    #top > header > nav label:before -- even sneakier trick? use borders to make that close triangle.

    #mainMenu -- kill the float, position it relative with a top offset to make it appear to "slide in" when the parent is activated via transition, rest of this is just centering, colors, etc.

    #toggle_mainMenu:checked ~ nav #mainMenu ,
    #toggle_mainMenu ~ nav.jsFocusWithin #mainMenu
    -- slide it into it's normal position when the modal is open.

    #toggle_mainMenu ~ nav:focus-within #mainMenu .. and yet AGAIN...

    #mainMenu li no float and space them apart.

    #mainMenu a,
    #mainMenu span
    -- block so they can still be padded and expand to fit their parent's width.

    #mainMenu a -- pad them differently and color them.

    #mainMenu a:hover,
    #mainMenu ul a:hover
    -- stating the specificity of the children lets us avoid using !important, otherwise this is just a normal hover state.

    #mainMenu a:focus,
    #mainMenu ul a:focus
    -- do the same with focus, but make it a bit more... visible to help keyboard navigators find their way.

    #mainMenu span,
    #mainMenu li:hover > span,
    #mainMenu li:focus-within > span,
    #mainMenu li.jsFocusWithin > span
    -- a lot to override in the mobile version to make these all behave the same. In the mobile version we want these as simple headings.

    #mainMenu ul -- setting these to static just makes them behave like normal list again. I add a simple border at the bottom to differentiate them from other sections of choices.

    #mainMenu ul li:first-child a,
    #mainMenu ul li:last-child a
    -- and of course they no longer need rounded corners.

    #mainMenu span:after -- likewise let's axe off the down arrows since they're no longer hover targets.

    ... and that's 99%+ complete. Since you have such a batshit large font across the body, the rest of the stylesheet is just shrinking the fonts down to more reasonable sizes the smaller the display, since 1.375em / 22px is a pretty massive fist-in-the-face for most 800px and narrower mobile devices.

    ... and that's how the CSS works.

    AGAIN, no arrows for the menu or click based states for the submenus, but on the whole those aren't things one should be wasting code on implementing in the first place. Especially if with focus-within or a simple scripted .focus-within class+script for legacy IE can implement things the "normal way".

    Though if I were to try, your submenu's would be triggered by input:checked the same as the hamburger menu is for touch.

    The script is relatively mundane.

    https://cutcodedown.com/for_others/soupi/menu.js

    It just does querySelectorAll to grab all focusable elements, and when they focus or blur a class is added or removed from their parent elements right up to but excluding BODY. This lets us with scripting enabled use .focus-within anyplace we could use :focus-within in modern browsers. I wrap it all in a SIF/IIFE so that the code is invisible to any other scripting you might want to add.

    A more complete implementation might try to parse the stylesheet to change all the :focus-within to someting else, but that's tricky and would require WAY more code.

    I know that's a lot to take in, so read up on it, and fire away with any questions.
     
    deathshadow, Feb 19, 2020 IP
  11. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #11
    The arrow ICONS being generated content in the CSS are a requirement, and we have that. Arrow KEY functionality is NOT part of any standards track I'm aware of for menu navigation, if anything it's a VIOLATION because you're overriding the default UA behavior of those keys!

    If somewhere in that aria trash it says that, it's directly conflicting with good accessibility practices. Though to be frank, that seems to be a good chunk of what Aria roles exist to do. Replicate existing sematics giving people excuses to use the wrong tags, and add pointless code bloat in the NAME of being more accessible whilst in action pissing on accessibility.

    ... all because I suspect that much like the folks at the WhatWG who added the derpy HTML 5 "structural tags", the folks who created ARIA didn't know enough about HTML to be doing anything involving it. Much like the folks who create trash like HTML/CSS frameworks being utterly unqualified to flap their damned yap on the topic of writing HTML/CSS.

    Bottom line, modifying what the arrow keys DO is an accessibility violation, not a requirement. Trust me, my bread and butter is accessibility consulting to companies stuck in litigation and paying fines for it.

    -- edit -- side note, anyone telling you to add JavaScript or use scripting only functionality to "enhance" accessibility is flapping their arse cheeks in the wind, and needs a quadruple helping of sierra tango foxtrot uniform. It is a guaranteed indicator they don't know what they're talking about.
     
    deathshadow, Feb 19, 2020 IP
  12. Soupi

    Soupi Greenhorn

    Messages:
    48
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    16
    #12
    Isnt aria needed in to the code for accessibility purposes... where in the html would i add that ??
     
    Soupi, Feb 19, 2020 IP
  13. Soupi

    Soupi Greenhorn

    Messages:
    48
    Likes Received:
    0
    Best Answers:
    0
    Trophy Points:
    16
    #13
    I also needed the dropdown boxes to stay closed untill i open it with enter key or space
     
    Soupi, Feb 19, 2020 IP
  14. deathshadow

    deathshadow Acclaimed Member

    Messages:
    9,732
    Likes Received:
    1,998
    Best Answers:
    253
    Trophy Points:
    515
    #14
    Aria does NOTHING for accessibility despite the wild claims, because only ONE legitimate UA -- crApples sloppy "screen reader" that's actually useless for the blind compared to JAWS -- uses it... and when it uses it the ONLY thing it does is the WAI roles which only seem to exist for when you're using the wrong markup.

    Seriously, read the WAI Aria Roles section and every blasted property basically says "when using the incorrect tag"

    How about instead of slopping more idiotic garbage code onto the incorrect tag, one just uses the CORRECT tags? I know, I know, crazy old Jason talking about semantic markup and using HTML properly again...

    Literally Aria seems to exist for the people who use DIV for everything because they're too lazy to use the correct tags or learn what any of them mean. Not ONE of the WAI Aria roles serves any legitimate purpose other than sating the wants and desires of people too lazy to learn what the tags mean and/or are for grammatically/semantically. The extended roles you get outside of that are even worse with no legitimate UA's using them for a damned thing, This is only exacerbated by the fact the ONLY other UA's that try to use them for things are data scrapers... or to use the proper name for those sleazy dirtbags, "Content Thieves". Aka the type of people site owners should want to keep out of their content!

    Again, kind of like HTML 5's derpy "structural tags" which are equally redundant to other markup you should have in the first place!

    Basically, Aria roles are ignorant incompetent BS and just more proof that the W3C has gone full-on schizophrenic.

    It can be done once they are focused, kind-of... but I REALLY advise against it. Just like the arrow navigation that's non-standard behavior that could (depending on implementation) be more of an accessibility violation than a help.
     
    deathshadow, Feb 21, 2020 IP