Select Page

Category: Accessibility

Too Much Accessibility

I like to blog little veins of thought as I see them. We recently linked to an article by Facundo Corradini calling out a tweet of ours where we used an where we probably should have used an . Bruce Lawson checks if screen readers are the victims of these semantic mistakes… Whenever I read “some browsers” or “some screenreaders”, I always ask “but which ones?”, as did Ilya Streltsyn, who asked me “what is the current state of the text-level semantics in HTML reality?” Léonie Watson to the rescue! Over Twitter, Watters wrote Most are capable of reporting these things on demand, but do not as standard. So you don’t hear the text/font characteristics being announced as you read, but you can query a character/word etc. to discover its characteristics. This is based on the visual presentation of the text though, rather than through any recognition of the elements themselves Which I suppose is to say that if you’re really fretting about screen readers misinterpreting the nuanced usage of your semantic emphasis… you can relax on that one. Bruce’s article led me toward Steve Faulkner’s article “Screen Readers lack emphasis” from 2008. Using the semantic elements strong and em does not convey any useful information to users of JAWS or Window Eyes under typical browsing conditions. While it is good to know this, it is not a reason...

Read More

Keyboard-Only Focus Styles

Like Eric Bailey says, if it’s interactive, it needs a focus style. Perhaps your best bet? Don’t remove the dang outlines that focusable elements have by default. If you’re going to rock a button { outline: 0; }, for example, then you’d better do a button:focus { /* something else very obvious visually */ }. I handled a ticket just today where a missing focus style was harming a user who relies on visual focus styles to navigate the web. But those focus styles are most useful when tabbing or otherwise navigating with a keyboard, and less so when they are triggered by a mouse click. Now we’ve got :focus-visible! Nelo writes: TLDR; :focus-visible is the keyboard-only version of :focus. Also, the W3C proposal mentions that :focus-visible should be preferred over :focus except on elements that expect a keyboard input (e.g. text field, contenteditable). (Also see his article for a good demo on why mouse clicking and focus styles can be at odds, beyond a general dislike of fuzzy blue outlines.) Browser support for :focus-visible is pretty rough: This browser support data is from Caniuse, which has more detail. A number indicates that browser supports the feature at that version and up. Desktop Chrome Opera Firefox IE Edge Safari No No 4* No No No Mobile / Tablet iOS Safari Opera Mobile Opera Mini Android Android Chrome Android Firefox...

Read More

Unbuttoning Buttons

We dug into overriding default buttons styles not long ago here on CSS-Tricks. With garden-variety fully cross-browser-supported styles, you’re looking at 6-10 CSS rules to tear down anything you need to off a button and then put in place your own styles. Hardly a big deal if you ask me, especially since it’s extremely likely you’ll be styling buttons anyway. Scott O’Hara has taken a look as well. I think the solution offered to use a is a little bizarre since you need bring your own keyboard handling with is non-trivial and requires JavaScript. But there are a couple of interesting other CSS explorations, neither of which stacked up for different reasons: display: contents; – some semantics-based accessibility problems. all: unset; – doesn’t reset display value, not good enough browser support. Direct Link to Article — Permalink The post Unbuttoning Buttons appeared first on CSS-Tricks....

Read More

Nested Links

The other day I posted an image, quite literally as a thought exercise, about how you might accomplish “nested” links. That is, a big container that is linked to one URL that contains a smaller container or text link inside of it that goes to another URL. That’s harder than it might seem at first glance. The main reason being that… Outside Inside Eric Meyer once called for more flexible linking, but even that doesn’t quite handle a situation where one link is nested inside another. Here’s what happens with that HTML, by the way: The nested link gets...

Read More

Small Tweaks That Can Make a Huge Impact on Your Website’s Accessibility

For a beginner, accessibility can be daunting. With all of the best intentions in the world, the learning curve to developing compliant, fully accessible websites and apps is huge. It’s also hard to find the right advice, because it’s an ever-changing and increasingly crowded landscape. I’ve written this post to give you some tips on small things that can make a big difference, while hopefully not affecting your development process too much. Let’s dive in! Document Structure and Semantics It probably doesn’t come as much of a surprise that structuring your HTML in an organized, semantic way will make a big difference. Screen readers rely on a well-structured document in order to follow a coherent narrative, so make sure that you’re using the elements that the HTML5 spec provides responsively and effectively. If you’re unsure about how to markup your work correctly, check out resources such as HTML5 Doctor, Code Academy and of course, CSS-Tricks. You can also check out articles like “Writing HTML with accessibility in mind” and “Semantic Structure” to get you going in the right direction. Let’s look at three specific things that can help ensure a well-structured and semantic document. Use a Single Element A good example of building a responsible, semantic document structure is only using one element. This should serve as a signpost for the most important content of the page for your...

Read More
  • 1
  • 2
www.000webhost.com