E-mail List Archives
Thread: Improving the Accessibility of My Projects
Number of posts in this thread: 4 (In chronological order)
From: Bryan Hadaway
Date: Wed, Jan 08 2020 9:35AM
Subject: Improving the Accessibility of My Projects
No previous message | Next message →
Hi Everyone,
I'm new to accessibility, at least in terms of the really important stuff,
not just the trendy stuff from a decade ago, when everyone was adding
language switchers and font-size changers to their sites.
Here's the project I'm primarily focused on making accessibility-ready at
the moment:
https://wp-themes.com/generic/
Everything I learn from this will then cascade down into all my other
projects.
If anyone would be gracious enough to help me by testing it out and giving
me some pointers on things that I should improve, especially from those who
browse the web from a keyboard 24/7, I would be very grateful.
I'm open to any/all suggestions, but one particular dilemma I'm currently
faced with is the tabbing/focusing order of the menu and search form.
Aesthetically, both on desktop and mobile, it's the way I want it. I want
the search form on the right on desktop, and I want the search form above
the menu on mobile.
Functionally, I want people to be able to tab to search *before* the menu,
and herein lies the problem.
Everything looks and functions the way I want it to, but from a keyboard
perspective, one would expect tabbing to follow the normal visual order of
elements on the page, otherwise it might be a little jarring/confusing.
However, web design is about compromise because there are many, many, MANY
variables that have to be taken into account and it's impossible to make it
perfect for every scenario.
My assumption would be that keyboard users would rather reach the search
form before the menu, even if done in a different way, as opposed to having
to tab through the entire menu (of which some people add dozens of links)
before getting to search.
So, of the following scenarios, what do you think is the most pleasing and
easy for actual keyboard users:
A. Exactly the way I have it now.
B. I should just change the tabbing order to menu first, then search.
C. I should just change the tabbing order to menu first, then search, but
also add a "Skip to search" link before the menu.
D. Some other creative solution?
Thank you!
From: Carly Gerard
Date: Wed, Jan 08 2020 10:39AM
Subject: Re: Improving the Accessibility of My Projects
← Previous message | Next message →
Hi Bryan,
I think this tab order could be further improved. I feel like I'm doing a huge visual leap from the homepage link across the entire screen to the search, and then the same amount of leap back to the menu on the left. It's a lot of visual work to keep track of where I am, especially with the current focus indicators being minimal and not catching my eye.
What might also be tripping me up is that I'm used to seeing search regions closer to the top of the page, rather than lower in the header. I don't think a search in the header is invalid (WebAIM did their nav/banner pretty well, I think: https://webaim.org), but most sites seem to put their searches closer to the top right of the screen on desktop:
* Gatsby: https://www.gatsbyjs.org/
* Apple: https://www.apple.com/
* University of Washington (UW): http://www.washington.edu/
* Western Washington University (WWU): https://www.wwu.edu/
At WWU, we put our search region before the main nav semantically as well. We also made sure to put the search above the navigation on desktop, so the tab order made it clear you would reach the search before the main navigation. On mobile, our search comes after the menu, but the entire menu is opened by a single button there, so one tab stop compared to desktop's 5-7.
In your example, if I had to guess focus order just by looking at it, I would guess that I would first focus on the main nav and then the search--they are on the same line visually and the main nav is first in that line. Whatever you decide semantically should be fine, as long as the design reflects that semantic order as close as possible.
I'm sure others will have different takes, which I'd be interested in hearing.
Carly
[Western logo]
Carly Gerard, CPACC<https://www.accessibilityassociation.org/cpacccertification> | She/Her/Hers
Web Accessibility Engineer | Web Communication Technologies
Western Washington University
516 High Street, Bellingham WA 98225
= EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > | = EMAIL ADDRESS REMOVED = <mailto: = EMAIL ADDRESS REMOVED = > | (360) 650-3944<tel:(360)%20650-3944>
From: WebAIM-Forum < = EMAIL ADDRESS REMOVED = > on behalf of Bryan Hadaway < = EMAIL ADDRESS REMOVED = >
Sent: Wednesday, January 8, 2020 8:35 AM
To: = EMAIL ADDRESS REMOVED = < = EMAIL ADDRESS REMOVED = >
Subject: [WebAIM] Improving the Accessibility of My Projects
Hi Everyone,
I'm new to accessibility, at least in terms of the really important stuff,
not just the trendy stuff from a decade ago, when everyone was adding
language switchers and font-size changers to their sites.
Here's the project I'm primarily focused on making accessibility-ready at
the moment:
https://nam03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fwp-themes.com%2Fgeneric%2F&data=02%7C01%7Cgerardc%40wwu.edu%7Cfa2c11cc1e7c463a43c308d79458bb97%7Cdc46140ce26f43efb0ae00f257f478ff%7C0%7C1%7C637140981132619401&sdata=gtnyfW4XchQdMm32s85YlXttPI599davSBd64lOBtlU%3D&reserved=0
Everything I learn from this will then cascade down into all my other
projects.
If anyone would be gracious enough to help me by testing it out and giving
me some pointers on things that I should improve, especially from those who
browse the web from a keyboard 24/7, I would be very grateful.
I'm open to any/all suggestions, but one particular dilemma I'm currently
faced with is the tabbing/focusing order of the menu and search form.
Aesthetically, both on desktop and mobile, it's the way I want it. I want
the search form on the right on desktop, and I want the search form above
the menu on mobile.
Functionally, I want people to be able to tab to search *before* the menu,
and herein lies the problem.
Everything looks and functions the way I want it to, but from a keyboard
perspective, one would expect tabbing to follow the normal visual order of
elements on the page, otherwise it might be a little jarring/confusing.
However, web design is about compromise because there are many, many, MANY
variables that have to be taken into account and it's impossible to make it
perfect for every scenario.
My assumption would be that keyboard users would rather reach the search
form before the menu, even if done in a different way, as opposed to having
to tab through the entire menu (of which some people add dozens of links)
before getting to search.
So, of the following scenarios, what do you think is the most pleasing and
easy for actual keyboard users:
A. Exactly the way I have it now.
B. I should just change the tabbing order to menu first, then search.
C. I should just change the tabbing order to menu first, then search, but
also add a "Skip to search" link before the menu.
D. Some other creative solution?
Thank you!
From: glen walker
Date: Wed, Jan 08 2020 5:17PM
Subject: Re: Improving the Accessibility of My Projects
← Previous message | Next message →
As a keyboard user, I prefer my top-level menus to *not* automatically open
just because I tabbed to them. Your "Parent Page" menu opens and shows
"sub-page" just by receiving focus. It's not a WCAG violation. It's more
of a personal preference to me as a keyboard user. It lets me tab across
the main menu and get to the search field fairly quickly. If the top level
menu will have a lot of items in it (although hopefully that number is kept
somewhat small), then as Carly said, you could have a "skip to search"
after "skip to main".
In general, I prefer the DOM tabbing order. It's predictable and easy to
implement - you don't have to do anything :-)
If you want to force a certain tab order, it can get complicated and messy
very fast. I would not use tabindex. You can still use the DOM order but
use CSS to move elements around, but be careful with this too. So your
search form could be first in the DOM but you position on the right and
down a bit from the top (so it's "under" your menu), then have the menu
next in the DOM. That gives you the tab order you want and the visual
order you want. There is a bit of a disconnect from the tabbing order that
most people will expect from seeing the layout, but it's not a WCAG
violation.
I don't see any problem with how it works now. Menu first then search
field.
From: Bryan Hadaway
Date: Wed, Jan 08 2020 5:48PM
Subject: Re: Improving the Accessibility of My Projects
← Previous message | No next message
Updated: https://wp-themes.com/generic/
(depending on when you read this, you might not see the updated version yet
because of the wordpress.org cache)
*@Carly* â Thank you. I think I've been able to greatly improve both the
visual and functional presentation now. Considering the project, titled
Generic, is supposed to, well, be generic, as a tool for other web
designers and programmers, I try not to get too fancy or opinionated with
it.
*@Glen* â Thank you. I agree. Initially, I did have it so that the parent
menu wouldn't open the sub-menu automatically upon focus, and had it so
that it would only open on enter or the down arrow, but it threw some bugs
into the mix and was starting to bloat the code a bit (I try to avoid JS as
much as possible). I ultimately decided to go with the most lightweight
solution, which is the CSS-only way that it's using now.
I'm tempted to use <details> to solve both the lightweight and
functionality problem, but I'm guessing that's a pretty big semantic no-no,
which would be even worse, because I want to use best practices and
standards as much as possible.