CLS issue only as a part of field data - how to diagnose it? - pagespeed

The website of PageSpeed Insight is the only place, where i get CLS issue in both of field and lab data.
Any other Lighthouse instance (by WPT, as API or by DevTools) displays CLS issue only in field data, not in the lab.
How can i diagnose correctly, which elements are causing CLS? Example.
PS: My question has the following cause: analyzing other websites i usually have under devtools → performance red diamonds layout shift, which, if clicked, display in tab Summary some data about this layout shift. Like on the screenshot:
But on the example site i get CLS diagnosted, but not displayed.

The synthetic (lab) tests only load the page (they do not interact with it), whereas field data is until page unload.
Immediately I can see one Layout shift is when you open either of the drop down menus, your scroll bars disappear (due to adding the class .overlayed) and the whole page shifts around. Synthetic tests do not open the menu so will never capture it, however this shouldn't actually contribute to CLS as it requires interaction to open (just something to fix).
The other thing I noticed is the bottom right corner icons cause a layout shift when you scroll and they collapse / open (the floating icons). This is likely to be the cause of CLS as it isn't via direct interaction. Scrolling does not count as user interaction when it comes to CLS.
My guess is that this is the one that gets found by synthetic tests sometimes and not others.
Finding Layout Shifts
In order to find layout shifts you can open developer tools, go to rendering panel (you may need to open it with "more tools") and click "Layout Shift Regions" so it is selected.
Now use the site and you will get a blue box around anything that shifts.
Or you could use performance traces
The other way is to run a performance trace in the performance tab and then just use the site. Once you are done complete the trace and it will tell you if a layout shift occurred and what item caused it.
Tracking them in the field
In order to capture layout shifts in the field yourself you should use something like Google Web Vitals library along with click / mouse position tracking etc and pipe it to your own backend or Google Analytics for analysis.
This lets you find issues with the page a lot more quickly and easily using Real User Metrics (RUM) data in real-time.

Related

Do accessibility settings like 'aria-hidden' prevent Power Automate from clicking or pressing content on a web page?

I am trying to select a dynamic calendar on a website. My goal is to open the calendar and input dates as I need to. I am not able to open the calendar by "Press button on web page" or "Click link on web page" with my selected UI Element. There are no ID's available to select. I have tried using the div class names with no luck. I have tried altering the selector to make a custom selector that looks for div names containing part of the class name. The 'Name' attribute in Power Automate is unavailable for the UI Element.
After trying all this, I noticed an Icon that is part of a div for the calendar, has
aria-hidden="true"'. When I checked the MDN here it has a warning statement: "Warning: Do not use aria-hidden="true" on focusable elements."
With being unable to select the calendar with standard and custom selectors, am I being blocked by the accessibility setting? Is Power Automate unable to focus on the calendar opener from aria-hidden="true"?
I don't know power automate, but what you observe makes sense. The attribute aria-hidden=true tells assistive tools such as screen readers and voice control software to ignore the element, as if it wasn't present at all.
A focusable element must never be aria-hidden=true. A screen reader won't know what to say when landing on it, and, as observed, it won't be reachable using voice control.
That's simply a pure accessibility fail (I would even call it stupidity, but well).
Technically, the solution is very simple: remove that stupid offending aria-hidden=true. Those who made that calendar probably put it there because:
they thought that screen reader and voice control users will always enter a date by hand and won't ever use the date picker
the date picker hasn't been made accessible, and so it's better to ignore it completely rather to present something only partially accessible
They copy/paste the code from elsewhere and didn't pay attention
They have no excuse for the third one, and for the two first, both reasoning are just wrong. Even if it isn't perfect, it's better to have a little something rather than nothing.
Keyboard-only user or screen reader user don't necessarily mean eased to enter a date manually. ON a mobile, the virtual keyboard is often painful to use, and people with limited movement sometimes use a device with only a few available keys (such as enter, tab, escape, and arrow keys only). Additionally, both might be combined if you think about someone who has a strong dyslexia and an inability to use his hands (the device would be actioned with feet, blinking eyes, etc.).
In theory, you shouldn't ever use custom widgets if you can avoid it. For entering dates, the standard exists: input type=date and friends.
Using standard widgets is the best guaranty to have something accessible at long term. Even if it might not be 100% accessible right now, it's getting better as the time passes.
Sadly, UX designers often don't like standard widgets much because it doesn't look like what they want, and there are still a few older browsers which don't support them all very well.

