The Paciello Group comment on SC 1.4.10 Zoom content #335
Comments
|
lvtf |
|
I agree with Paciello's comment. The problem lies in spurning W3C's own principle of "clear and simple language". This SC existed back in April as "Content can be resized to 400% without loss of content or functionality, and without requiring two-dimensional scrolling except for parts of the content where fixed spatial layout is necessary to use or meaning". The meaning was understandable to everyone (except that bit about two-dimensional scrolling), even if it might have needed a little further technical explanation in the Understanding document to clarify any possible ambiguity. But that's what the Understanding documents are for. Since then it has degenerated into the present meaningless phraseology about "equivalent width" (which noone understands), and doesn't mention 400% text sizing at all! It is not understandable, and now it has been pointed out that it isn't even correct technically. That's what comes of thinking that clear and simple language can somehow be improved by replacing it with incomprehensible jargon! I hesitate to criticise some of the remaining phrasing in it (which I don't think is much clearer), because we desparately need this SC to be accepted into the WCAG for the sake of low vision users everywhere. But we really need the text to be restored to its initial glory before it is released upon an unsuspecting world! We are the ones that are going to have to explain the new WCAG to the IT world next year. How on earth do you explain "can be zoomed to an equivalent width of 320 CSS pixels"? And why should we have to explain something that was perfectly clear originally? |
|
@guyhickling wrote:
Principally because providing a relative measure of zoom was not testable. How do you test (reliably, across platforms and screen sizes) whether a page could be zoomed to 400%? @patrickhlauke wrote:
If content can be zoomed so that it appears as 320px wide without creating scrollbars, and without a loss of content or functionality, surely that means it is readable? (And hasn't lost functionality). I appreciate there might be niche cases where you could create a fixed-width site (at 320px), but actually, that means someone can zoom in on a desktop browser to 400%. Is it a big issue that the 101% to 399% zoom levels have the same layout? It would be odd for a site to do, but not a negative thing from an accessibility (discrimination) point of view.
So we'd have: I like the idea, but it still has the problem of missing a starting point. If you have a 1024px screen (or 1920) you'll get different results. E.g. my 1920px screen can zoom to 400%, and the content can be shown at 320px, but not necessarily at the same time. It can't be tested from the face of the SC. Logically, it needs either:
E.g. "From a starting point of 1280px CSS pixels wide, content can be zoomed up to 400% without loss of content or functionality, and without requiring scrolling on more than one axis, except for parts of the content which require two-dimensional layout for usage or meaning." As a content guideline, defining what the content has to do would seem to be more appropriate. (And avoids looking even more technology-specific, although I'd admit that mainly just perception.) I'm open to changes, but the terms have to be testable. |
then lose the "can be zoomed" and just require that content fit in 320px wide viewports, and in the understanding explain that this value was chosen because on an average desktop screen, this means that it can be zoomed up to 400% ? |
|
Certainly the testability has to be worked out, and the Understanding document will have to set out how to do that. If a starting point must be specified then so be it. My concern is that if the actual SC is incomprehensible we'll never get to the testing of it.....because the development world will simply ignore it as a mystifying piece of jargon they don't understand. The principle behind 400% zoom will become one of those "good practice" rules that it's good to follow when designers don't want to do something else that breaks it entirely, but they won't think of it as something that has WCAG backing behind it because they won't realise it is there. And we will spend the rest of our days trying to explain, to every new audit client we deal with, what the SC means. Far better to have an SC that everyone basically understands, then explain the detail inside the Understanding. So I think the wording you have just suggested may be the way to go:
I also feel that if the W3C as an organisation genuinely wants to promote its principle of "clear and simple language" (and it seems important to me that it continues to do this), and if it wants to tell others to use it, then it needs to be seen to be following the same principle in its own backyard! |
Um, the original TPG comment was to include "zoom"! I'd also argue that saying 'can be zoomed' means you should use that mechanism to test it, which means you do test from 100-400, rather than just at 400 (/320px). Also, we don't want someone to just open it on a phone and think 'yep', done that. Because the effects can be different compared to zooming in on a desktop. (E.g. sticky headers.)
The understand doc will detail the process, but the SC text has to be 'testable', which means that regardless of the separate doc the content must pass/fail that statement. I appreciate that it is difficult to understand to start with, but we need something that means the same thing, i.e.
The above is easier language, but longer and less precise. We went through a lot of revisions in #77 to get here. If you can think of a way of saying that better, please let me know... Cheers, -Alastair |
the normative text doesn't say anything about desktop browser though. the understanding document can clarify that testing should be carried out on desktop browsers as well as mobile browsers. the difference in behavior here is a difference in how the UA handles certain CSS. |
|
No, but in order to zoom, you'll need to use a user-agent capable of zooming (in a way that affects the pixels / layout). That is implied in the SC text, and outlined in the testing procedure of the understand (or at least the draft in #77 so far). |
|
So using the wording you have used just above (slightly rearranged to fit in with the formal nature required here), and most of your earlier suggestion higher up for the first part of it, the SC would become:
Now that really is clear, and to the point. It's testable and, equally important, everyone would understand an SC worded like that. And if brevity is important it's only one word more than the version in the draft - and does away with the first Note completely. I appreciate the time it took in #77 to reach the current draft form (I read it all through when I first saw it), but I think it is still worth trying to achieve a clearer and more understandable version than the current draft, to make things easier for everyone in the future. |
|
I'll put that to the group, but issues I'd anticipate are:
The latter two are the more difficult ones. |
|
I've been trying to address the issues I raised above, but I keep ending up with the same wording as before. Even with a minimal change to the start like this:
I think that leads to issues in testing horizontal scrolling sites as there is no starting height. It was a bit of a fudge before (320px height is a smaller zoom factor for most desktop browsers), but it worked. Does anyone have ideas about how to make this work for horizontally scrolling sites? |
|
Well, I'm beginning to wonder if this is even a problem! I was talking to a Chinese friend last week, and he said Chinese websites were written horizontally. So I started taking a look at Chinese, Japanese, and Korean websites (all allegedly vertically written languages), and in the first 5 or 6 sites I looked at in each of those languages, all without exception were written horizontally across the page, and had to be scrolled vertically, in just the same way we scroll in English sites, to see more content on the longer pages. Text was written horizontally, and if the page wasn't reponsive designed a horizontal scroll bar appeared when I made the window smaller, just as on an English website. In short, I found no websites that scrolled horizontally when pages or content were over-long, they all scrolled vertically, as we do in our language. I took a look at Omniglot (http://www.omniglot.com/writing/direction.htm). It lists about 150 horizontal languages and only 20 vertical ones, including Chinese, Japanaese and Korean, and some little known languages the three of which I tried I couldn't find websites in. It then says "Until the 1980s Korean was usually written from right to left in vertical columns. Since then writing from left to right in horizontal lines has become popular, and today the majority of texts are written horizontally. Chinese is often written vertically in Taiwan [not in the Taiwanese websites I looked at it wasn't!-gh], while in China and Singapore it is usually written horizontally. Vertical and horizontal texts are both used in Japan." For Japanese, another source says, "Traditionally, Japanese was only written vertically, and most historical documents are written in this style. However, with the introduction of western materials, the alphabet, Arabic number and mathematical formulas, it became less convenient to write things vertically. Science-related texts, which include many foreign words, gradually had to be changed to horizontal text. Today most school textbooks, except those about Japanese or classical literature, are written horizontally. Young people mostly write this way, though some older people still prefer to write vertically as it looks more formal." When you think about it, it's not really surprising that these formerly vertical languages follow the same methods as we do on websites. The web is written in HTML, and that is designed to create text horizontally and then wrap down and to the left at the end of lines. Other language sites are still written using HTML, mostly by computer people who speak English whatever their first language might be, for the same browsers that we all use which are also designed for horizontal content direction, and that's just the way it is. It looks like previously vertically written languages have just fitted themselves into that framework, and in fact were already doing so for business reasons before the web was born! However if anyone knows of a language where websites normally do it differently I would be interested to hear of any examples. So maybe a Note, or just a paragraph in the Understanding document, would be enough to cover this whole matter, rather than make the SC itself overly complex and hard to understand for no need (- it has taken us long enough to understand it, we shouldn't put the same load on everyone else if it isn't really necessary). I'm not saying vertically written websites don't exist; I am just saying the numbers may be so vanishingly small that we can keep the text Success Criterion itself simple, always a good thing, and cater for the other possibility elsewhere. It looks like we may be worrying about something that just doesn't happen in normal life! |
|
It is worth reading the previous conversation in the issue. The bottom line there is that although non-horizontal text is fairly rare now, support is improving so it could become more common. There is a good primer for Chinese language and writing mode. Even in western sites, it is possible to have text going in different directions. I think that if we don’t account for it, the SC will be rejected when it comes to wider comments. |
|
I have had a think about the wording issue you raise over the two dimensional scrolling matter. Instead of the "without requiring scrolling in more than one dimension", perhaps "without requiring both vertical and horizontal scroll bars simultaneously"? would be a bit clearer? But that has the same loophole as most of the "two dimensional" attempts tried so far. To illustrate, take a page with just a few lines of text, say 7 lines for argument's sake, each stretching across most of the width of a normal width PC screen. And we will assume that, due to the bad coding used, these lines won't wrap responsively so a horizontal scroll bar appears when they are zoomed. Now Increase to 400% zoom. The lines will now be four times the height, but seven lines won't cause a vertical scroll bar (in practice the average PC screen will hold a browser with around 30 lines or more of text at normal text size without needing to scroll down, so a quarter of that at 400% zoom. So we only have scrolling in one dimension, horizontally. Such a page won't meet the case of two dimensional scrolling so won't fail the SC as currently written - but it has failed the aim we are trying to achieve with this SC because horizontal scrolling back and forth is needed to read each of the long lines of text. This leads me to think that the wording mentioned in the June conversations about this, "without requiring scrolling in the direction of the text" is the only kind of wording that actually fits what is wanted from this SC. It has the failings that were mentioned then, but it covers both cases of horizontally and vertically written languages better and without the above loophole. So expanding on that to meet the failings it had, how about "in the direction of reading the words of text". That also brings in the idea of not wanting people to have to scroll along as they read. So the SC now becomes (using the text you had above, three posts ago on 26 Sept):
That works whether there are one or two scroll bars, and is hopefully a bit clearer as well. |
|
I think (re)introducing "scrolling in the direction of reading" makes this SC immediately clearer to the reader as it captures the LV problem of (usually horizontal) scrolling. |
|
Knowbility has a good resource for evaluating this wording and this
wording. His name is Anthony Vaquez, he has a Masters in Eastern Studies
from Standard and is fluent in Chinese as a second language. Anthony is
also blind and did all his learning of Chinese using a screen reader and
refreshable braille. He works for Knowbility. His email is avasquez@
knowbility.org.
Wayne
…On Tue, Sep 26, 2017 at 7:29 AM, Alastair Campbell ***@***.*** > wrote:
I've been trying to address the issues I raised above, but I keep ending
up with the same wording as before.
Even with a minimal change to the start like this:
From a starting width of 1280px CSS pixels content can be zoomed up to
400% without loss of content or functionality, and without requiring
scrolling in more than one dimension, except for parts of the content which
require two-dimensional layout for usage or meaning.
I think that leads to issues in testing horizontal scrolling sites as
there is no starting height. It was a bit of a fudge before (320px height
is a smaller zoom factor for most desktop browsers), but it worked.
Does anyone have ideas about how to make this work for horizontally
scrolling sites?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#335 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0OF4nzARP6iuMphq6XCDyr0s9LcvwYks5smQowgaJpZM4PB1Pn>
.
|
But what happens when you have text going in more than one direction? As soon as a western site uses vertical text (e.g. at the side as a style) a regular page fails. |
|
We can go in one of three ways:
and just add a Note to explain the vagueness of the "scrolling in more than one dimension" phrase, and to explain the loophole I raised above.
|
|
I am really thinking that this is less of a problem than it appears to be.
It cannot be dismissed because people have web pages discussing classical
literature in western languages. We could expect these examples exist in
CJK formats. The literary samples would be in vertical text orientation.
That is just one example. There are probably hundreds.
I think Alastair's original language will suffice for three reasons:
1. It is testable.
2. It is sufficient to describe both formats.
3. Formats are, by necessity, simplified to fit in 320 pixels.
The last is important because text that goes in two directions is less
likely in small space formats. A developer will not want to waste 20 to 40
pixels in a 320 pixel format for a banner of vertical text. Developers will
get very economical in small confines to preserve functionality.
Lastly, text should wrap, even if it is oriented vertically or
horizontally, even if the page mixes the formats. Alastair's wording
convers that.
The wording is a little dense, but spreading it out would probably add more
confusion.
This will require a good understanding section with examples.
Wayne
…On Sun, Oct 1, 2017 at 6:50 PM, Guy Hickling ***@***.***> wrote:
We can go in one of three ways:
1. The SC can stay with the wording we have now arrived at above:-
From a starting width of 1280 CSS pixels content can be zoomed up to 400%
without loss of content or functionality, and without requiring scrolling
in more than one dimension, except for parts of the content which require
two-dimensional layout for usage or meaning.
and just add a Note to explain the vagueness of the "scrolling in more
than one dimension" phrase, and to explain the loophole I raised above.
1.
It would be possible to have two, almost identical sections in the SC
(some of the SCs in WCAG 2.0 have several sections) , one for "horizontally
written languages" and the other for "vertically written languages". They
would differ only in the two dimensional scrolling phrase. One would say
"without requiring horizontal scrolling when the text is written
horizontally" and the other would have the equivalent for vertical
languages.
2.
We can continue to look for a different way of phrasing it. That is
possible, I think, and tomorrow I'll put my thoughts on that if you like.
But it will involve more words in the SC to explain it clearly. The
problems of lack of clarity and/or loopholes arise when we try to explain,
what is quite a complicated thing to describe, in just two or three words.
As soon as we use too few words, people start asking what it means, or it
contains discrepancies and loopholes!
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#335 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0OF266Oop7T2Z3cFl7yYumbiUlhtZEks5soEF-gaJpZM4PB1Pn>
.
|
|
So the downsides of the two approaches are:
The first is possible in some scenarios but unlikely - it would also be a rubbish experience on mobile devices as well, you'd have to go out of your way to have a website that mostly passes but then fails this in one place. The second would fail some fairly popular websites aimed large swathes of the non-western world without intending to. I think Wayne has a good point that (in western contexts at least) developers would probably drop vertical-text from the zoomed/small-device view as it doesn't work. However, that still leaves vertical text which is intended to scroll vertically, and mixed direction text for languages like Chinese. If you can think of a way of closing the first without impacting the second, please do chip in! |
|
@WayneEDick wrote:
"Could expect...would be... probably hundreds". But are there? In all these discussions I don't think anyone has actually shown a real life example. I'm certainly not saying there aren't, but it would be nice to have some live examples of actual websites written vertically. To start the ball rolling on that here are three sites I picked at random, one listing lots of Chinese sites, one with Japanese sites, and the same for some Taiwanese websites. They list some "top rated sites". I don't know what the listed sites are all about as I don't know any of those languages (so I hope there is nothing objectionable there!) but we can all browse them. The ones I looked at, again picking random ones, are are all written with horizontal text: http://www.chinesetop100.com/ (you have to cut and paste from the Alexa ones or you just get the alexa page).
It seems as though this is only thinking about mobile format. But this SC is primarily about websites on desktop PCs - designers aren't going to stop writing for the desktop, and they don't fit into 320 pixels! It is about very long lines of text on a desktop screen, and making sure they don't become wider than the screen requiring scroll bars. |
|
@alastc said:
It is the back-and-forth type of scrolling for every line of text (or column of vertical text) that makes reading tedious and frustrating after zooming. So the SC wording should say that. Therefore I suggest, instead of "two dimensional scrolling" or "scrolling in more than one dimension" with all their associated questions and need for clarification:
Yes, it takes a few more more words to say it (33 actually, but there are much longer SCs than this one). But something like that will be accurate, clear and understandable, doesn't leave the loophole mentioned earlier, and it says precisely what we mean which is always a good thing! No further Note or explanation needed (hopefully). We can adjust that wording slightly if anyone spot's a real issue in it, but basically we need something like that. There's nothing to beat saying exactly what we mean! |
It is hard for me to point to examples, I can look at the sites and not know! However, there is a W3C requirements doc with some good info:
Languages (or rather: text in various languages) is not just horizontal or vertical. Consider the possibilities, text can be vertical with 'horizontal' characters, or vertical with vertical characters.
I think you're missing a key bit: When you zoom you get the mobile view. The point is that it is requiring either responsive site, or a version which can be zoomed to 400% (e.g. a small fixed-width version). I think Wayne's point was that when reflowed, devs have the option to simplify certain aspects. |
|
@alastc wrote:
Actually which way the letters or characters within the text are oriented doesn't matter for this SC. They can be upside down for all that matters! The only thing that matters is long strings of text (lines horizontally, or columns of characters vertically), and whether they wrap or not on zooming. If they wrap, fine. If they are fixed so that on zooming they go beyond the edge of the screen and cause a scroll bar, then they fail the SC. But within those pieces of text it makes no difference, to the triggering of scrolling, which way the individual characters are displayed. Sorry, I should have thought of that in the discussions earlier in the summer. It means, however, that we come down to only two variations that the SC need be concerned about - long lines of horizontal text causing a scroll bar on zoom, and long vertical columns of characters causing a vertical scroll bar on zoom. It seems to me those two variations can be described easily enough, either with the wording I suggested in my last post above or something very similar. |
|
I think there comes a point where we have to stop thinking of every possibility, because the number of possibilities is endless. If there are particular designs, such as the three column one, that need a little explanation as to how they fit in, then maybe they should be discussed in the Understanding document. What we have now is a wording that is in plain language, with a meaning that is clear, and is still as general purpose as we can make it. If everyone can understand it then the majority of people will do their best to follow it. Whereas, with the wording currently in this SC's draft, people will spend most of their time arguing about what it means, or trying to explain it to others, and many will simply dismiss it as just another piece of meaningless double-talk that they will not bother to try to understand. I would like to say that, even as a web developer myself, I have the greatest difficulty in understanding how to get from "can be zoomed to an equivalent width of 320 CSS pixels" to a low vision user zooming to 400% on their desktop PC screen. And yes, I have read the explanations. Those of you who were in on that discussion right from the start no doubt understand how the connection works, but I don't think many people coming to it from outside that conversation will do so. I'm also conscious that deadlines are looming close. The December limit is only a month away, and I understand that even after the November draft comes out it will be difficult to make further changes. So I would urge you to accept the wording we have reached here, and put it forward to whoever has to decide between the two. I do not think they should be left with only one choice. They should be given this second version, and be allowed to make a decision based on the merits of the two alternatives. |
|
Hi @guyhickling, This issue was the main topic of the working group this morning, both versions were presented (see the wiki page) a few key points from the discussion:
Change of SC text proposed by the WG at TPAC:
|
|
Thank you for the links. Thank you also for placing our alternative wording before the Working Group. That is much appreciated. I think my first question would be, what do they mean by "Need to combine the current text-size (1.4.4) with this one". Does that mean they will change to 200% figure in SC1.4.4 to 400%? I thought they were aiming not to change any of the 2.0 criteria? Or does it mean that the current 1.4.4, as it stands now at 200%, will now be the only requirement for text sizing? Lower down in the wiki they say "Therefore the formulation of text requiring 400% increase in content does not work", so it seems to me that they are throwing out the whole idea of 400% zoom. Is that correct? |
|
Sorry, that was confusing, I didn't mean to combine the two SC, but to use them in combination. What has now been proposed is that this SC focuses on reflow, and we rely on the current text-resize SC to ensure that text does actually increase in size. The nuance is that it does require the equivalent of 400% zoom by making sure you have to display at 320px wide/high without 2D scrolling. We had comments about the level of testing needed if you have to test every size between 100% & 400%, so took out the zoom aspect. We rely on the 1.4.4 SC to ensure that text does actually increase, so (for example) sizing text with VW units would fail. Not all text would increase 400%, but a lot would, and certainly more than 200% (with no horizontal scrolling). Another factor was that pages with text in both directions are becoming more common because browsers have better support for vertical text now. Also, the low-vision folks would rather avoid horizontal scrolling, even for layout, not just blocks of text. I hope that makes sense? |
|
@alastc, just repeating my survey comments here for posterity. We briefly touched on this in the midst of whirling through LVTF issues, but I don't think we came to a conclusion. In concept, I understand the difficulty in trying to cover zoom and reflow in one SC, so I'm fine with separating the two. However, this proposed language does not require reflow at all, but rather a single working presentation at 320 pixels. A single media query for 320px and a fixed layout at larger sizes would pass, but gives little to no benefit to low vision users. Reflow is a dynamic and continuous response, and the SC needs to be clear that is the content requirement because that is the user accessibility requirement. I would suggest the following wording to resolve this: Reflow: Content can be presented at widths equivalent to 320 CSS pixels and greater without loss of information or functionality, and without requiring scrolling in two dimensions, except for parts of the content which require two-dimensional layout for usage or meaning. |
|
@steverep I agree, that's what I said at the TPAC face-to-face on Wednesday morning -- that reflow and zoom needed to be supported at all levels not just the minimum and maximum. For example, many people use 150% zoom today but some in the group interpret that it only needs to work at 200% and not anything in between. SC 1.4.4 says up to 200 percent -- in my opinion the key term is "up to". I would like to hear from Greg V. and others who were involved with WCAG 2.0 on how they intended up to 200% to be understood. |
|
+1 to Steve's proposed edit.
JF
…On Mon, Nov 13, 2017 at 7:44 PM, Jonathan Avila ***@***.***> wrote:
@steverep <https://github.com/steverep> I agree, that's what I said at
the TPAC face-to-face on Wednesday morning -- that reflow and zoom needed
to be supported at all levels not just the minimum and maximum. For
example, many people use 150% zoom today but some in the group interpret
that it only needs to work at 200% and not anything in between. SC 1.4.4
says up to 200 percent -- in my opinion the key term is "up to". I would
like to hear from Greg V. and others who were involved with WCAG 2.0 on how
they intended up to 200% to be understood.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#335 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/ABK-c2FKrAyu4pdz8gxjXn8Xig9zmHXCks5s2P6igaJpZM4PB1Pn>
.
--
John Foliot
Principal Accessibility Strategist
Deque Systems Inc.
[email protected]
Advancing the mission of digital accessibility and inclusion
|
|
I’d like to take that approach, but there are two things that make me wary:
Update: Also, it occurs to me that actually the fixed 320px version still passes that wording, as it does work up to that point, it just doesn’t fill the screen. I’m not sure that adds value!
The lesser point is the testing overhead, you’d have to establish all the breakpoints and check info & functionality is available at all levels. Generally if things are available at the smallest they should be available in all, but it leaves that door open. I guess the question is: if we get objections the other way, will it end in deadlock and no SC? I’m happy to try, but I don’t want to loose the good for the perfect. |
My response would simply be that their "mobile version" does not meet the accessibility needs for low vision, so why are we crafting something to give a pass? We've been clear in the working group and to comments that 2.1 is not for legacy content looking for a quick fix.
But it's not associated with zoom at all. It simply says to fit content within >= 320px. It can be worded other ways of course, but it's very clear.
I don't want to nitpick about analogies, but being clear that info and functionality needs to be available over the full responsive range is a fully closed door. I can appreciate concerns over testing magnitude, but specifying the endpoint only is hardly a compromise considering it eliminates the vast majority of the user benefit. If I start at 1280px, there are 961 viewport widths to test down to 320. A good compromise between 1 and 961 is not 1. |
I don't think that is so clear. If I were a user with low vision, I think I would prefer a 320px wide version that I can zoom in on significantly (and much more significantly than the 200% text-size that hardly anyone met), than the desktop-width version. (Remember one of the potential SCs was for linearisation.) Is it ideal? No, however, those who can do it responsively will probably meet it from a zoom point of view anyway. Those who can't are simply stuck. My last point still stands:
|
Well, as someone with low vision I can tell you I would not prefer that at all. If I start at 320px and can only go up from there, that means the only way to utilize the full width of my screen is with a level of magnification that I probably don't want or need. So I should take away all the usability benefit of the desktop version for what? Not to mention this scenario depends critically on:
Neither of these is a certainty and just put even more burden on the person with a disability. |
|
I guess it depends on the level of vision, if someone wants 400% (or more) you might not even notice there is a 'desktop' version. Still, it comes down to what we can get through, and there were significant objections to the zoom-at-every-stage approach. |
|
@alastc I wonder how the low vision user might get to the 320 breakpoint on their desktop. Option 1) shrink the window to 320 and then zoom in. I don't think this is helpful to shrink the window. Option 2) Use zoom which reduces the width down to 320 but also increases the scale factor. This is the most likely method. At our target resolution I have to Zoom in to 400% to get a width of 320 with a scale factor of 4. But only 200% zoom is require yet I don't know how to get my browser at 320 on the desktop with only a scale of 2 without reducing the window width -- which I don't want to do. |
|
@mraccess77, thank you for adding that additional complication. I was fixated on the total lack of actual reflow support when I took the survey last night that I failed to notice the user now doesn't even have a guaranteed path to get to this "zoom" anymore. |
|
I think you’re missing the point. If a site has to provide this view, they have to provide the 320px breakpoint. In that case you’ve done 90% of the CSS work to provide a fully responsive site. The effort to add the in between points is negligible and gets you a better UX on millions of devices. We’ve had comments (see the thread in Gregg’s comment) that we’re requiring responsive design (which is mostly true in practice) and that is too much to ask. The only relevant get-out method is to provide a completely separate mobile site, but even that is unlikely because every example of that I’ve seen does not provide the full content and features. So either we have this ‘line in the sand’ that is relatively easy to understand and test, or we get nothing. |
|
Also, we've pointed to loads of conforming responsive sites in these threads, can anyone point to an example of a conforming 320px only site? |
@mraccess77, this is exactly what some LV users I know do. It means that when their AT magnifier is enabled, the browser window width fits the width of their display; as long as there is no horizontal scrolling in the browser, they can now view the entire width on their screen, magnified. I understand our goal is to have this achievable with just the browser function's Resize text, but wanted to point out that Reflow alone will help some who use ZoomText and other software magnifiers. |
|
@mbgower, yes that would be a way to achieve the zoom, but it's far from ideal. It involves being very careful not to pan the screen horizontally, and you either have to do the same vertically or manage both pan and scroll. Plus you have to re-position after any window change outside the browser or change of zoom factor. Doesn't the fact that these low vision users have to do this make the case that simply testing reflow is not enough, or am I missing something? That is, why can't they achieve the same result with browser zoom and no AT zoom? |
|
@mraccess77 wrote:
I'm confused by the examples, the assumption is that the person is zooming in, so how they get to 320px (if they need to go that far) is up to them in terms of starting point and zoom level. Your window with is one variable (and we're assuming a starting point of 1280px), the 320px is the far-end of the zoom/reflow scale. As I said above, providing that end-point means the vast majority of sites will use a responsive method, so you would be free to zoom in to your desired level. For a hypothetical site which creates one large breakpoint (e.g. 1280px) and one at 320px, you would have to zoom into a point where you hit 320px. That could be at 400%, or 200% and a windows width <640px. I've yet to find one of these:
|
|
@alastc Can we talk about the actual test steps? I had assumed the test steps will be to resize the window to 320px perform checks for this SC and then zoom in to 200%.and then perform checks for SC 1.4.4. Zooming at 200% from 320px will essential put the width down to 160px at a scale of 2. So would the test then actuall be resize the window to 640px and then zoom in to 200%? Then we get a scale of 2 and a width of 320px. |
|
Hi @mraccess77, For this SC, the steps are either:
In a desktop browser the effects should be the same. However, note that Firefox doesn't support 400%, so you'd need to use the 960px wide at 300% or lower. 1.4.4 resize text does not specify any starting point so my suggestion is to have two types of test depending on whether zoom worked. Either:
I.e. it is possible to fail zoom and pass text sizing. It is possible (but harder) to fail text sizing and pass zoom. Currently no site can fail 1.4.4 as zooming works with scrolling, so this should help a lot. |
|
@alastc say I start from 1280px as you suggested and zoom in to 400%. You then say "check that the text is twice the size". It may be -- but since I'm at 400% here I can't really know what it would be at 200%. You say "Currently no site can fail 1.4.4 as zooming works with scrolling," I see sits fail 1.4.4 because of many things that we have already discussed such as overflow hidden, content over top of other content, etc. |
This is straightforward: For any text that doesn't appear to be increasing at the same rate, check the computed text size. If the computed size at 100% zoom is 20px, it must be at least 10px at 400% (thus being 40px effective size compared to 100% zoom).
Then I assume you're testing with text-sizing not zoom? Given that the SC text can be met with zoom "text can be resized without assistive technology up to 200 percent without loss of content or functionality", it is pretty rare for sites to fail that. |
|
@alastc wrote If the computed size at 100% zoom is 20px, it must be at least 10px at 400% (thus being 40px effective size compared to 100% zoom). Right -- that's checking for 400% increase at 320. We aren't required to check for that -- only 200% increase of text size. So testing text size at 400% doesn't have much of a value -- we need to test at 200%. @alastc wrote Then I assume you're testing with text-sizing not zoom? Certainly not. I just zoom in with my browser control+mouse wheel in Chrome and I have all sorts of situations where text gets smaller, scrollbars are hidden and text is cut off, content overlaps text, etc. We've documented issues with google books, Google's AMP, snap to scrolling, video conferencing software, etc. |
|
Well, we need to test that it can be displayed at 200% larger. So yes, you can test at 200% zoom, but actually it could pass (be 200% bigger) at any point on the continuum. Personally, I would test at 400%, if it doesn't pass then, reduce zoom and see if it gets (relatively) bigger at any point. |
|
Thank you for your comment. The working Group discussed your concerns and while it is not able to fully address your points, they were helpful in moving the discussion forward. While the goal is to allow users to increase the size of content and have it fit within the viewport, there are some significant complications in testing and feasibility when trying to enable that across all screens. For example, sites often reduce the text size for smaller screens (e.g. BBC homepage, Apple homepage) for legitimate usability reasons. Therefore the formulation of text requiring 400% increase in content does not work. What has now been proposed is that this SC focuses on reflow, and we rely on the current text-resize SC to ensure that text does actually increase in size. The new wording is: Reflow: Content can be presented at a width equivalent to 320 CSS pixels without loss of information or functionality, and without requiring scrolling in two dimensions, except for parts of the content which require two-dimensional layout for usage or meaning. We recognize that some concepts are not simple to understand (equivalent width, and two dimensions), but this phrasing is being used to be precise in the SC text. So, we will explain this clearly in the Understanding document." |
It seems the normative part of the SC is missing the actual core idea here of allowing users to zoom content sufficiently. While the 320 CSS px size is good and testable, this SC could be nominally passed if the content was zoomed to 101% (as long as content fits in 320 CSS px). The current normative wording only guarantees that content doesn't start creating horizontal scrollbars in viewports that are 320 CSS px wide, not whether or not that content is readable or if the user was in fact able to zoom at all up to that point. Suggest that the idea of allowing up to 400% zoom, coupled with minimum viewport width, would better serve the original idea/outcome. "Content can be zoomed up to 400% and it will still fit into a viewport of 320 CSS pixels width without..."
The text was updated successfully, but these errors were encountered: