Ugh, I’m soo tired dealing with the extra level of complication, for something that’s already complicated enough. I have to think in all these layers, like a spider web of code weaved ontop of my other code and it’s driving me absolutely bonkers!
I can’t be the only one who feels this way ? Though I never see anyone complain about this.
I understand why it’s needed, but it’s such an immense headache!
I must be going about this wrong, or I’m just an idiot
Thanks for letting me rant 
Perhaps you can give a few examples of what is making you hate it?
Personally, I find the challenge of making things accessible very rewarding. Not only is it the right thing to do, but just the process of testing and experimenting in order to make something that works for everyone is interesting and fun.
Maybe if you’re better at it and actually get paid to do all this work, it’s ‘fun’, but right now it’s a nightmare to me.
Surely, you felt this way too in the beginning when you were learning the ropes?
You’re an expert by now so it’s easy, once something is easy it’s no longer something crappy .
I would say that anyone who wants to be a serious web developer nowadays should know the basics about accessibility, and that knowledge will prevent at least 50% of basic accessibility issues. Knowing accessibility should be considered a part of web development, just like knowing HTML/CSS/JS. It should not be treated as some sort of add on that is only left to the experts. So I would look at it like this is part of your core knowledge that you need in order to do web development properly. Learning anything new can be frustrating. But at some point in the past you had to learn HTML, CSS, and JS. Were those always super fun and not frustrating?
But yes, there are parts of accessibility that are complicated (and possibly there is no one “correct” answer) and you probably will need a specialist to help out. We can’t all be experts on everything. But you didn’t give any examples about what you consider a nightmare about accessibility, so I don’t know where your current frustrations fall on the scale of accessibility difficulty.
I understand it’s essential knowledge that’s why I’m working with it now and going through this struggle.
right now, I have a menu toggle button outside of the menu nav. The menu is never hidden , just placed off screen with left: -9999px , and shown again when needed with left: 0.
I think this is accessible, I read that the button should not be outside, but it was harder to solve with the toggle inside as I had so much completed already. So I went with the off screen positioning, instead of display:none
Still not sure if this is acceptable, I hope it is .
Thanks
You want display: none.
Basically, if the button can’t be accessed with the mouse then it shouldn’t be accessible by the keyboard. Moving it off screen allows it to still be accessible with a keyboard. Setting display to none removes the button completely from the DOM and thus it would not be accessible by keyboard.
but how is this accessible ? See this is what’s confusing and frustrating me.
I read this here:
and here I read this , under placement
article
I have one solution using display:none
https://github.com/cmb347827/display-none-github.io
And here after 2 days work, as I first tried positing the button in the menu which did not work , I did this left: -9999px
https://github.com/cmb347827/position-left-github.io
So I should go with display:none? I’m just confused about this still
Does my display:none github code look acceptable for the rest, and for the menu buttons in terms of accessiblity?
I would need to add the aria that I added in the later left-9999px version?
Thanks
I tested both for keyboard accessiblity and only the left:-9999px version works well in for both desktop and mobile. In mobile at least to tab to the button and it opens, but I would have to add keyboard access for the features and company menus.
So your not the only one who feels this way, but few complain because what your talking about is more or less the job description. At its core, your talking about dealing with complexity.
Accessibility could and actually is overthought about all the time. Its easy to overlook, easy to bypass and easy to forget about. However, it is also something that has legal repercussions. (ref)
I usually compare accessibility to security. You could make things work without either, but bypassing it usually just results in more work down the line, in a form of technical debt. However unlike some technical debt there’s visible legal and financial costs to this debt.
I’d go with display: none, its more approachable, cleaner and designed for this kind of problem.
The final aspect of all this “dealing with complexity” is the aspect, when you build something you want to keep things as complex as required and nothing more. Making things more complex than is required could confuse you, or anyone else in the future. This is a form of technical debt, where you are creating what is essential “legacy code” that may need to change in the future. Its one thing to make a decision early that seems like a good idea, only to find out later it was the wrong decision and having to fix it. Its another to make a known bad decision that may lead to problems down the line.
So ya, definitely one of the confusing things about accessibility is that there is a lot of information out there about it but not all of it is up to snuff. And finding the right information isn’t always easy (which is a fault of the accessibility community as a whole). I don’t want to be too critical about the links you gave above. but I will say that they are steering you in the wrong direction.
For example, a navigation menu (like the one you are creating) should not be using menu and menuitem roles. Those roles are meant to be used for what we think of as more “traditional” menus in software, such as a menu that would allow you change settings or perform some action. For navigation menus such as yours you really don’t need to do too much special. The button that expands/contracts the menu (the hamburger button in your case) needs the aria-expanded attribute. And then you need to hide the menu when it is not expanded by using something like display: none. It’s really about as simple as that. Here are a few links to how that would work.
W3C ARIA Authoring Practices Guide: Example Disclosure Navigation Menu
Adrian Roselli: Don’t Use ARIA Menu Roles for Site Nav
Adrian Roselli: Disclosure Widgets
Also, take a look under the hood at how the Menu button at the top right of the FCC website works.
As for when the page is wide enough that you don’t need the toggle button, you must effectively remove it from the DOM so that keyboard users can’t access it and screen reader users can’t discover it. The most common way to do this is to use display: none. If you wanted to use the position left trick then you would also need to add aria-hidden="true" (to keep assitive tech like screen readers from seeing it) and tabindex="-1" (to keep keyboard users from accessing it). But why go to all that trouble when you can just do display: none?
Because the functionality of a menu like this is not provided by native HTML elements, the potential for accessibility issues increases since you the developer must add JS to make it more accessible. As I said above, since this is a simple navigation menu, you only need to manage a few things, so I’m confident you can do it.
While we are at it, a few more accessibility concerns.
Don’t use a div when what you want is a button. The hamburger toggle button is just that, a button, and thus you should use the button element. Adding role="button" does not automatically turn the div into an actual button. For example, you can’t access the “button” with a keyboard because divs are natively focusable. So you would need to add tabindex="0" to the div. Also, buttons can be activated by both the space bar and the enter key. Did you take both of those into account for the click handler you added to that div? You actually can’t because a click handler won’t recognize a space bar as a click. So you would have to add a keypress handler to catch the space bar.
In this case, you have unnecessarily introduce accessibility issues by using a div instead of a button. If you switch that to a button then you can just use on click handler and it will work with either the space bar or enter key (and you won’t need to add a tabindex). This is one of those examples in which using the correct HTML enhances accessibility for free while using incorrect HTML reduces accessibility and adds more unnecessary work to make it accessible. This is what I meant by knowing the basics of accessibility, such as using semantically correct elements, will reduce your accessibility issues.
UPDATE: Ahh, I see, you used a div on one of them and a button on the other. Sorry, I should have checked both. So ya, keep on using those buttons!
P.S. Sorry @bradtaniguchi, I accidentally replied to your post instead of the OP.
So looking at my solution using display:none, I already hide the toggle button in desktop view. And I will add aria-expanded, like I added in my left:-9999px solution.
I did not add menu roles , I just used Jquery ui menu. So I can’t use that because of build in roles?
I just want to be sure I’m doing it correctly now , as this has stressed me out so much as I had completed so much already and then I read about the toggle button needing to be inside a menu , breaking everything.
The fact my toggle button is on the outside is fine ?
Thanks! You’ve been most kind and helpful
I’m well aware of the legal issues, I’m doing everything I can to make my code more accessible. I spend probably about 50% of my time now dealing with that. And focusing on accessbility has been more new to me. I’ve heard/read about it in the past but only now focusing on it, and it’s confusing because I’m still learning and online resources are useless.
I’m not exactly sure what you mean by this. The toggle button should come right before the list that is acting as the menu:
<button aria-expanded="(true or false)">...</button>
<ul>
<li>...</li>
<li>...</li>
<li>...</li>
</ul>
Since this is your main navigation menu then you would normally put all of this inside the nav element at the top of the page. Again, I will suggest you take a look at how the main menu toggle button is implemented in FCC.
I will be happy to take a look at your most updated version. Please let me know which one that is.
Thank you. I will have it , mostly , ready by tomorrow. If you could take a look then that would be fantastic 
Just to be clear, I can use Jquery menu ui ? Or does it come with build in menu roles that make it a bad choice? It’s vague to me what constitues a menu or not, visually this looks like a menu.
Thanks
I don’t know. I haven’t use the jQueryUI in ages. But if it is adding role="menu" and role="menuitem" to things then that is not what you want.
Yes, this can be confusing. We commonly refer to anything that is a list of links at the top of a page a “menu”. But when it comes to the ARIA menu role, it means a very specific type of menu. There are very few use cases for using an actual ARIA menu. Most of the “menus” you will create are what we call disclosure widgets. You click a button to expand the list and then you can tab through it with the keyboard.
If you want more reading, below is a link to an article that goes into much more depth about what the various things we add to web pages should be called.
Oke here’s what I have. Hopefully ok for accessbility.
Please let me know what you think 
https://github.com/cmb347827/intro-section-with-dropdown-navigation-main-display-none-version
Thanks!
Hey this is almost there. Great job. There is one issue that absolutely needs to be fixed, but hopefully it won’t take you too long to do.
I know it seems like the aria-expanded attribute should go on the list, since that is what is being expanded, but it actually goes on the button. So you’ll need to change that for all three buttons in your menu. Each button should start with aria-expanded="false", and then toggle to aria-expanded="true" when you click on it to expand the menu, and then back to aria-expanded="false" when you click on the button again to close the menu.
There are also a few minor issues that should be fixed as well. One is the use of aria-label. You only need to use aria-label if there isn’t text already available to give the element a name. For the submenu buttons, you have actual text inside the button so you don’t need aria-label on those buttons. And since every link in the menu has text then you don’t need aria-label on those. Basically, you can get rid of the aria-labels on the submenu buttons and all links in your menu because they are all doing unnecessary work. This is a best practice and basic rule of ARIA: only use ARIA attributes when absolutely necessary.
As a side note, most of your aria-labels are basically the same as the actual text in the element except you have added “link to …” or “opens the … submenu”. This is not needed. Screen reader users already know that something is a link or something is a button that opens something. You don’t need to include this extra “helper” text because it just causes unnecessary words to be read to them which is tedious and possibly confusing.
Another issue that should be fixed is the alt text on the icons in the Features submenu. Those would be considered “decorative” text and thus should have empty alt text (i.e alt=""). That way screen readers will ignore them and just announce the actual text for the link. Another way to hide these decorative images from screen readers is to add aria-hidden="true" to them. You have done this for the up/down arrows on the submenu buttons (which is great). I would just add that generally, if you are using aria-hidden="true" to hide an image then you don’t need alt text for it, so you could use alt="" on the image.
For the hamburger button, you have hidden the images with aria-hidden="true" (again, this is perfectly fine, and you could set the alt text to alt="") but in this case you don’t have any actual text inside the button so you do need to use aria-label to give it a name (which you have done). Naming elements with aria-label is a skill in itself. Generally, you want it to be as short as possible and just describe the element. Since this button controls the main navigation menu, then you would want aria-label to be something like “main menu” or even just “menu”. You don’t need to add information like “Open/close” and “in mobile” to the aria-label. Screen reader users will already know about the open/close functionality of the button because you will have the aria-expanded attribute on it. That’s the purpose of the aria-expanded attribute, to tell screen reader users that the button controls something that can be hidden or expanded. So the aria-expanded attribute is doing this work for you (that’s why it is required to be on the button). And the “in mobile” text at the end is unnecessary because it isn’t important information that screen reader users need to know, so it just adds extra words they have to listen to.
The placement of the hamburger button should also be fixed. It should be the first element inside of the nav element. The nav element acts as a landmark. Screen reader users can use landmarks to navigate the page. Main page menus are generally placed inside the nav landmark at the top of the page. So if they navigate to the nav landmark then they are going to assume that everything for the menu is inside the nav landmark. And since the hamburger button is part of the menu, it should be inside the nav landmark.
As a side note, you don’t need to add “navigation” to the end of the aria-label for the nav element. Screen reader users will already know that it is for navigation because it is the nav element and it will automatically be treated as the navigation landmark by their screen reader and they will hear that it is for “navigation”.
I know this seems like a lot and I can understand your frustrations with accessibility. I can tell that you were trying your best to be accessible, which I applaud. Please don’t stop trying. I think that perhaps you just got some misleading information up front and it lead you to overcomplicate things a little. Notice that most of the changes I recommended above were about removing unnecessary things you added. I’m not going to lie, some accessibility issues are extremely complicated and take a lot of work and testing to implement correctly. But those are much more uncommon, and you certainly don’t have anything like that on your page.
Keep up the good work!
Thanks. It cleared up a lot of confusion for me . You spend alot of time typing this all out and looking at my code, I really appreciate it!
From now on I will first look at how to solve for accessibility and make sure it’s correct before I continue. It will be a lot less stressful that way .
Any advice how to go about focusing on accessbility and not to overcomplicate things ?
Thanks