In this week’s roundup, the string length of two emojis is not always equal, something to consider before making that rounded button, and we may have a new way to share web apps between devices, even when they are offline.
7 if it contains additional Unicode scalar values that represent a skin tone modifier, gender specification, and multicolor rendering.
(via Henri Sivonen)
An accessibility issue with rounded buttons
Be aware that applying CSS
border-radius to a
You can avoid this accessibility issue in CSS, e.g., by emulating rounded corners via
border-image instead, or by overlaying the button with an absolutely positioned, transparent
(via Tyler Sticka)
Sharing web pages while offline with Bundled Exchanges
Chrome plans to add support for navigation to Bundled Exchanges (part of Web Packaging). A bundled exchangeis a collection of HTTP request/response pairs, and it can be used to bundle a web page and all of its resources.
The browser should be able to parse and verify the bundle’s signature and then navigate to the website represented by the bundle without actually connecting to the site as all the necessary subresources could be served by the bundle.
Kinuko Yasuda from Google has posted a video that demonstrates how Bundled Exchanges enable sharing web pages (e.g., a web game) with other devices while offline.
(via Kinuko Yasuda)
Read even more news in my weekly Sunday issue, which can be delivered to you via email every Monday morning. Visit webplatform.news for more information.
Are rounded buttons actually an accessibility issue?
I get that you’re losing some clickable pixels, but we’re not talking about a whole lot of area in the examples. I can’t imagine anyone is using touch with a fine enough touch that it matters here.
If the button is a square (e.g., an icon button), then over 20% of its interactive area is lost by turning it into a circle via
border-radius. That’s not negligible. If the user has hand tremors, low vision, or just large fingers, they may hit those edges that are not interactive.
There’s also the guideline that touch targets should be at least 44 by 44 pixels. A button that satisfies this rule may no longer do so once its corners are rounded. Take Twitter’s floating action button as an example. It’s 55 by 55 pixels on mobile, but because it’s a circle, the 44 by 44 square sticks out. Luckily, Twitter made sure that the entire square is interactive, not just the visible button, and that’s my advice as well.
I agree, I don’t think rounded corners are an accessibility issue. So long as the element width and height are large enough (WCAG 2.1 settled on 44×44 CSS pixels for target size), the corners don’t matter.
I think creating an invisible clickable area is a problem in itself; if I click outside the visible button area, I expect nothing to happen. I don’t think it’s an issue with keyboard or touch interaction but can be with a cursor. Using hover to show the “true” button area could address it.
Think of it this way: If on a touchscreen device, someone taps on the area in the corner of a button that is cut out by the rounded border, did they mean to tap the button? I think yes. Did they by any chance mean to tap some other interactive element? I think that’s unlikely. It’s just too close to the button.
So by making the interactive area of a rounded button a proper rectangle, all we’re doing is making sure that it never happens that the button is not activated just because the person tapped too close to its corner.
I always hated when you could interact with a button when you’re not actually in the area of the button. I don’t think it’s a good idea to bring this archaic style of buttons back. When I wanna tap the button, I will just tap the button, not something else. If there’s a concern for accessibility, just make the button larger – easy :)
This has nothing to do with the weekly roundup, but just wanted to wow this site has the nicest blog design of any blog I’ve seen. So unique and clean even with the dark background. If it were a paid theme, I’d buy it in a heartbeat! (fingers crossed)
Take a button that’s 44px square but has border-radius: 50% so it becomes a 44px diameter circle. The corners of the square would be 31px from the center and the edge of the circle 22px from the center, a 9px difference. A finger tip is 8-10mm wide and using many Apple mobile displays (2x Retina) as representative, there are 6.4 CSS px/mm so from the center to the edge of a finger tip is 25.6-32px. If a corner of the button’s square was below the center of the finger tip, the tip would still easily touch the circle and activate the button. If the corner was halfway between the center and the edge of the finger tip, it would still touch the circle. The circular button would have to be ~130px across for a finger tip centered on the corner to not activate it; that’s a big target to miss.
You suggest if someone clicks in the invisible target corner it’s because they meant to activate the visual element it belongs to. But that may not be so, particularly if the button is on top of something interactive. Imagine this: They’re shopping for pants, there’s an picture of the pants with four round color swatch buttons (black, navy, brown, khaki) on top of the image; they tap a swatch to change the color then think they tapped on the image to enlarge it but because they didn’t move their finger much, the edge of the tip clicks the invisble corner and activates a color change.
In general, the interactive target shape should be the same as its visual shape. I’ve experienced a problem when they did not match: There was chevron breadcrumb navigation and I clicked on what was visually the right link but because the cursor was below the tip of the point for the left link, the left link was activated.
I tested it in Safari on iPhone. If the button is a
44pxsquare, it is still possible to hit the corner of the square outside of the circle. Try it in my demo on your mobile device. You can tap the black cutouts (it will say “square” below).
This is the problem. Someone misses the rounded button and hits the cutout instead. As I already said, I think it is safe to assume that if the user taps the cutout, they wanted to tap the rounded button.
Re your scenario where the button is on top of a different interactive element, I think that’s another (even bigger) accessibility issue. It’s probably a good idea to leave enough space between interactive elements and not stack them on top of each other.
Related: Hand tremors and the giant-button-problem