Putting My Patterns through Their Paces
7 Comments
Comments are ordered by helpfulness, as indicated by you. Help us pick out the gems and discourage asshattery by voting on notable comments.
Got something to add? You can leave a comment below.
Geert Melotte
Ethan
Geert, that’s a great point! Breaking from tab order is definitely a trade-off, and one I try to be mindful of. That’s part of why I’ve started shying away from patterns that require drastic structural changes—like, say, putting the navigation at the bottom of the document’s source, and then pulling it visually to the top of the page.
Some colleagues have suggested it’d be ideal if tab order followed the visual presentation. But that aside, it’s worth noting that all the questions I ask myself are, well, assumptions, often informed by my own biases and expectations—which means those assumptions need to be vetted by real users, as early as possible in the design process.
Adrian Roselli
To respond to Geert Melotte, CSS Flexbox can certainly mess with expectations about source order versus read/tab order. But so can CSS Grid, floats, and absolute positioning.
I follow two rules (for now) when it comes to using flex: 1. I do not use the order property, as that can be a can of worms; and 2. I still tab through the page to see if it makes sense contextually.
I tracked some different browser behaviors in a post with a bunch of code samples: http://adrianroselli.com/2015/10/html-source-order-vs-css-display-order.html
Kevin Oleary
Couldn’t you have avoided all the flex box gymnastics by just swapping around the order for screen readers with Aria: tab index?
Graham
Hi Gert and Ethan. I agree, great point!
In my experience the tab order reflects an element’s hierarchy, and would follow the same rules that Ethan outlined in the article. When I designed games which adhered to accessibility guidelines from the BBC, the tab order was defined by the order of importance of the buttons on the screen rather than the visual order in which they appeared. For example, on the start screen the most important button was play (large, central on screen), so it came first in the tab order, before mute, options etc (in the top-left-hand corner). This may not apply directly to the web, but I would have thought the same principles would apply here.
Andrew
So relevant to me right now.
What I’m doing is decoupling components from HTML. I never thought so many could be candidates for this. My god it is so much work!
Flexbox is a gift from the heavens. The things it is enabling.
I feel like The Ugly One in episode 3 of Teen Girl Squad… “I’m going for a whole new style!”
Gunnar Bittersmann
Thanks Ethan,
You demonstrate a great way “to move past the visual presentation in front of me, and focus on the underlying content.”
You might go this way even further using the new HTML elements. The teaser might well be an <article>
element (or an <aside>
element, depending on the context in the page); inside which the <div class=“teaser-hed”>
would be a <header>
. A screenreader should be aware of the difference between <article>
/<header>
and <div>
/<div>
and convey it to the user, shouldn’t it?
“By [Author Name]” doesn’t look like a heading to me; I would use <p>
instead of <h2>
. And alas, <i>
does not mean ‘icon’. ;-) Sometimes a <span>
is just a <span>
, as for “comments”.
Have you prevented the comment counter from overlapping the byline? You never know how long [Author Name] is… Making the whole @.teaser@ the flexbox and reordering the flex items using the @order@ property might take away the need for ‘@position: absolute@’. (For that, the parts need to be siblings, i.e. no <header>
element in this case.)
Moving beyond,
Gunnar
Great article, love the progressive ehancement thinking. I was wondering what impact the layout reordening has on accesibility? Because if there are links in the flex items, the logical tab order won’t be followed. Does this impose accesibility issues?