How can one determine whether a particular element registers a click? It's considered non-clickable when the node is, e.g., disabled, has pointer-events: none, etc.
Basically, the question is how to mimic isClickable of WebdriverIO.
Related
Google's Material Design 3 uses a so-called state layer for interaction states like hovering, focusing or pressing an element. These states are represented by adding a layer with a fixed opacity onto the element to change its colour.
I am currently creating a web application with Vue.js and using tailwindcss as my CSS framework, and was wondering if there is a simple way of creating these state layers. As far as I am aware, there are two possibilities.
I can either use a semi-transparent HTML element that has the same size, shape and position as the original element and set its colour and opacity to the required values. However, doing this for every element that can be interacted with would be a lot of work, greatly increase the size of my HTML code, and I do not think it is an elegant solution.
The second way I can think of is calculating the resulting color of adding the layer to the element, and setting this value when the user interacts with it. Calculating these values manually and stating them explicitly would also be a lot of work, and it would mean that whenever I change one of the content colours, I would have to recalculate all colours for interaction. Another possibility would be to calculate the values at runtime, which has the added benefit of making them dependant on the content colours, but that would mean that I have to access the tailwind variables inside my JavaScript code, and then set the corresponding classes by concatenating the tailwind class name with the calculated value.
While all of these solutions would be possible, I feel like they are neither simple nor elegant. Is there another way that I did not think of, or is the concept of state layers just not meant for these frameworks?
WCAG 2.1 introduced success criterium 1.4.11 Non-text Contrast for UI components like checkboxes, sliders etc.
Would it be safe to ignore 1.4.11 for the background-colour within a button, as long as the text inside has sufficient contrast as well to the button as required by 1.4.3 Contrast, as to the surrounding background colour?
Somebody who couldn’t perceive the button shape due to the low contrast, they would at least perceive the text within – just as with a text-only button.
And text-only buttons exist in several widely used design systems. As the text is the only thing left visible, and text needs a higher contrast than UI components, it automatically suffices for 1.4.11 as well.
Now, I’m not only wondering for the practical implications, but also for an audit. Do you know sites that passed audits with such buttons, or with text-only buttons?
Short answer, most likely you're ok.
Your interpretation is how I conduct my audits. If the button's background color does not have sufficient contrast compared to the page background color (or whatever color happens to be "adjacent" to the button background color) (1.4.11), then if the text within the button has sufficient contrast with the button background (1.4.3), then the user still has enough contrast to know where to "click". It's nice to know where the edge of the UI component is but it's not always necessary to know where it is in order to interact with the element.
The key is:
(1.4.11) Visual information required to identify user interface components
So if I can't tell where the edge of the button is, can I still "identify" where the button is? If there's sufficient text-to-background contrast (1.4.3), then "yes", so 1.4.11 doesn't fail.
Now, a lot of WCAG can be subjective and you might find an auditor that fails the button with 1.4.11 but just because one person says it fails (or another says it doesn't fail), doesn't mean that that person's interpretation matches with yours.
You might disagree with the auditor and that's ok, as long as you can back up your interpretation.
Do you know sites that passed audits with such buttons, or with text-only buttons?
Yes, I pass sites all the time based on my interpretation of this success criterion but I often give a "best practice" that the button edge should be distinguishable but note that it doesn't technically fail.
Is there a way to prevent an 'aria-live' element from being focused by a screen reader?
I'm developing a calendar and would like to notify user whenever the currently selected month is changed.
As others have said, keyboard focus does not have to move to the aria-live region. Any changes made to a live region will just be announced. The focus will not move.
However, if you are asking whether you can prevent the user from moving their screen reader focus to the element, no, you can't prevent that. As long as the element is part of the accessibility tree (a subset of the DOM), the user can navigate to that element and hear its contents.
The rules on whether a DOM element is part of the accessibility tree are spelled out pretty well in "5.1 General rules for exposing WAI-ARIA semantics". Specifically, in the "5.1.2 Including..." section, it says elements that have text will be included. I'm presuming your aria-live element has text because it's being announced as you change it. If you jump back up to the "5.1.1 Excluding..." section, you can prevent the element from being on the accessibility tree if you use aria-hidden="true", but if you do that, then the live changes won't be read.
If implemented correctly, aria-live region will never receive visual focus.
Make sure that the live region is present on the page initially, only then dynamically added/changed content will be announced. Live region of the page that gets announced whenever content changes but the focus doesn't shift to the live region.
I am experiencing slowness with an animation in my website.
After some investigation I found out (via the DevTools timeline tab) that the problem is that the entire page is being re-painted instead of just the animated div.
I checked the "Show composited layer borders" option, and found out that sometimes the animated div is in another render layer.
But I can't find a consistent behavior:
When the div is not in another layer - the animation is slow.
When the div is in another layer, sometimes the animation is fast and sometimes it is slow, depending on the presence of other elements in the page (a div with position:fixed, a marquee, etc). These other elements appear to be totally unrelated to the animated div in the DOM tree but obviously have an effect on the rendering of the page during the animation.
I found a few articles (1, 2, 3, 4, 5) that suggest possible ways to "force" Chrome to render an element in another render layer but most of them are old (things might have changed).
Also, they generally don't address how elements can affect each other with regard to the render layers.
How does Chrome decide which element to put in which layer?
How can I find out what was decided in my case? (i.e. debug the render layers)
How can different elements affect each other with regard to the render layer?
How can an animation of an element that is in another layer, cause a re-paint of the whole page? (at some cases this happens)
How can I ensure a fast render of my animation? i.e - force the element into another layer and make sure the animation doesn't cause a re-paint of the entire page.
And lastly - how can I stay on top of changes to the browser's rendering algorithm so that these problems don't return in the future?
OK so I finally found a solution to my problem.
This SO answer explains how to enable the "Layers panel" in chrome DevTools. That panel allows you to see in real time (even during animations) which elements are in which layers on the page.
Also, each layer has properties that tell you why chrome decided to make a layer out of it.
Using this tool I was able to determine that one of my elements which is an overlay of the whole page (to mask the page when there's a modal div) sometimes gets its own layer and sometimes not.
The reason it got a layer only when some other elements like marquee were present on the page was that chrome detected that "the element may overlap other composited elements".
When these "other composited elements" are not there, this overlay element does not get it's own layer. And when I open the modal there's also an animation on the opacity of the overlay div. And since it was not in a separate layer - it caused the entire page to re-paint itself in each frame (this is sometimes referred to as a "paint storm").
I solved the problem by making sure the overlay div will always get its own layer, by adding -webkit-backface-visibility: hidden to the style of this div.
I was just inspecting the page with debugging feature, and found these hidden elements. Does anybody know, why these elements are there with display attribute none. First one from left is iframe, rest are text areas
sometimes, some backend logic and data Management needs some input operations for controlling operations and data. This not belongs to the frontend and presentational layer, so it stay hidden. In conclusion, backgrounds works.