Web Accessibility (WAG2) MODIFICATIONS

I need to have my prestahop (1.7.8) pass web accessibility check and i went through resolving most errors except of 2 which i consider also stupid ones..
The control arrows of default theme's image slider has no contrast. (The control arrows are white and the wave Accessibility app is comparing them with the blank slider box no matter the image added in the slider)
In the product page the quantity add remove quantity arrows give the following error "A button is empty or has no value text." So far i have only succeeded n removing the quantity arrows completely by removing the code from the theme.js file.
Has anyone any idea how i can properly correct these errors without ruining the theme?
Sounds like you are using a scanner to check the accessibility of your code. In particular, the Wave tool from WebAIM. Note that scanning tools can only catch a small percentage of accessibility issues. The number ranges from 20-30%, leaving 70-80% of accessibility issues untested. You need to perform manual accessibility testing to find the remaining issues.
Also note that scanning tools aren't flawless. They can report false positives. So it's possible that your two remaining errors are not real errors. Applying CSS and background images when testing for color contrast can be quite tricky and some scanning tools will report an error when there isn't one, or might NOT report an error when there IS one.
With those two caveats in mind, we'll need more details about your code before we can give detailed advice.
With your second error, it's sounds like you might have a '+' and '-' button for quantity. If those buttons are images and the image doesn't have an alt attribute, or if they're CSS :before elements that don't have a pronounceable character, then WAVE will tell you the button doesn't have any text.
i still can't figure out how to resolve the quantity arrows (up/down)..
I did edit the theme.js file to remove the arrows but now the language change is not working... so i ended up reuploading the original theme.js which now shows the same initial web accessibility error.
Do you have any suggestion as to what to edit/where?

Accessibility - provide mechanism for easy navigation between interactive sections

