WCAG 2.2 new zoom level cutting out content on top,sides and bottom of streaming serivcre videos #4872
Replies: 21 comments 14 replies
-
when the authors/developers don't apply them correctly. if content, as a result of it, is cropped/unusable, that fails the requirements already, so it's those streaming services that are doing it wrong/failing. |
Beta Was this translation helpful? Give feedback.
-
|
its really not as the contol bar size pixels had tobe increased which results in video layout breake as none of these videos are made for these guideline |
Beta Was this translation helpful? Give feedback.
-
|
it doesnt matter they only applied thes beacuse of the guildelines it was functional before guildelines wereaccoted, thy adopted wcag2.2 guidelines to avoid suit even if makes proudcut worse |
Beta Was this translation helpful? Give feedback.
-
|
i don't think you quite understood what i said if the media isnt made with
these new ratios in mind, which is a lot, zooming out is not the only thing
that cut content off but 2-000400% scale zoom level your reuerre is
extreme, if its was minimum was set to 110% to 120 it be manual, and of
course streaming services are that have wen version will apply same
coding to all their version which will result in errors, no i know in
disability community like this, or wanted this, what a lot people wanted is
accurate cc, ability to increase audio or change pitch, and accurate type
to text software vice versa, so according to you this while violets this
new wcag2.2, the fault lies with streaming services, did you even into take
into account the technical limitations of increasing zoom for certain
display screen, so since your saying its on their end can you
provide example or instrcutrtion on how the zoom meets minimum target level
without ridiculously cropping videos
Kind Regards
KyleDalton
…On Thu, Jan 15, 2026 at 6:14 PM Patrick H. Lauke ***@***.***> wrote:
*patrickhlauke* left a comment (w3c/wcag#4867)
<#4867 (comment)>
can cause layout issues
when the authors/developers don't apply them correctly. if content, as a
result of it, is cropped/unusable, that fails the requirements already, so
it's those streaming services that are doing it wrong/failing.
—
Reply to this email directly, view it on GitHub
<#4867 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4WNJYWLCGQTIOCXLPEYGBL4G5D5JAVCNFSM6AAAAACRYHVTD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJTGQYTQOJUHA>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
WCAG 2.2 SC 1.4.10 doesn't require 400% zoom. It requires content not require scrolling in 2 dimensions at 320 CSS pixels. It doesn't actually require anything enlarge. |
Beta Was this translation helpful? Give feedback.
-
|
well thats not how its been adopted and it require pixels of ocntrol bar to be larger |
Beta Was this translation helpful? Give feedback.
-
The normative text does not refer to "scrolling in 2 dimensions at 320 CSS pixels". It refers to "Vertical scrolling content at a width equivalent to 320 CSS pixels". Furthermore, all the non-normative notes and the Understanding page refer to zooming and text enlarging. It is very clear that the authors of the SC did not intend it to be tested at 100% zoom - they could have said "at or equivalent to", but they didn't. Issues such as floating elements obscuring other content are far less apparent at 100% zoom and a 320px wide window than in a 1208px window at 400% zoom. I would therefore regard the former as a bad way to do testing even if it was permitted (which I assert it is not). |
Beta Was this translation helpful? Give feedback.
-
|
ir require pixel size to be increased and new minum target is 400%zoom if
that not correcert then its wording is misleading is causing the
problems, (Level
AA)
Content can be presented without loss of information or functionality, and
without requiring scrolling in two dimensions for:
- Vertical scrolling content at a width equivalent to 320 CSS pixels
<https://www.w3.org/TR/WCAG22/#dfn-css-pixels>;
- Horizontal scrolling content at a height equivalent to 256 CSS pixels
<https://www.w3.org/TR/WCAG22/#dfn-css-pixels>.
Except for parts of the content which require two-dimensional layout for
usage or meaning.
Note 1
320 CSS pixels is equivalent to a starting viewport
<https://www.w3.org/TR/WCAG22/#dfn-viewport> width of 1280 CSS pixels wide
at 400% zoom. For web content which is designed to scroll horizontally
(e.g., with vertical text), 256 CSS pixels is equivalent to a starting
viewport height of 1024 CSS pixels at 400% zoom.
Note 2
Examples of content which requires two-dimensional layout are images
required for understanding (such as maps and diagrams), video, games,
presentations, data tables (not individual cells), and interfaces where it
is necessary to keep toolbars in view while manipulating content. It is
acceptable to provide two-dimensional scrolling for such parts of the
content.
Success Criterion 1.4.11 Non-text Contrast
<https://www.w3.org/TR/WCAG22/#non-text-contrast>
Understanding Non-text Contrast
<https://www.w3.org/WAI/WCAG22/Understanding/non-text-contrast.html>|
How to Meet Non-text Contrast
<https://www.w3.org/WAI/WCAG22/quickref/#non-text-contrast>
(Level AA)
The visual presentation <https://www.w3.org/TR/WCAG22/#dfn-presentation> of
the following have a contrast ratio
<https://www.w3.org/TR/WCAG22/#dfn-contrast-ratio> of at least 3:1 against
adjacent color(s):
User Interface ComponentsVisual information required to identify user
interface components
<https://www.w3.org/TR/WCAG22/#dfn-user-interface-components> and states
<https://www.w3.org/TR/WCAG22/#dfn-states>, except for inactive components
or where the appearance of the component is determined by the user agent
<https://www.w3.org/TR/WCAG22/#dfn-user-agents> and not modified by the
author;Graphical ObjectsParts of graphics required to understand the
content, except when a particular presentation of graphics is essential
<https://www.w3.org/TR/WCAG22/#dfn-essential> to the information being
conveyed.as righ there size is being told to be increased
Understanding Visual Presentation
<https://www.w3.org/WAI/WCAG22/Understanding/visual-presentation.html>|
How to Meet Visual Presentation
<https://www.w3.org/WAI/WCAG22/quickref/#visual-presentation>
(Level AAA)
For the visual presentation of blocks of text
<https://www.w3.org/TR/WCAG22/#dfn-blocks-of-text>, a mechanism
<https://www.w3.org/TR/WCAG22/#dfn-mechanism> is available to achieve the
following:
- Foreground and background colors can be selected by the user.
- Width is no more than 80 characters or glyphs (40 if CJK).
- Text is not justified (aligned to both the left and the right margins).
- Line spacing (leading) is at least space-and-a-half within paragraphs,
and paragraph spacing is at least 1.5 times larger than the line spacing.
- Text can be resized without assistive technology
<https://www.w3.org/TR/WCAG22/#dfn-assistive-technologies> up to 200
percent in a way that does not require the user to scroll horizontally to
read a line of text on a full-screen window
<https://www.w3.org/TR/WCAG22/#dfn-on-a-full-screen-window>.
- as you can see and many compines will simply apply that feature or new
zoom across board as it is cheapset option for them
Note 1
Content is not required to use these values. The requirement is that a
mechanism is available for users to change these presentation aspects. The
mechanism can be provided by the browser or other user agent. Content is
not required to provide the mechanism.
Note 2
Writing systems for some languages use different presentation aspects to
improve readability and legibility. If a presentation aspect in this
success criterion is not used in a writing system, content in that writing
system does not need to use that presentation setting and can conform
without it. Authors are encouraged to follow guidance for improving
readability and legibility of text in their writing system.
…On Fri, Jan 16, 2026 at 12:46 AM Jonathan Avila ***@***.***> wrote:
*mraccess77* left a comment (w3c/wcag#4867)
<#4867 (comment)>
WCAG 2.2 SC 1.4.10 doesn't require 400% zoom. It requires content not
require scrolling in 2 dimensions at 320 CSS pixels. It doesn't actually
require anything enlarge.
—
Reply to this email directly, view it on GitHub
<#4867 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4WNJYQV7LNS2TD3MYCA27D4G6R6FAVCNFSM6AAAAACRYHVTD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJVGIZDOMBYGM>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
you can test at 100% if you resize your browser window, or are on a device with a limited size screen, that in the end shakes out to a width of 320 CSS px. not quite sure what you're arguing around here... in any case, going back to the original question: this isn't going to change in WCAG 2.x. |
Beta Was this translation helpful? Give feedback.
-
|
right so this ruins perfctlryfuyunctional sericvres |
Beta Was this translation helpful? Give feedback.
-
As I said in my previous post, issues such as floating elements obscuring other content are far less apparent at 100% zoom and a 320px wide window. If you test at that zoom level, you're going to miss issues that affect people who use higher zoom levels. And they are precisely the people who the SC is aimed at. It's not aimed at people with very narrow browser windows or screens. 100% zoom and a 320px wide window is not the same as 400% zoom and a 1280px window unless you reduce the height of the 320px wide window to a quarter of its normal height (and maybe not even then). It's so trivially easy to do this test properly at 400% zoom, that I truly don't understand why anyone is arguing against doing so. |
Beta Was this translation helpful? Give feedback.
-
|
no it was 100 percent zoom video content is cut out, beascue pixel bars, and certion other elments have to be increased to 400% |
Beta Was this translation helpful? Give feedback.
-
|
but this new zoom minum ruins layout for almost all forms of media as they
are not designed for all this new target going to do is cut content out or
force people to newer devivces
…On Fri, Jan 16, 2026 at 4:25 AM Test Partners Ltd ***@***.***> wrote:
*TestPartners* left a comment (w3c/wcag#4867)
<#4867 (comment)>
you can test at 100% if you resize your browser window, or are on a device
with a limited size screen, that in the end shakes out to a width of 320
CSS px. not quite sure what you're arguing around here...
As I said in my previous post, issues such as floating elements obscuring
other content are far less apparent at 100% zoom and a 320px wide window.
If you test at that zoom level, you're going to miss issues that affect
people who use higher zoom levels. And they are precisely the people who
the SC is aimed at. It's not aimed at people with very narrow browser
windows or screens.
100% zoom and a 320px wide window is not the same as 400% zoom and a
1280px window unless you reduce the height of the 320px wide window to a
quarter of its normal height (and maybe not even then).
It's so trivially easy to do this test properly at 400% zoom, that I truly
don't understand why anyone is arguing against doing so.
—
Reply to this email directly, view it on GitHub
<#4867 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4WNJYTECZSCZW6OIOTJFE34G7LQ5AVCNFSM6AAAAACRYHVTD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJWGI3TGNRUG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
@TestPartners wrote:
I agree that is is useful to test with 400% zoom starting from 1280 viewport width for the reasons you give, and record any issues that arise. Normatively though, the requirement does not say anything about fixed content or about how much space should remain for content to still pass after magnification. It also does not define the viewport height to test at which makes all the difference regarding cover-up issues. You can call it a loophole but that is what is in the normative text. So I think @patrickhlauke is right to treat 100% at 320px as equivalent in terms of the normative ask of 1.4.10. There may be other SCs such as 2.4.11 Focus Not Obscured that may catch situations where fixed content hides other content. |
Beta Was this translation helpful? Give feedback.
-
But that's not what the normative text says. It refers to "Vertical scrolling content at a width equivalent to 320 CSS pixels". It does not say "at or equivalent to 320 CSS pixels". You are right that the requirement does not say anything about how much space should remain for content to still pass after magnification. But we shouldn't just ignore it - we should make an intelligent subjective judgement, as we do with many other success criteria. And to do that, we should consider how people will view the page - many people use magnification, but I suspect that almost no one uses a 320px wide viewport at 100% zoom. |
Beta Was this translation helpful? Give feedback.
-
|
and that is issue 320px shoudnt be mandtory as it is breaking servicres |
Beta Was this translation helpful? Give feedback.
-
|
i am saying new target of 400% is resulting layout breaks
…On Fri, Jan 16, 2026 at 9:34 PM Test Partners Ltd ***@***.***> wrote:
*TestPartners* left a comment (w3c/wcag#4867)
<#4867 (comment)>
So I think @patrickhlauke <https://github.com/patrickhlauke> is right to
treat 100% at 320px as equivalent in terms of the normative ask of 1.4.10.
But that's not what the normative text says. It refers to "Vertical
scrolling content at a width *equivalent to* 320 CSS pixels". It does not
say "*at or equivalent to* 320 CSS pixels".
You are right that the requirement does not say anything about how much
space should remain for content to still pass after magnification. But we
shouldn't just ignore it - we should make an intelligent subjective
judgement, as we do with many other success criteria. And to do that, we
should consider how people will view the page - many people use
magnification, but I suspect that almost no one uses a 320px wide viewport
at 100% zoom.
—
Reply to this email directly, view it on GitHub
<#4867 (comment)>, or
unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4WNJYQD5BPFVWTY576BQ534HDEEJAVCNFSM6AAAAACRYHVTD2VHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTONJZGYZTKNZTG4>
.
You are receiving this because you authored the thread.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
I believe you are trying to make a distinction where it doesn't exist. when you zoom, you DO change the CSS pixel width of the window, and it IS 320 CSS pixels if you started at 1280 and zoomed 400%. the "equivalent" was used to also cover things like PDFs where the unit of measure isn't necessarily CSS pixels (and though nominally not covered by WCAG, environments such as native iOS which uses "points", or Android native development which uses "density-independent pixels" as the measure - which are conceptually equivalent to CSS pixels in that they don't mean actual physical pixels, and are independent of the actual pixel density used) |
Beta Was this translation helpful? Give feedback.
-
|
but that what its says for pixels controls to be increasred two which messes up boarder of videos |
Beta Was this translation helpful? Give feedback.
-
|
Converted to a discussion, as the original issue was closed since there won't be any fundamental changes to the reflow requirement in 2.x. any further discussion can probably be used to inform what is done in WCAG 3 eventually. |
Beta Was this translation helpful? Give feedback.
-
|
right so bassci;y you guys dont undertsand how much you brokre with these guidelines as while guidelines may be fine real world impact is streching videos |
Beta Was this translation helpful? Give feedback.
-
|
I note that the test procedure for failure technique F102 specifically allows testing with a 320px wide viewport, even though the SC itself doesn't have a test procedure. I don't know why it is permitted, given that it prevents issues relating to floating elements from being identified, but it seems that I am in a minority in thinking this is a problem. I would like to see this tightened up in WCAG 3 such that the normative text and the test procedure more closely reflect realistic user behaviour, i.e. using magnification rather than an ultra-narrow viewport. By default, you can't reduce the width of a Chrome window below 520px, although I think there are "hidden" settings that allow you to do so. But why would anyone do that? And do they? |
Beta Was this translation helpful? Give feedback.
-
|
Am I right in thinking that although there is an interesting discussion about 1.4.10 here, the concern of the person who raised the issue is being completely ignored?
|
Beta Was this translation helpful? Give feedback.
-
|
i cant unfountrely proivde sceeenshots before impletion of 1.4.10 asmuch as i would like to as all devices i have have been updated to new reurimrents wether thats the broswer or the os of devcies i would not now i can proivde you about screenshot of control pixels and how things are cut off in videos but thats it |
Beta Was this translation helpful? Give feedback.
-
|
also for many text reading online suchas ebooks i have to zoom out to 90or 75 percenrt to read as now 100 percent cuts stuff out |
Beta Was this translation helpful? Give feedback.
-
|
@kyledalton16-hub If content is not visible even without zooming (i.e., when displayed at 100%), then this probably has nothing to do with WCAG SC 1.4.10 Reflow, but is a functional error that affects all users. Or are you referring to the display at 100% zoom on devices with small displays, such as a smartphone? In that case, it is of course possible that the display has deteriorated due to an incorrect attempt to comply with 1.4.10. I often see this in WCAG audits. Whereas previously a fixed layout was used, requiring horizontal scrolling at 400% zoom or on a smartphone, now attempts are made to reflow the content and prevent horizontal scrolling. This sometimes results in content being lost. This is an undesirable side effect of incorrect implementation of 1.4.10, which actually worsens the perceptibility of the content, because worse than horizontal scrolling is not being able to perceive the content at all. |
Beta Was this translation helpful? Give feedback.
-
|
first pf all dont use smartphones for that puporse, second i didnt havezooming or croppoing issue, until wcag2.2 new critrea was supposted to be done by in june of 2025, seond the new targert minium for zoom even at 100 percenrt browaser zoom the new pixels controls or ui ux layout results in layout breaks |
Beta Was this translation helpful? Give feedback.
-
|
first pf all dont use smartphones for that puporse, second i didnt havezooming or croppoing issue, until wcag2.2 new critrea was supposted to be done by in june of 2025, seond the new targert minium for zoom even at 100 percenrt browaser zoom the new pixels controls or ui ux layout results in layout breaks |
Beta Was this translation helpful? Give feedback.
-
|
@kyledalton16-hub Without a URL or screenshot, we can't proceed any further. Incidentally, SC 1.4.10 has been in existence since WCAG 2.1 (adopted in 2018). WCAG 2.2 was adopted in 2023 and does not contain any new regulations regarding zoom (https://www.w3.org/TR/WCAG22/#new-features-in-wcag-2-2). |
Beta Was this translation helpful? Give feedback.
-
|
well not in austrelia, https://www.crunchyroll.com/discover any videos on siad site when playling is cropping out heads |
Beta Was this translation helpful? Give feedback.
-
|
again i don't have screenshots of before it was implemented as in
Australia it wasn't implemented until april of 2025, and i didnt know they
were going to do this, second i give screenshots of my scaling is messed up
on my devices, but a lot of video display be blocked due to drm, also they
increasred their target zoom to 400% even know i am using 100%or90% it
doesnt look right ninety looks lime what 100 used to be, and companies will
do cheapest thing possiblid instead of keeping old zoom levels they
increased and strechred the media for a new ridiculous 400 percent for
everything
Kind Regards'
Kyle
…On Wed, Jan 21, 2026 at 5:10 PM JAWS-test ***@***.***> wrote:
@kyledalton16-hub <https://github.com/kyledalton16-hub> Without a URL or
screenshot, we can't proceed any further. Incidentally, SC 1.4.10 has been
in existence since WCAG 2.1 (adopted in 2018). WCAG 2.2 was adopted in 2023
and does not contain any new regulations regarding zoom (
https://www.w3.org/TR/WCAG22/#new-features-in-wcag-2-2).
—
Reply to this email directly, view it on GitHub
<#4872 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4WNJYWKWYP5ITYTQMGMGV34H4Q6BAVCNFSM6AAAAACR5CICX6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNJVGY2DENA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
-
|
https://www.crunchyroll.com/discover, netflix youtube and hidive when ui was upadted for these new ridcilous targerts |
Beta Was this translation helpful? Give feedback.
-
|
@kyledalton16-hub I can't see any display errors on the pages you mentioned. |
Beta Was this translation helpful? Give feedback.
-
|
right if you dont have crunchyrolly you wont be able to see that video itself is strechred can videos being atched here if so i can show but filesare to big |
Beta Was this translation helpful? Give feedback.
-
|
well due to drm protection hard to send screenshots
…On Fri, Jan 30, 2026 at 10:11 PM JAWS-test ***@***.***> wrote:
@kyledalton16-hub <https://github.com/kyledalton16-hub> I can't see any
display errors on the pages you mentioned.
—
Reply to this email directly, view it on GitHub
<#4872 (reply in thread)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/B4WNJYWCFCS7ERM2KRHOUS34JNC6LAVCNFSM6AAAAACR5CICX6VHI2DSMVQWIX3LMV43URDJONRXK43TNFXW4Q3PNVWWK3TUHMYTKNRVGA2DAOA>
.
You are receiving this because you were mentioned.Message ID:
***@***.***>
|
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
WCAG 2.2 standards, specifically those aimed at improving accessibility for users with low vision (such as requirements for 400% zoom and larger interactive targets can cause layout issues where content appears too zoomed in, crowded, or improperly scaled on streaming service interfaces. While intended to make services more accessible, the implementation has led to frustrations where interface elements are too large or, conversely, where content is not properly responsive, leading to unintended zoom or, in some cases, content being cut off., this frusrtriang no one sked for this reidcoucs zoom level, i have not be able to use my paid subscriptions beauces of this
Beta Was this translation helpful? Give feedback.
All reactions