How about some accessibility quick hits!
It’s a bit hard to keep track of when using certain CSS value types is bad. For a while, using pixel (px) values in media queries was considered a bad practice as the breakpoints didn’t trigger as expected when a user zoomed in. But then that changed, and media queries do now, and using pixels for media queries isn’t really a bad practice any more.
But is using px still a bad practice in other cases? Yes, says Josh Collingsworth.
… when or if the user changes their preferred font size, if you’re using
emandrem, all the text on your website will change accordingly, like it should.2remis still double that font size;0.5remis still half of it.By contrast,
pxvalues are static.20pxis just20px, regardless of the container’s, browser’s, or user’s font size. No matter how large or small the user’s font preference may be, when you set a value in static pixels, it clobbers that choice and overrides it with the exact value you specified.Critically, that means if your stylesheet uses
pxto setfont-sizeanywhere in it, any and all text based on that value will be impossible for the user to change.
Did you know that it was, up until fairly recently, specced that heading elements (e.g. <h1>, <h2>, etc) would “reset” inside of a new <section> (and similar) elements? I admit I thought that was kind of a neat idea. For example, if you’re building a site with HTML partials, and one of those as a little <aside> that I plunked into a sidebar or something, that I could have an isolated set of headings that would be valid and squoosh into the proper hierarchy going on on the rest of the page, without knowing or caring about headers scattered around the rest of the page.
Well, despite being specced, and despite general liking of that idea, no browser ever implemented it, and it was removed from the spec. Pour one out for the Document Outline Algorithm.
Doesn’t make me want to hold my breath for browsers implementing a tab order fixer-upper that follows the visual order of grid or flex items, like has been tossed around a bit.
Léonie Watson:
… you may be surprised to learn that there is no way for authors to design the aural presentation of web content, in the way they can design the visual presentation.
Why we need CSS Speech
All the major browsers now have “listening” features built right into them, and still no way to control that experience.
The good news is that there is a spec for CSS speech. Léonie thinks it’s too old and too big, so offered to take it on and trim it down (hopefully into something browsers will take on). Looks like that’s starting to happen based on the names on the spec.
This is a wild story: Safari’s date-picker is the cause of 1/3 of our customer support issues.
Shortly after I read it, I had to use this exact date picker a number of times while filling out online forms on an iPad at a doctor office and I friggin get it. Using that date picker for birthdays is horrible. Even knowing exactly how to do it, I tripped up several times in a row.
The danger of all this is companies, sometimes rightfully, going “screw it we’ll just build our own”, and having that home-grown picker perhaps solve this one UX issue, but cause accessibility issues that harm another group of people.
A smidge of good news. We can Use the dialog element (reasonably) says Scott O’Hara. There have been some recent updates that solve some the focus handling issues that apparently gave it a red flag before. I’m glad about this, as I think it suffers from exactly what I described above: people build dialogs in-house instead and get some (if not most) of the accessibility requirements wrong. Focus-trapping alone is brutally difficult to get right, and it’s just a freebie with <dialog>.
The post Chris’ Corner: Font Size, Document Hierarchy, and Dialog appeared first on CodePen Blog.