We have a web-based app which uses a side-by-side experience for desktop users where the left side of the screen is a file browser and editor and the right side of the screen is an interactive preview. Users of our app will make constant and iterative changes on the left and and then interact with the preview on the right, switching back and forth many times in quick succession.
Is there a "best practice" for allowing quick and easy navigation between these two interactive areas? I know this might fall under the "opinion" category, but I feel that accessibility is such an overlooked topic that it helps to have as many resources as possible.
You have a few tools at your disposal.
Headings
Headings are one of the easiest ways to bake in some super simple section switching. Screen reader users will use the keys 1 through 6 to navigate by heading levels so if both of your panels are <h2>s (for example) they can simply cycle location using headings.
Keyboard shortcut keys
You can set keyboard shortcut keys.
However you should never do this in isolation. By this I mean if you say that switching window is say Alt + 0 you must allow users to be able to change these key bindings to their preferences.
This is so your shortcut keys don't interfere with their screen reader keys (as they may have set custom keyboard shortcuts).
please note: as pointed out in the comments this is not a WCAG requirement for key combinations (which is only for single keys) but is a usability best practice and highly encouraged, especially as some screen reader users use a modifier key rather than a toggle key for screen reader navigation.
Then we get into an interesting area which I like to illustrate by saying "how would a one handed user use your page?".
This example makes you realise that some sort of sticky keys solution may also be considered where key combinations can be done with a sequence of keys, any time apart (as you may have someone with NO HANDS using eye gaze technology or a switch for example so you don't want to impose a time limit.)
Obviously the above are extreme examples but things you may want to consider (and in reality anyone using eye gaze would be able to visually switch panels etc.)
Voice commands
Being able to switch panels via voice (for example Dragon Naturally Speaking) is also essential.
Now you can do key combinations with voice software so that fixes most issues but they can be annoying and fiddly.
One thing that is quick to use on most voice software is clicking any button on a page with a unique name.
As such having a button above each panel that activates it would be beneficial to voice users.
Assuming these buttons have unique names I could simply say "click activate panel 2" (where "activate panel 2" is the button name) and switch immediately.
Do you need to manage focus?
Bear in mind that when you switch panels you will by default start at the top each time.
This may be exactly what you want but more than likely this would be a terrible user experience.
Instead you may want to remember the previous focus location. Then if I use the keyboard shortcut it would jump back to the same location in the panel. If I use the voice / button click to change location same again.
However if someone uses headings to navigate this obviously wouldn't work. You could then give them a button directly after the heading that says "resume from previous location" to fix this and use that to manage focus.
User settings
As you can see there are loads of things that different people with different requirements may or may not need.
As such adding all of the features by default would probably make the application worse to use for majority of users.
Instead have a settings screen that lets a user turn on features that benefit them, set their own shortcut keys, turn on or off sticky keys, decide if they want you to manage focus for them (or not) etc.
This is a difficult problem! I have been giving a similar issue a lot of thought. I have outlined one idea that uses ARIA live regions, and an alternative idea that might work better if quick-jump keyboard support is vital.
Live region announcements as part of a <form>
The <output> tag may be what you're looking for. It is mapped to the ARIA role of status so any changes to its content will be announced without any focus change. That way, the user can continue to navigate and make changes on the left side without always having to flip over to the right side to know what changes were made.
The role status has an implicit aria-live value of "polite", so that the announcement will wait until any other descriptive announcement is finished.
It has an implicit aria-atomic value of "true", which means that any change will trigger the announcement of the entire contents of the element -- which may or may not be appropriate for the content. If not, add aria-atomic="false" to read out only the changed node.
If the content inside the <output> could be anything other than phrasing content (including <div>s or heading tags) then you should use a <div> with the role attribute of "status" instead.
Custom keyboard controls can get tricky with various types of assistive technology (AT) software/hardware. Plus those commands probably can't be made easily discoverable. Some ATs provide a keyboard command to flip between a controlling element and the element assigned via its aria-controls attribute. Unfortunately, this functionality is poorly supported, but it is the current standard, so support may get better over time. Currently only NVDA on Windows supports it, with the keyboard command Insert + Alt + M.
Adding aria-controls to an element controlling an <output>/status is mandatory anyway, so give it a unique id attribute and set that as the value of aria-controls on each form element inside the <form>.
If the <output>/status is wrapped in a <fieldset> and the inputs are all wrapped in a containing <fieldset>, then each <fieldset> acts as a grouping container, so the user can navigate between them quickly. As part of this, ensure the <fieldset> containing the <output> directly follows <fieldset> containing the form elements in the source order. If this isn't possible, add the aria-owns attribute to the containing <form> and reference the id attributes of both <fieldset>s with a space in between.
Always-open non-modal <dialog>
You may instead consider making the right side pane an always-open non-modal <dialog>. A <button> next to each interactive element on the left pane would move focus to the <dialog>, and the Escape key would return focus back to the <button>. Focus isn't trapped within a non-modal <dialog>, so the user can still move between each pane using normal navigation methods. The <dialog> needs to have an open attribute to appear and it also needs to have aria-modal="false".
Each <button> would need an aria-controls value referencing the <dialog>'s id attribute, and an aria-haspopup value of "dialog". The <button>s could be invisible until focused.
There's only a single focused point at any given time. So there isn't any real miracle solution, screen reader and other keyboard-only users will necessarily have to repeatedly go back and forth.
IN fact, the most important isn't to be able to switch quickly between the different parts (you must only somehow give a way to do it only with keyboard), but to not lose cursor position when you switch.
For example if I edit something on the left, go to the right to check the result, and then go back to the left side, I expect to find the insertion point exactly where I left it off.
You really have to make sure that this is always correct, and as closest as possible when changes occurs (especially when it's asynchronous, i.e. a change occurs on the right side when you are on the left side).
The most similar accessibility recipe or component is probably split view.
In windows world, the most used shortcuts for cycling between the different splitte parts is F6, and Shift+F6 to cycle in reverse direction.
Don't hesitate to add other easier or additional shortcuts if the switch has to be really frequent, such as Ctrl+Tab, if such shortcuts aren't already used for something else.
F6 and Shift+F6 aren't the easiest shortcuts to perform, especially on laptops where all F1-12 keys may not be available at all or only by using an additional FN key. I personally always found F6 a questionnable choice, but that's only an opinion; at least we have something and that's of course better than nothing.
However, don't replace an existing shortcut commonly used. (for example Ctrl+Tab = switch between different tabs, don't use it for cycling between views if there are tabs in your application and keep it for the tabs)

Bing Custom Search Instance showing results outside active domains (EDIT: Now giving no results for any queries)

Having a problem with Bing Custom Search.
I list only two entries in the Active tab:
https://www.ladottransit.com
https://store.ladottransit.com
Nothing listed under the "blocked" tab.
Run a search for "reports" and I get results from crimereportsforneighborhoods.brecordsbzc.com, which is clearly outside the parameters.
I also lost the ability to remove or edit active entries in a previous instance (I had to create a new instance to get them back). These icons ("controls") are no longer displayed in that instance.
Thanks for your assistance.
EDIT: Here's screen cap of a search for "candy" (once I removed the errant Actives):
EDIT 2: I removed all pinned entries and the problem seemed to go away, and I launched. But I went to check this afternoon and I'm now I'm getting no results for any queries. The following was a search for Downtown (which should have numerous results).
This is the return I get regardless of the query. Code has not changed since testing and launch. Placed the JS snippet again and getting the same result.
I can't seem to repro the out of domain result issue. Below is the snapshot. For controls, they shifted to right and they are difficult to see as there is a gap in UX between ranking adjustment and controls. You can scroll towards right and they should be visible. If you can't see the scrollbar, pls change the browser and try. I tried in edge and it works.
Can't repro with "candy" query. It's weird that you are seeing and I can't repro. Just make sure that you don't have anything pinned - pinned results are not shown in "active" tab. Else, you need Cognitive Services support team to look into this matter.

Flex - invisible text until mouse pointer moves outside textInput

We have an application running flex sdk 4.5 and have recently encountered an issue with textInput fields which we have not been able to reproduce on our end for the better part of a month now.
Here are the symptoms:
Users opens an input form which contains several input fields (combo boxes, calendars, text inputs, etc)
User clicks inside a text field
Users types (obviously!)
** Nothing appears in the text input - we have validators on some of these fields and they do kick in properly (ie. user sees red box around textInput disappearing)
User moves cursor outside of text input field and text appears
Give or take, this is the test case we've been provided. We have been unable to reproduce this and I'm reaching out to see if anybody has heard of issues like this in the past.
They are running our flex application in the following environment:
Windows XP SP3
IE 7.0.5730.13 (locale = en-gb)
Flash Player 10.3.181.14
Upgrading either of these components is not an option. Installing the flash player debugger is not an option either.
Now we've setup a pc exactly the same way as they have on their end and still haven't reproduced. So we're really stuck at this point :)
Any suggestion is greatly appreciated. I'll provide any additional info needed.
-Marc
Feb. 2nd 2012 - Update
As I noted in my comment reply to shaun, it seems our customer was more or less precise in their description of the issue. We ran a webex session with them this morning and actually saw the issues first hand.
Here's what happens:
- User loads our application via its url
- User is able to input data and pretty much do any function for a 'random' time period
- All of a sudden, the issues start (there are more symptoms than just the one I originally mentioned):
1. Users type in text input fields and they won't see the text appear until they move the cursor out of / into any other component (could be entering an hbox, exiting a text input field, etc)
2. Combo boxes behave more or less the same. They can drop them down, but then the mouse wheel no longer refreshes the list. It actually scrolls in the background, but until the user moves the mouse, the list does not refresh
3. We also communicate between the server and client via an amf channel. The events make it to the client, but again, they won't see the screen refresh until they move their cursor.
So basically, the application still seems to work, but the screen is no longer refreshing. Could it be something to do with an invalidate / update of the display list that doesn't kick in? We'd like to get them to install the debugger version of FP, but that doesn't seem to be an option.
Another thing to keep in mind: they have a VERY bad internet connection. They average around 1-1.5mbps (megabits) which is enough for our app, but I just thought I'd let you know.
We learned that they also use a Citrix presentation layer to deploy IE 7 to the end users. We've received confirmation from the end user that even if they launch IE on their workstation (not through citrix), they get the issue also.
Another note is that we've seen no errors in our web server, jboss or application logs...
So that's the update I've got... anyone have more thoughts on this? We've more or less discarded the fonts being an issue at this point since the issue affects more than just 'fonts'. Is everything on the screen not updating anymore.

Resources