Change 1.4.10 Reflow to level A #1050
Comments
|
Changing the success criterion level is a breaking change. I'm against such a change. See the conversation about it here: #1041 |
|
I'd still note that I don't believe "There is one thing you that would make a big difference for people with low vision. Change Reflow 1.4.10 from AA to A" will have any actual real-world impact on a site/application's willingness to adhere to the SC. whether the SC is A or AA is possibly more of a "signal" than anything that influences developers to implement something or not. as said, if a developer has been unable to meet/ignored the SC when at AA, it won't make them more keen to rethink their approach if it was A. also, this kind of thinking also reinforces what we keep trying to say ISN'T the case...that A is more important than AA which in turn is more important than AAA. there's other factors that supposedly influence what level is given to an SC, including how much impact it would have to adhere to an SC in terms of layout/functionality. and for complex web apps (imagine something like a fully-fledged code editor/word processor/3D visualisation tool) i'd say the requirement of "must work without scrolling/without dropping any functionality even at mobile-sized viewport" is a not-inconsiderable ask. |
|
I want to ask the same question I'm posing in #1041; what has changed since we published WCAG 2.1 to justify such a change? |
|
Same point I just made in #1041: Look at WCAG 2.x Priority levels discussion and the patterns for which SC landed at A versus AA. As a requirement that is Essential but not Easy and not Invisible, 1.4.10 fits the AA grouping. The few single A SC which break this pattern are the requirements for captioning and alternative formats. |
|
Given that most policies include level A and AA I don’t believe a change will make that much of a positive difference and it will cause more problems for tooling and tracking. Id vote to keep at AA. |
|
The reason I wanted to tackle this at the same time as other reflow issues is updating / adding an SC for reflow 'down to' rather than 'at' 320px: Assuming we thought it was a good requirement to add/increase, we have various options:
My personal priority of concerns for updates to 2.2 (chair hat off) is:
All the options for reflow updates meet 1. Of the options I could think of (feel free to point out if I've missed something), I think my preferences would be either: Update reflow to A and add another at AA (like the current focus-visible update), or depricate/supercede reflow and add a new 'down-to' SC at AA. |
|
I think the change from "at 320 px" to "down to 320 px" is very important. I don't care which way is chosen, but I would prefer the last one: "Depricate reflow and add a new SC for reflow at AA for down-to" |
|
I agree that “down to 320px” is very important. It is also much more difficult, and I remain skeptical that it is testable in any practical sense. My vote would be to keep 1.4.10 as-is and at AA. Then add a new SC very much like 1.4.10 but it uses “down to” instead of “at” at AAA. The new AAA SC should also drop the “Except for parts of the content which require two-dimensional layout for usage or meaning” bit. If we want to try and make 2.2 a little bit more coherent, and I think we should, we could promote 1.4.4 to single A. |
I'm not sure why? If you are testing for text-sizing and text-spacing over different page variations then the only extra bit is watching for missing info/functionality or horizontal scrolling. Also worth reading through this for the implications of page variations on text-sizing tests: |
|
^ But how many "different" page variations are sufficient? By comparison, the "at 320px" is very specific. |
|
it may be specific to say "at 320px". but it's practically useless for any users whose viewport is not exactly 320px. per https://www.w3.org/TR/WCAG21/#cc2 each variation needs to be tested for other SCs. i'd say a sensible initial assumption would be that to test you'd start at the largest of those variations and work your way down until you reach 320 CSS px as the lowest bound. [ed: to clarify, "work your way down" meaning you then from that largest dimension keep decreasing the window/viewport size in 1 CSS px decrements until you reach 320 CSS px] |
|
Yikes, I missed that change to CC2! The sentiment is good, but I am not sure that is the best fit for the requirement. Also, the formatting and the emphasis on the word NEW was lost.
Exactly. This is the implication that I find onerous. |
|
That change was from back in 2017, survey results, and had a lot of discussion in #391 We do test across variations (generally breakpoints) by zooming or window manipulation. I wouldn't say we view every pixel increment, but it is pretty easy to spot things as you zoom in /out. If you see things get too close, you can adjust the window between zoom-points to narrow in for that instance. We generally find that sites either fail in a big way, or you just find the odd bug. |
|
@alastc I so very much appreciate your ability to point to survey results! Right, you wouldn't view every pixel increment. But it seems to me that people are asserting that this is what "down to 320px" requires. Which is why I am of the opinion that keeping 1.4.10 at AA and "at 320px" is the correct choice at this moment in time. CC#2 already lets testers fail 1.4.10 for sizes "down to" 320px, so there is no compelling reason to bake that sort of minutia into 1.4.10 explicitly. |
No, sorry, I should have been clearer: We test and fail across page variations for text-size & text-spacing. For reflow we can only fail that at 320px wide. In most cases something that triggers scrolling or disappears at 900px or 600px wide will also do so at 320px wide. However, given that we are already testing the others across variations it is easy to note reflow issues that only occur above 320px under 'best practice'. What we are really talking about (with 'down-to') is catching those relatively rare instances of things that fail between no zoom and 400% (or equivalent) zoom. |
|
and with my suggested process of decrementing by 1px down to 320 I was outlining the test procedure IF we changed the "at 320 CSS px" to "down to 320 CSS px" (as that's the only way to catch "those relatively rare instances") |
|
An implied or explicit process of decrementing by 1px down to 320 is exactly the sort of test procedure that is counter-productive, IMHO. |
|
how else are you going to catch things if we change things to "down to"? and just exclusively making 320 CSS px the only size at which reflow must be met (for vertical-scrolling content) only helps users that started off with 1280 width screen resolution and zoomed to 400%. if they have a different-sized screen (e.g. they do use 1600x1080 or something else, because they do have a physically large enough screen that allow them to still go for that size) and then zoom to 400%, or if they do have a 1280 sized screen but only need 300% magnification, a site can quite happily have two-dimensional scrollbar and/or loss of content/functionality and still be perfectly fine in light of 1.4.10 as it currently stands... [edit: and to clarify, in practice the test is would be executed by opening a test page/sample with the browser window on desktop at full large size, and then dragging/resizing the window progressively down to 320 and checking if two-dimensional scrollbars happen/stuff gets lost or cut off] |
I don’t disagree that, in actual practice as an experienced tester, testing for “down-to” can be quick and efficient. My concern is for scripts getting written, as has happened in this very thread, that call for testing pixel-by-pixel. Which is why, absent a better alternative, I am arguing for keeping 1.4.10 as-is and adding a new AAA SC. |
Actually it isn't as easy as that. On a small page yes, you could just drag it smaller and watch for anything that starts to go wrong. But large commercial sites usually have very long pages, going down several times the height of the average screen. You may have to scroll the whole page seven or eight times to check from top to bottom. It wouldn't be any good looking at the top of the a clean page if something is going wrong below the fold. Theoretically you would have to scroll down or back up each time you make the check (scroll down or up every pixel??? - we'd be there for forever and a day - and that would have to be repeated for every page being tested!) The usual way is to look for breakpoints and check nothing has gone wrong just before one of them is triggered. Not so bad if there are just two breakpoints, for tablet and mobile. But if the developer has multiple breakpoints on different pieces of content, then it becomes tricky. So while you should check for all widths of screen, not just the 320px end point (and many consultants will do that), we need some way of limiting the amount of testing that has to be done. |
|
I'm a bit concerned with some of the assumptions above, particularly comments like this:
(I assume that last number was supposed to be 256) It is extremely hard to overstate how much work is required to both interpret and try to meet Reflow for anything beyond a basic content-centered website. I don't believe there is a single other criterion that imposes the same level of burden that Reflow does on complex web apps. It has been very frustrating to watch people become demoralized about working on accessibility when they realize they'll never meet WCAG AA, just because of Reflow. Particularly when the criterion can seem so entirely divorced from a good user experience for their product. I also personally have doubts about whether the enormous amount of work required to meet Reflow has a corresponding payoff, when talking about an interface past a certain level of UI complexity. I don't mean that in the sense of "it's not worth it to do the necessary work to make products accessible for people with low vision," I mean that in the sense of "I find it difficult to imagine any possible way for an app like Visual Studio or a complex interrelated analytics dashboard to be usable at a screen size of 320x256px, especially compared to the experience with magnification software." The "Except for parts of the content which require two-dimensional layout for usage or meaning" doesn't help in the above cases, both because it both only applies to those individual parts, and also often nothing in the app strictly depends on two-dimensional layout; it is the overall complexity of the UI that is responsible for the difficulty meeting Reflow. Unfortunately "overall UI complexity" is hard to measure. There is certainly work that complex web apps could do to be more accessible to low vision users, but I am increasingly convinced that Reflow, as written today, is a distraction to that work. Rather than moving it to level A, I would strongly suggest considering moving it to AAA, and introducing a new requirement that centers around the reflow of text content, or pages whose primary purpose is to present static content. Please forgive me if this comes off a bit strong; I'd like to think that if anyone else in this thread had been involved in the same months upon months of torturous discussions around reflow that I have, they would be equally frustrated today :). |
I totally agree. Level A should become part of SC 1.4.8:
200% could be replaced by 400%. |
|
Hi All,
I was a little flippant about the ease of Reflow. It is as hard as
implementing any level A or AA criterion if your website hasn't addressed
that problem before. Let's be honest. All WCAG is hard if you never planned
for it. Even if you have met WCAG 2.0 Level AA, you likely haven't planned
for reflow.
When we discussed requirements for low vision in the LVTF, there was one
requirement that every member supported enthusiastically. That was reflow.
It serves people with tunnel vision by enabling short lines that word wrap.
It serves people with poor visual acuity because it enables sufficient
enlargement with word wrapping.
Accessibility guidelines change for two reasons: technology changes and our
understanding of disability changes.
When WCAG 2.0 was adopted there was no responsive design and our
understanding of low vision accommodation was taken from a paper
prospective. 200% enlargement is all that is possible for print on paper.
Also, nobody realized just how much overhead was caused by 2-dimensional
scrolling. Nobody liked it, but nobody really realized it was as terrible
as my calculations revealed.
When 2.1 came around it was time to adjust these earlier shortcomings of
2.0. The 400% enlargement of 1.4.10 is sufficient for a wide range of low
vision. For vision better than 20/100, one can read efficiently without
excessive errors at near the intended reading distance. If the reading
distance is cut in half or a little more the enlargement is sufficient up
to 20/200. The reflow is simply a necessity for reading intelligently.
With WCAG 2.0 we didn't have an SC that ranked as Level A importance for
low vision. With 2.1 we do have one, 1.4.10.
While Level A has little impact for conformance among experts, it does have
a strong psychological impact. People value Level A criteria more. That is
a reality.
Hard or easy, it is the most necessary criterion for low vision.
Best, Wayne
…On Sat, Feb 29, 2020 at 12:52 AM JAWS-test ***@***.***> wrote:
Rather than moving it to level A, I would strongly suggest considering
moving it to AAA, and introducing a new requirement that centers around the
reflow of text content
I totally agree. Level A should become part of SC 1.4.8:
Text can be resized without assistive technology 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
200% could be replaced by 400%.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1050?email_source=notifications&email_token=AB6Q4F2LMQI33GYFMIVVVGDRFDGGRA5CNFSM4K4A6CM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENLUH2A#issuecomment-592921576>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F6YDKPVDSQFMCAZUCTRFDGGRANCNFSM4K4A6CMQ>
.
|
1.4.10 does not require a 400% zoom. It only requires reflow. Zoom is required at most 200% (SC 1.4.4) I also think reflow is very important, but not for the whole page, but only for the lines of a text column. Someone with visual impairment has hardly any disadvantage, because it is necessary to scroll horizontally to read the next column. Therefore I would require reflow for a text column with level A and reflow for the whole page to level AAA. I would also remove the 200% exception for reflow and require that at 400% all content is also enlarged by 400%. However, a minimum size can be defined (e.g. for already large headlines) that do not need to be enlarged by 400%. |
|
"1.4.10 does not require a 400% zoom. It only requires reflow. "
This misses the main point. 1.410 enables effective enlargement using
browser zoom. I quote from Understanding 1.4.10.
"320 CSS pixels is equivalent to a starting 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."
1.4.10 was designed to solve the size and reflow problem in one place using
simple browser zoom. It works.
Best, Wayne
|
That was the intention, but unfortunately does not correspond to the wording of the SC and the understanding:
If we really want to support 400% zoom, we should
The exception for two-dimensional content should also be more clearly formulated. For example, while tables in their entirety are an exception, the exception should not apply to table cells and their contents. This is currently not clearly regulated (see #932 (comment)). A height should also be specified (see #987) |
|
"That was the intent but unfortunately does not correspond to the
wording..."
I was in on the writing of this SC and I am not sure what loophole you are
asserting. If such an unintended loophole exists we should close it.
Wayne
…On Sun, Mar 1, 2020 at 10:50 PM JAWS-test ***@***.***> wrote:
1.410 enables effective enlargement using
browser zoom
That was the intention, but unfortunately does not correspond to the
wording of the SC and the understanding:
https://www.w3.org/WAI/WCAG21/Understanding/reflow.html#the-relation-of-reflow-to-the-success-criterion-1.4.4-resize-text
In an implementation where text does not consistently increase its size as
people zoom in (such as when it is tranformed based on a media query to
adapt to small-screen usage), it must still be possible to get to 200%
enlargement in order to satisfy the Resize Text criterion
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1050?email_source=notifications&email_token=AB6Q4F77D3GRVRVLS3VJM6DRFNJMZA5CNFSM4K4A6CM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENOD6XI#issuecomment-593248093>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F6YUDTNDTLR5ITLH7LRFNJMZANCNFSM4K4A6CMQ>
.
|
|
Coding with low vision does not look like it was represented above:There are two reasons. 1) People with full sight or blindness cannot imagine how people with low vision work without visual or audio cues that guide the work of the fully sighted or blind. 2) People with low vision learn their base system very well so they can use every tool available to create a screen that is visible and useable. Here are shots of my PyCharm windows. PyCharm has tools that make personalisation possible. That is really what accessibility is all about. Making it possible for other views of programs to support the entire scope of disability. Images of PyCharm pages.
The first is the view I use while I am coding. This example shows that the The second is the project tree view. I have pulled out some menus to show Finally we have the structure view added to show the object structure. You should note that many visual toolbars are missing. I operate from Now,PyCharm is a little less stupid than forcing you to zoom the whole I function as follows. I use mono fonts because they have a smaller That is how it works. Notice how line 2, the "symbols" definition, word wraps the string "('x y A If I need a toolbar or status bar I can always add it in for my action and As I said, it is not easy. But it is possible. Think of PyCharm as a system that has designed a system of drawers that can be opened and shut as needed. I believe this is the true accessibility model for professional desktop applications. It is true, I did not use zoom only. Unfortunately, we could not get SC's Best, Wayne |
|
Dear Sarah,
I hope you found my images and use method for enlargement useful. That is
how I code, and do mathematics.
I think having panels and toolbars that open and shut is a viable way to
meet 1.4.10 with applications. I know this problem is difficult. It is like
going back 10 when we were just starting.
As you know as a programmer, we learn things in shells, one layer at a
time. WCAG really looked at inter-modal access. ARIA, the accessibility
API's, the barrier between the assistive technology and the page (or app)
code were taken as essential. They worked as long as you wanted to map text
to a rich audio interface or voice to print, but with people like me and
those with cognitive issues the translation we need is intra-modal. I need
a different print interface. People with cognitive disabilities need less
clutter interfaces.
These differences are difficult for a person with full sight and no
cognitive issues to visualise. My wife used to tell me when I'd get
frustrated with the pace of change, "Wayne, people cannot see what they
cannot see." I'm glad I have my wife. She's a nurse, and she keeps me in
reality.
I do think we need to define the tools for achieving enlargement with
reflow. It is a profound problem. We will work on some techniques that will
help developers. I promise, before I retire completely (I'm 72) I help with
some useful techniques.
Please forgive us for throwing this curveball to all you who did your best
to conform to accessibility. We just learned new stuff. I didn't even prove
the complexity involve in reading with horizontal scrolling until a year
before WCAG 2.1 came out. Know body knew just how bad it was before.
I went all the way through grad school and taught computer science for 30
years before I calculated the operational overhead. When I read the
Algorithms book from MIT for teaching a graduate class, I made over 100,000
horizontal scrolls. I'm glad I didn't know that before I started.
Best, Wayne
…On Sat, Feb 29, 2020 at 12:47 AM Sarah Higley ***@***.***> wrote:
I'm a bit concerned with some of the assumptions above, particularly
comments like this:
It is dead simple to make a case that works at 320 by 768.
(I assume that last number was supposed to be 256)
It is *extremely* hard to overstate how much work is required to both
interpret and try to meet Reflow for anything beyond a basic
content-centered website. I don't believe there is a single other criterion
that imposes the same level of burden that Reflow does on complex web apps.
It has been very frustrating to watch people become demoralized about
working on accessibility when they realize they'll never meet WCAG AA, just
because of Reflow. Particularly when the criterion can seem so entirely
divorced from a good user experience for their product.
I also personally have doubts about whether the enormous amount of work
required to meet Reflow has a corresponding payoff, when talking about an
interface past a certain level of UI complexity. I don't mean that in the
sense of "it's not worth it to do the necessary work to make products
accessible for people with low vision," I mean that in the sense of "I find
it difficult to imagine any possible way for an app like Visual Studio or a
complex interrelated analytics dashboard to be usable at a screen size of
320x256px, especially compared to the experience with magnification
software."
The "Except for parts of the content which require two-dimensional layout
for usage or meaning" doesn't help in the above cases, both because it both
only applies to those individual parts, and also often nothing in the app
strictly depends on two-dimensional layout; it is the overall complexity of
the UI that is responsible for the difficulty meeting Reflow. Unfortunately
"overall UI complexity" is hard to measure.
There is certainly work that complex web apps could do to be more
accessible to low vision users, but I am increasingly convinced that
Reflow, as written today, is a distraction to that work. Rather than moving
it to level A, I would strongly suggest considering moving it to AAA, and
introducing a new requirement that centers around the reflow of text
content, or pages whose primary purpose is to present static content.
Please forgive me if this comes off a bit strong; I'd like to think that
if anyone else in this thread had been involved in the same months upon
months of torturous discussions around reflow that I have, they would be
equally frustrated today :).
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#1050?email_source=notifications&email_token=AB6Q4FZM64765XFPWWGMPOLRFDFTTA5CNFSM4K4A6CM2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOENLUEVI#issuecomment-592921173>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AB6Q4F6U7ISVI6ACOYMKHQ3RFDFTTANCNFSM4K4A6CMQ>
.
|
That's not in the Understanding. Can that be added? Can we agree on a minimum size that a text must reach at 400% zoom?
Unfortunately, I cannot see what should be complex about this. Furthermore, the requirement that a block of text does not have to be scrolled,
I think this requirement should be added in the Understanding.
Too big:
Can this be added in the Understanding? |
|
@WayneEDick I appreciate you sharing those screenshots, and also your commitment to making things better for low vision users. I think we're actually aiming for the same thing, and your screenshots and description of how you use PyCharm actually match pretty well with what I've been hearing and observing from other low vision users in similar use cases. (everything below is my personal opinion and observation, not my approach as a Microsoft employee) The accessibility features you're using, and the way you combine screen zoom with selective text resizing are actually the exact sort of use cases I would like to spend time targeting and improving, because those seem to be how actual people are using products like PyCharm. Work could be done on features like the following:
This is actually the very reason I commented on this issue, and the reason I think we actually agree. I have not found any indication that people actually use products like Visual Studio or Photoshop or PowerPoint at an effective screen size of 320x256px. They use other methods, like what you shared. Techniques like collapsing or resizing panels, and allowing line wrapping in a code editor (which actually is not required by reflow) are extremely helpful to real users, but do not enable products to meet Reflow. This is my worry. We're making product teams chase their tails to meet a legal requirement that doesn't reflect how people with low vision actually use their product. I personally would like them to My position has never been that we shouldn't be doing work to make products better for low vision users, or that "it's just too much work"; it has always been specifically that Reflow is the wrong work when considering a certain type of product; and worse, it's a significant amount of wrong work. The decisions made to improve experience at a 600x400px screen, or a 800x600px screen with text size increases are not the same decisions that would be made to target a 320x256px screen. The Reflow criterion pushes teams towards implementing the latter, targeting a form factor that it appears is not actually used in the real world (at least not beyond in-browser zoom on websites and simpler apps). I want to incentivize product designers to make decisions that are best for disabled users, not best for legal risk. I'm not comfortable highlighting specifics of our products in a github thread, but let's just say that there are certain features in certain products that are not possible to make functional at a 320x256px screen, even when allowing multiple areas to have 2-dimensional scroll. The technique that works in those cases is to drastically reduce text size. This is allowed by Reflow, therefore teams are incentivized to reduce text size on zoom. In other cases, there are interrelated regions that do not strictly "require" 2-D layout for meaning, but still significantly decrease usability if stacked. There are potential better solutions that involve e.g. expand/collapse controls, and those would work with a target screen width of 500px or 600px, but not a target width of 320px. Reflow incentivizes teams to stack those components instead of investigating whether that is best for real users. @alastc I can't really think of a way to phrase this that doesn't risk coming off poorly (not my intention), so I'll just ask directly: are you aware that Visual Studio and VS Code are entirely separate products? VS Code is not a good example of where Reflow falls apart, largely for the reasons you outlined above. I don't think there's much more I can add here that would be useful, so I'm going drop after this; if you feel like you still don't understand where I'm coming from, I'd be happy to chat outside this thread in real time. Otherwise, I hope you at least consider the possibility that the normative text of Reflow is working against usability in certain cases. Thanks for your time :) |
If you look at Wayne's (or my) screenshot, the desktop is not that size, but the interface window (including zoom level) is in that ballpark. Also, the SC doesn't require that the entire interface fits into that size view. It requires that for vertically scrolling content it works in a 320px width, and for horizontally scrolling content it works in a 256px height. Which leads to the next bit:
I'm not sure where that comes from, the first example in the understanding page shows the main menu being automatically hidden at higher zoom. The section on visibility/availability talks about that as well. Collapsing/re-sizing panels, automatically or manually is a valid technique. It doesn't come up much for more content-oriented websites, but I don't see why that wouldn't conform. The requirement for conformance of full pages has this note:
I.e. if you can access an alternative form of that content from the interface, that is a method of conforming. The user being able to customise the interface to adapt for smaller viewports / higher zoom is an appropriate approach.
Yes, but I only use VS code and might conflate them sometimes, apologies.
If the reason those areas have to be onscreen at the same time is due to the relationship between them (e.g. there is an edit area on one side, and the status of that thing is shown on the other), that would fit the exception and scrolling would be allowed. It is hard to make that call without specifics, but that was the intent of the exception. |
|
Hi @JAWS-test,
It is under the "The relation of Reflow to the Success Criterion 1.4.4 Resize Text" heading. Regarding table cells and blocks of text, we had that discussion in (around) 2016. Yes it's important, but so is not hunting around a layout (as you have to with magnification-style size increases). Adding a sub-clause to reflow for items that fit the exception (like table cells) and adding a requirement that they are not bigger than the height/width would be more complex for people to understand. Also, once we can see people applying reflow it is easier to see how big an issue it is.
We can add clarity, possibly advice, but we can't add requirements directly in the understanding.
For what viewport height? At the minimim outlined in the SC (256px)? What if the viewport is a bit higher, go with a percentage? What if the width affects how high the header/footer is due to wrapping? (quite a common thing). We'll deal with that in #987, I'm just pointing out it is not straightforward. |
|
Hi @alastc
This chapter says:
What I think is missing at this point is the hint that this exception (that's how I understood the GitHub discussions on the subject) should not apply to small text, but to large text such as headlines. So my question would still be whether this can be added in the Understanding and whether we can define a minimum size for which 200% instead of 400% zoom is sufficient |
|
This SC is not targeting a 320x256 screen. What it's attempting to do is target the veiwport a user with low vision might see when using magnification at 400%. If you were using 1280 as a user you would essentially have 4 screens of content horizontally compared to 1 at 1280. Within that viewport is content readable without horizontal scrolling. |
|
I agree with JAWS-test. This wording in the Understanding doc could actually be misused, should a designer be perversely minded enough, to ensure that whole sections of text content on a page zoomed to 400% remained the same size text as in the unzoomed view! Clearly not what was intended. So I support the idea of rewording some of the text in these two Understanding paragraphs to make them more specific and less ambiguous. While we can't lay down a requirement in the Understanding, we could add something along the lines of the following to make things clear. It adds no restriction not already in the SCs, but clarifies that, in this "Relation of Reflow to SC1.4.4" section of the Understanding, we are only thinking about text that starts off very large before zooming. So: "However text may sometimes start with a size so big, without zoom, that at 400% zoom just a few words may entirely fill the average PC screen. Some headings are an obvious example of this. If the design counteracts this, in the small screen layouts, by reducing the initial text size of such portions of large font using the media queries, it should still achieve a text size of 200% of its size in the desktop PC layout, without losing content or functionality as required by Success Criterion 1.4.4." The above would replace the last sentence of the first paragraph of the section, ("In an implementation where.....etc"). To fully meet JAWS-test's point and be still clearer, it could perhaps even append the words "...but we would not recommend this kind of size reduction for any text under [30px?] in font size" [we would have to decide the actual figure in that]. |
|
@mraccess77 is there a common real-world setup where a desktop user at 400% zoom and 320px width is going to have a viewport height greater than 256px? You end up with lots and lots of cases like this, where someone zooms to a 320px width, and it is compliant according to your interpretation, but it is still completely unusable (there is an entire clipped form in that vertical scroll region): Or even worse, where the content is completely obscured by the fixed elements. You could have an entire app or website that is compliant according to this interpretation of Reflow, and yet have all its information and functionality completely missing. This isn't even an edge case; most complex apps I've worked with have some variant of this problem, as do many basic websites. Again, if this is allowed, what is the point of investing lots of work to make this the experience at 320px? Who is this helping? @WayneEDick are you ok with the user experience above? Is there something I'm missing here, such as that vertically oriented monitors are common and an easy workaround for this kind of issue? This type of use case comes up far more often than the sort of complex app interface I was talking about before. Many websites and web apps that could otherwise be made accessible at 1280x1024 at 400% zoom will not be, if this is interpreted as passing the criterion. |
This depends on the ratio of screen width and height, but normally not: If you have 320 px at 400% in width, you also have about 256 px in height.
The problem would not arise if in SC 1.4.10 we defined not only a width but also a height. Then it would be a violation of "without loss of information or functionality" |
|
Hi @smhigley We agree that the situation of short scrolling areas is an issue for users -- I run into that almost every day -- but we were not able to get it into WCAG 2.1 -- we had wanted to get it into WCAG 2.2 -- but that hasn't occurred. However, just because that is a gap doesn't mean what SC 1.4.10 requires is not beneficial -- it's just not complete. Yes, perhaps things could have been solved in different ways and a solution worded differently might have more impact -- but it's what we could get consensus on. I argued that the wording left loopholes for people to shrink content -- and that does happen - but overall it has been helpful in my opinion. |
I thought WCAG 2.2 was in the early stages of drafting right now... Is it already decided what new SCs will be? Where can I find them? |
|
Hi @alastc is there a public list of SCs being considered for 2.2? |
|
On the same subject, is there time to propose another SC? I have a very simple one that I'd like to add (by simple I mean very short, not likely to be at all controversial, and with a simple solution for developers to satisfy it). |
|
@mraccess77, @JAWS-test - our wiki has the links, or directly it is this spreadsheet. This covers the ones being drafted, once in the editors draft it is all deal with in github. @guyhickling - Not for 2.2, but please do create an issue and tag it with "wcag.next". That's what happened with icon description. |
|
Regarding how we chose levels in WCAG 2.0. While some of the reasons SCs ended up at various levels is discussed in 2.1, the bottom line reason that something ended up at one level or another was based on where we able to get consensus for it. If most of the group agreed something could go at level A, without blocking objections, that is where it went. |
|
Hi everyone, There was a fair bit of back and forth on this one, but the upshot was there was enough concern with the testing & impact of changing it to 'down to' that it would not have passed a CFC. It was not due to doubts about user-requirement, it was more to do with the burden of testing given that sites which do meet 14.10 generally do work at the inbetween points. By burden, that includes the effects of missing issues at particular pixel-widths that one tester did not find, but which are there. To raise this issue again, it would help to be able to demonstrate that there is language we could use that means it is not a per-pixel-width check. |
and others
Creating this issue based on a thread started by @WayneEDick, who said:
Charles H replied:
Regarding the feasibility, @patrickhlauke said:
@WayneEDick replied:
It seems like a good discussion to have during the normative updates to 2.2.
The text was updated successfully, but these errors were encountered: