In brief, I'd like to know what the right way design a mobile navigation toggle that when clicked shows the menu but simultaneously hides the content.
I know normally you would have something like this:
<body>
<button type="button" aria-expanded="false" aria-controls="main-nav">I'm collapsed</button>
<nav id="main-nav">...</nav>
</button>
<body class="mobile-nav-open">
<button type="button" aria-expanded="true" aria-controls="main-nav">I'm expanded</button>
<nav id="main-nav">...</nav>
</button>
#main-nav { display: none; }
.mobile-nav-open #main-nav { display: block }
However, some of peculiarities of this design I've been given require that when mobile nav is open, the rest of the content is hidden. (ie: display: none)
Let me illustrate what I'm talking about:
This is the desktop layout of my site.
Desktop Layout (sorry can't show inline images because I'm a new user)
Now here's mobile's "nav collapsed" and "nav expanded" states, respectively.
Mobile Collapsed (sorry can't show inline images because I'm a new user)
Mobile Expanded (sorry can't show inline images because I'm a new user)
now I could do some css like this,
.main-nav,
.sidebar-nav,
.footer-nav {
display: none;
}
.mobile-nav-open .content,
.mobile-nav-open .footer {
display: none;
}
.mobile-nav-open .main-nav,
.mobile-nav-open .sidebar-nav,
.mobile-nav-open .footer-nav {
display: block;
}
And pass additional ids to aria-controls
<button type="button" aria-expanded="true" aria-controls="main-nav sidebar-nav footer-nav">I'm expanded</button>
Now that's fine but it doesn't account for the "collapsed"/hidden state of Content and Footer. Adding them to aria-controls would be incorrect because their "collapsed" state is the inverse of the navigation's "collapsed" state. In some ways this seems kind of like tabbed content where what you display is mutually exclusive, yet that doesn't feel right. It's a single button doing the toggline, not an item for each "tab" and the content being displayed are not related/grouped in the way you usually see in a tab view.
I've searched MDN looking at tablist, listbox, etc but didn't find anything that really fit.
I'd appreciate any insight as to the proper WCAG way to achieve this would be. I suspect because there's not a clear way to describe this in terms of aria attrs that this is a accessibility anti-pattern.. but it's the design I was given :shurg:
If you keep it as you say, it indeed looks a little like an accessibility anti-pattern. At least, as you have observed, nothing especially fits your case.
Maybe the best if you have no other solution is to not specifiy anything, so that you are sure that users won't be surprised and won't think that your app is buggy.
No worry, they will end up figure it out. To compensate for that lack of ARIA indication that can only confuse users, you have to make it exceptionally clear, by saying something like "Show X and hide Y", or maybe better, "Switch between X and Y" or more simply alternatively "Switch to X" and "Switch to Y". Don't forget to update the label of the button as needed.
However, I have another suggestion. I can't see your screenshots because I'm blind myself, so I can't tell if it is well suitable in your case, but maybe you can view it in another way. What about considering one of the two contents as a popup or navigation menu ?
When a popup is open, it's the normal fonctionning that you can't reach what's not inside it. When a navigation menu is open, it isn't unconventional either that the rest is hidden, especially in mobile apps where space is limited and where you must stay as simple and concise as possible.
Still, note that if you view one of the two content as a menu or a popup, you must provide a close button. There you can maybe "cheat" by reusing the same button which opened the menu/popup at the first place. You just have to change its label.
As a wrap up, of course it would be better if you could follow one of the standard UI patterns such as toggle button or tablist. But, when everything doesn't fits very well, keep in mind that, very often, less ARIA is better than too much.