Hi Andreas, apologies to now replying to this question on the web vitals feedback group. Was on my To Do list!
Screen-reader users are treated no differently. So provided they are using their screen reader on Chrome and meet the
other user eligibility criteria they will be included.
Enabling a 'skip to main content' will be treated in the same manner as any other interaction. Specifically for each CWV:
- LCP - an interaction "finalises" LCP as interactions can lead to more content loading. Therefore the 'skip to main content' will not be eligible as an LCP candidate (assuming it is only shown on pressing "tab"). It will also not change the selected LCP element. However, as it finalises the LCP element, it can mean that a late-loading large element is not eligible to be consider the LCP is the screen reader user tabs before it loads. This is similar to clicking (on a menu or the like) before the page is fully loaded.
- CLS - a 'skip to main content' is unlikely to cause CLS since it is usually shown on user interaction (the 'tab' key) and shifts within 500ms of interactions are excluded. While CLS is primarily a visual metric, it should be remembers that not all screen reader users are blind so it is still an important metric for these users.
- FID - FID will be finalised with the use of keyboard (e.g. tab to 'skip to main content') as that counts as the first interaction on the page. As FID only measures input delay.
- INP (pending Core Web Vital) - like FID keyboard use will count as an interaction for INP, but INP should give a better measure if responsiveness since it will include all interactions rather than just the first, and measures beyond just the input delay.
So overall, we circle back to my first note: Screen-reader users are treated no differently.
Is there a particular concern you have where you think screen readers will (or should?) impact your Core Web Vitals?
Thanks,
Barry