Zoom Content (formerly Resize content) #77
Comments
|
What about a responsive site? ... how would a user zoom in with touch. Generally they would pinch but that causes scrolling Horizontally. Also, I noticed it makes no mention that this should be achievable without Assistive technology... should it say something like "without assistive technology up to 400 percent without loss of content or functionality. " |
|
A responsive site is fine, in fact, that's why we can go more than 200%. For mobiles, that is what the second exception is for: "If the user-agent fits the layout to the viewport and does not provide a means of reflowing content, two dimensional scrolling is exempt." Most (all?) mobiles use a different model from desktop, where the layout is set as the page is loaded. There is no method of (pinch) zoom which doesn't cause horizontal scrolling. Some have text-sizing in the OS settings, but few apply that to websites. It doesn't mention "without assistive technology", personally I don't think it needs to, keyboard, bypass blocks and visible focus don't mention that either but you could argue they should. I wouldn't be against adding it, but I don't think it needs to. |
|
David commented on-list that he didn't get that the second exception essentially meant small screen/mobile devices. Do people think we could cut the layout (technology specific) aspect and just say: I'd like to keep it general rather than put 'mobile' in the SC text, we can explain that in the understanding doc. |
|
If it is possible to replace the current 1.4.4, I would adjust the second exception:
I'm not entirely happy with that wording, but also trying to avoid having lots of caveats! |
Ideally we'd stay away from User agent exemptions... but I don't know how else to fix it, unless we say something like "small screens" and then define that... I'm actually attracted to that term (or something like it) for a number of mobile things also. |
|
The problem is that the 'switch' between layout methods is not at a particular screen size.
I would guess there are weird & wonderful windows/android tablets that could use either method at any particular size. We really have two layout styles that have different potential for expansion, need different techniques, and different SCs. I thought the simplest way to deal with it would be adding one for desktop-layouts, but if we replace the current 1.4.4 we could add another, more specific one. Then (if this one replaces 1.4.4), add a separate one along the lines of:
So, for desktop layouts this is already covered to a greater degree. For mobile-style layouts you need to allow for increased text-sizing. I.e. don't set heights on things elements with text, allow for wrapping etc. All the stuff we've had to do for the years before RWD. So with Resize content, resize text, and reflow, you have three levels:
That should still maintain compatibility with WCAG 2.0, it only increase the requirement. |
|
i don't think we want two sizing scs |
|
Well, there are two layout methods with very different attributes, so you either have two or ignore mobile. |
|
We can't change 1.4.4 for backwards compatability, so any solution
suggestions are going to need to be new SC.
Katie Haritos-Shea
703-371-5545
…On Dec 17, 2016 6:03 PM, "Alastair Campbell" ***@***.***> wrote:
Well, there are two layout methods with very different attributes, so you
either have two or ignore mobile.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#77 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AFfqyiz9Un-F7NPCUf9hlP8j1vzn3UmDks5rJHhLgaJpZM4LB3oC>
.
|
|
Hi @Ryladog, I had assumed that to, but David pointed out that the previous decision/consensus was to write them as though they were additions-only, but once we've got them all together we could decide if it made sense to edit current ones. I don't think anyone wants three separate resize criteria, so we can either we add this one, or use this to replace the current one and add another one. There are plusses and minuses to both approaches, but they could both be backwards compatible as there is no reduction in coverage. |
|
On Thu, 2016-12-01 at 12:44 -0800, allanj-uaag wrote:
<h2>SC Shortname</h2>
<p>Resize content </p>
<p> (Was: "Size (all content)", but trying to align and extend 1.4.4
Resize text.) </p>
<h2>SC Text</h2>
<p>The content of the Web page can be increased to 400% without loss
of content or functionality, without two dimensional scrolling, with
following the exceptions: </p>
Why are you hard-wiring 400% here? Is a user agent that allows resizing
to 800% non-compliant? What about 200%, is that OK? (trying to
understand the rationale here)
Suggest,
The content of the Web page can be increased at ratios of up to at
least 400% without...
<ol>
<li>If the spatial layout of some the content is essential to that
contents use, that part of the content is exempt.</li>
So "islands of inaccessibility" are allowed? That seems sucky.
At any rate should be "that content's use" :-)
<li> If the user-agent fits the layout to the viewport and does not
provide a means of reflowing content, two dimensional scrolling is
exempt. </li>
How can it zoom and still fit content to the viewport without
reflowing?
[...]
If the user needs to increase content more than 400%, then <a
href="https://www.w3.org/WAI/GL/low-vision-a11y-
tf/wiki/Reflow_to_Single_Column">; reflow</a> would be necessary.
</p>
This still seems weird to me. A reflow might be necessary at a 10%
increase (110%) and in another circumstance not needed at 500%.
|
We aren't testing the user-agent, it is the content that has to pass. However, we should probably align with the current 1.4.4 and say "up to". The rational is that with modern methods not available at the time of WCAG 2.0, it is much easier to allow for increasing size of text & content. If a site has a layout that works in a 1200px wide desktop browser, zooming in 400% means you have a 300px wide layout area. That aligns nicely with mobile styles applied with media queries.
Some content cannot be reflowed (e.g. maps, diagrams, some data tables), so either it horizontally scrolls, or it doesn't work at all. There is still the current 1.4.4 about resizing text up to 200% though, which should apply to that content.
Pinch-zoom on mobiles, expands the layout out of the viewport. I.e. induces horizontal scrolling. See above for the discussion on mobile device layouts.
Sorry, that is confusing. It is just using the term 'reflow' as a pointer to the Reflow SC, which is about completely removing the layout styles to have 1 column. You are right, reflow can happen well before that using media queries & similar techniques. So, the up to date SC text would be:
|
|
On Mon, 2016-12-19 at 05:41 -0800, Alastair Campbell wrote:
>
[...]
So, the up to date SC text would be:
>
> The content of the Web page can be increased up to 400% without
> loss of content or functionality, without two dimensional
> scrolling, with following the exceptions:
> 1. If the spatial layout of some the content is essential to that
> content's use, that part of the content is exempt.
> 2. If the user-agent does not provide a means of reflowing content,
> two dimensional scrolling is exempt.
Looks clearer now. Maybe "up to at least 400%" would be even better but
I'm OK either way. Thanks.
|
|
There has to be some minimum width specified under which the content is not expected to reflow. As it stands if I were to size my browser to the minimum width allowed (in chrome this went down to 256px in my instance, FF to 302px and IE to 217px ) and then zoom to 400% I have less that 100px width for my content (and only 57px in IE). This is not practical for any layout and needs to be rethought. |
|
That applies to the current 1.4.4 as well, it's almost as easy to destroy a layout at 200% (or even 150%) if you do that. Whilst it might sound reasonable to adjust a desktop browser to a mobile size, is there evidence that anyone does this? They have different layout mechanisms (and we're excepting mobile as a separate issue), so why try to support an odd behaviour of re-sizing your browser to a tiny size on a desktop OS? Everyone I've seen with low vision has kept the browser window as large as possible, and either used browser zoom and/or magnifier and/or reduced the resolution of the whole (>20") screen to 1024 wide. I'd be happy to specify a minimum window size to start testing from in the understanding document (1024 seems like a reasonable starting point), but that seems like a technology-specific detail that we wouldn't have in the SC text. |
|
There are a few things I would like to get clarified on this. For instance, I tend to think of Zoom (NOT text-only zoom) as a pure, indiscriminate magnification of the entire content. On this github page, for instance, if I Zoom on Firefox, a horizontal scrollbar appears after 3 increases. At 400%, I get scrollbars on google, deque, facebook, etc. It's a non-trivial issue. I'm aware that a site doing mature responsive design, like WAI can handle all 8 of Firefox's incremental increases without displaying scrollbars. But even then, there are issues:
I find the sentence on reflow confusing, since depending on what people think of as a definition of reflow, it is impossible to get to 400% without doing so.
|
|
I'm not sure I get the same thing for some of your examples? Github & Facebook don't use a responsive (enough) design, but Deque I can easily get to 500% with no horizontal scrolling. On sites which started responsive 500% is feasible on Gov.uk, and BBC.co.uk works without scrolling at 400% starting with an 1100px wide browser. Are you sure you don't have the 'text-only' zoom applying in Firefox, or another accessibility plugin that is also increase text size as well as zoom? Noting the exception for 'mobile' devices (which don't reflow when zooming), starting at the most common width of 1366px (or even 1280px), zooming 400% leaves you with at least 320px width, which happens to be the standard (smallest) mobile device setting people generally work to. (It was the original iPhone width.) Regarding Firefox not going past 300%, does that matter? From discussions on other SCs it seems that some UAs need to support an SC, but not all. The content should work for the SC, and if someone needs to go to 400% (or test it) they need to use Chrome or IE/Edge. Personally I could live with 300% and no horizontal scrolling, but some people on LVTF would be disappointed because there is a real user-need that isn't met by other means.
Yes, sorry, I meant "reflow" as in the SC, not just a plain reflow, that's poor wording. Perhaps that would be better as: If the user needs to increase content more than 400%, then a more drastic method is needed such as over-riding layout styles. The SC on Reflow tackles that issue. |
|
@alastc , that is strange regarding the differences with deque.com. Nope, I'm not using text-only zoom, and I'm resetting before testing. I actually see horizontal scrollbars with the first 4 increases, then on the fifth increment -- I assume when the zoom hits a breakpoint -- the scrollbar goes away, and then with the next zoom and all subsequent, it comes back again. Not trying to pick on that site, grin; all the content seems to be in the viewport. But the scrollbars are definitely there. So if the presence of the scrollbars is the failure, it fails from my testing.
That would need to be made clearer, because it currently reads like the author is responsible for guaranteeing 400%. So the requirement is really to author content that can zoom without requiring horizontal scrolling. Perhaps a third exception stating that where the user-agent does not support zoom up to 400%, the content can be magnified to the maximum set by the user agent? Making such a change will help clarify, but I'm still a bit surprised to see this proposal to both double the current resize requirements and require it to apply to all content (as opposed to just resizing text) as well as move the requirement from AA to A. That may be academic, given most jurisdictions focus on everything up to AA, but still. You may also find some not-welcome cognitive load issues as users who increase text size suddenly find the content disappearing from the viewport as the entire page content reflows down the page. |
I think the failure would be needing to horizontally scroll to see the content (barring exceptions), not the presence of scroll bars. I can't get scroll bars on the Deque example, perhaps there is some browser-bug there but if you don't need to scroll horizontally to read/use it, that's the main thing.
Yes, but that doesn't mean it has to work in every user-agent. E.g. You should use a UL for an under-ordered list, but not every screenreader announces the bullets in the same way, does that mean it isn't supported everywhere? Not everyone uses a screenreader, but the odd hidden heading is acceptable for creating a good heading structure... So long as there are common UAs that do allow 400%, I don't see that percentage as a problem. I don't think adding another exception for user-agents that don't go to 400% would help, because as an author/designer/developer you have to adjust the content. If it adds an exception for some UAs to 300% then you might only test to 300%, but you should be adjusting the layout.
Yes, that was discussed on the LVTF, but the overhead of horizontal scrolling was considered much greater, and there is some good research evidence for that.
The was the considered opinion from the TF based on user-need, but as you say AA would have the same effect in practice, so if there are arguments the other way I don't think it would be a show stopper. |
|
This comment is not specific to this SC, but is general in nature. Do you think it would be helpful if there was a 'simple language' section that clarified the purpose without so much technical qualification? For instance, for this SC it could be: "Authors support the resizing and reflow of content as allowed by the browser." |
|
Possibly, but in the guidelines section the SCs need to meet the SC acceptance requirements. Perhaps as the first line in the understanding document? |
|
I realise this has seen a fair amount of criticism / change suggestions already so I am not sure this still helps.. It would also promote approaches like that of Android browser Dolphin that does reflow text when zooming in (maybe as as a user-selectable option). In mobile apps, I think a case can be made that when zooming in / increasing text size, some content better stays unresized (given that a UA system level zoom function is always available). LV users in our app testing often referred to items by known position / size / colour etc - as repeat users, they did not need to read controls every time but rather relied on their predictability. In contrast, if a nav bar would increase in size and fill half the mobile screen, that can be counterproductive as it it pushes content far down. That indicates that it might make sense to differentiate between content text and text in controls / nav sections. (The old distinction between text and the rest is no longer that useful as most controls (including things like icon fonts) are text now.) As already noted in the TPAC 2016 notes, there seems to be a disconnect between the SC text: "The content of the Web page can be increased to 400% without loss of content or functionality, without two dimensional scrolling, with following the exceptions:" ...and the text that follows in the section Description: "Zoom functions preserve all spatial relationships on the page and all functionality continues to be available. Simply put: a person can make everything bigger or smaller as needed. If the user needs to increase content more than 400%, then reflow would be necessary.") Zoom functions will only preserve all spatial relationships in designs that are not responsive, and by the same token, require two dimensional scrolling, which is excluded in the SC text (bar exceptions). What is perhaps meant in the description text is that the reflow caused by zooming does not lead to an unexpected reordering of content (which might be covered by SC 1.3.2 Meaningful Sequence). Section Testability : "If horizontal scrolling is present, check that the content would not make sense without the scrolling." I have no idea what this means. Minor editorial notes: I would change "The content of the Web page can be increased to 400%" to read "The content of the Web page can be resized to at least 400%" Maybe we need to be more specific as to the issue of loss of content or functionality. What is meant here is avoiding overlaps and clips etc. But there are responsive sites that when zooming in and applying mobile breakpoints consciously cut down on content on that page or view. Testers would need to be told whether or not this fails the SC. Eliminated content may be acceptable under certain conditions, e.g.:
|
|
Hi Jonathan, I'm fairly sure the inner-width calculations will still be consistent, but I'm getting a Windows laptop shortly so I'll test it soon. Cheers, -Alastair |
|
It has been pointed out by @mraccess77 above that people who use a desktop at 400% zoom are actually looking at the mobile responsive layout. To them it isn't just an alternative small screen version, it's their everyday, desktop view. So (as has also been pointed out by others above) content should not be removed from mobile versions, though it can be hidden behind a click button, or even at the end of a link to another page. I think that's important enough for it to be spelled out in the SC. So could I suggest an extra sentence after the first one: "Content is not removed from any version of the page created for smaller screen sizes, unless replaced by a button, link or similar means of access to that content, in the same location on the page as the content being replaced." That bit about the location is needed to stop a developer saying "if you look in the third level submenu, in the 18th option down, you'll find all the material we removed there!" If spelt out in this fashion it would clarify that deliberately removing content on mobile versions is included in "loss of content". |
|
Hi Guy, I agree with the principle, but there are a few counter points to that change: Firstly, I don't think it is possible to achieve that. When the area of the screen is 1/4 of the 'large' variation, stuff has to go somewhere. Trying to make authors put it in the same place (which may be impossible to do, let alone define) would be counter-productive. You would end up with show/hide buttons everywhere. I think it would be better overall (for LV users and people on small screens) for the interface at that size to make sense and be usable, even if that means putting things in different places and/or hiding them behind links or show/hide buttons (because to make it usable, it will have to do that). People should have access to the same content, that is covered by the SC as it stands, but I don't think we should try to enforce a particular user-experience. Also, we need to be careful about the terminology of 'versions'. There was a thread on AGWG recently about ensuring that different 'variations' were included that resulted in this note: A different version would (I think according to WCAG) be at a different URL. I think the new note also helps to cover the issue you're raising, and we can make that clear in the understanding. (Which I really need to get written soon!) |
I think that would be far too restrictive, as it mandates layout/visual design. And it may require sub-optimal solutions. Imagine a page with five or six different panels of content. On large screen, they're shown side-by-side. On small screen, they can be switched to by using options in a hamburger menu. This would be a very appropriate pattern for small screen, but the suggested requirement to have the link/button/disclosure widget in the same location would forbid that. |
I think this can be addressed and clarified in the Understanding doc. We have the wording "without loss of content" in there. I agree there are many ways to interpret what that means. I flagged in discussion earlier that many sites doing 'responsive design' provide a subset of content on their mobile pages. We also need to be careful of when a mobile version is designed specifically for a mobile context in what I would call an app-like UI. I think I used this example earlier, but a government ferry system here offers key information that someone driving en route to a terminal may want such as current conditions at the terminal (vessel delays, weather, etc) and making or confirming reservations. In this context, the argument is that someone does not care about HR job openings or corporate fiscal reports. Such a web-app view of certain features of their site I would argue should not constitute a failure of this SC as long as the company's main website meets this SC. But as stated before, i don't want to downplay the signficant effort some orgs will face who have fragmented a complex service offering into multiple mobile views based on perceived mobile scenarios, but have left their holistic web site desktop biased. I think this can be tackled in a natural refresh cycle, but it does represent a change in direction for some sites. |
|
It is obvious that use case for smartphones are different from that of desktop experience. Nobody would expect Excel on iPhone or Android phones to have as rich a feature set as Excel for OSX or Windows. The web experience is even more restrictive because it has to deal with limitations imposed by web technologies and browser on top of the small screen and on screen keyboard. Features requires UI and UI requires screen real estate. Less screen real estate means less UI and, thus, less features.
That said, I have not read all the incoming mails on the list and I may be missing context. If all this means is that your excel spreadsheet should retain all its cell content, then I totally understand. Opening up the same spreadsheet from mobile or desktop should not mean your formula or tab will be different. But if we are talking about requiring equal feature set regardless or screen size, we have a deal breaker.
Alex Li
|
|
Hi Alex, There's hasn't been much on the list about this, it was accepted a while ago and hasn't changed since. (I assume Guy is relatively fresh to this SC?) You might remember we discussed interfaces like spreadsheets and that's where the exception and note came from. Cheers, -Alastair |
|
Thanks Alastair! Should have read the thread. Glad we are not debating the same thing over again. -Alex |
But the point here is that if the "mobile version" is triggered purely by the viewport size (which in turn is also influenced by zooming/window size on a desktop environment) then it's not a separate "version" - it's purely a relayout of the same page. And as it does depend on zoom/window size, there's no way for a user to switch to the "company's main website" unless they zoom out / enlarge the window / go to a computer with a bigger monitor. If the "mobile version" is completely separate from the "company's main website" (different URL, or the user can switch between them easily) then of course that's not considered the same page/site and needs to be separately evaluated (of course, if the "main website" doesn't allow zooming etc either, then that'll be a failure for that site - and if the "mobile version" then doesn't provide the same content, it can't be counted as a conforming alternative since it's not equivalent) |
|
@patrickhlauke , to be clear, I am talking about the relatively common implementation, where a media query detects the person using a mobile device and they are sent an abridged (and highly customized) version based on that. Frequently there is a "connect to full website" link or something along those lines, which will send a mobile user to the company's full website.
I believe many sites will fail the second of those points, and such websites will need to be updated to meet this SC. I agree with Alastair's assessment that given the timeline we're on, that can be handled in the natural refresh of most sites. |
I'd be careful with terminology. media queries are generally used to just apply different CSS styles based on certain characteristics (like viewport size). so there's no being sent anywhere...the page is the same, just that different styles are in effect (which may or may not hide stuff). but yes, one can also detect/run media queries via a JS interface and based on the outcome of the query load a different page/resources, so this can be a blurry distinction. but classically, when we talk about responsive web design and media queries, we're talking about a single page that changes/adapts. a more common example of a site loading/sending the user to a bespoke mobile version is a site using browser/user-agent sniffing (e.g. with a framework like WURFL https://www.scientiamobile.com/ or just naively coded by hand looking for strings like "iOS", "Android" etc in the UA string) |
|
I agree with Patrick. The thing to remember here is that while the layout
using media queries is commonly thought of as the "mobile version" because
that is what businesses intend it for, it is also the actual desktop layout
that low vision users, using 200% or 400% text size and/or zoom, actually
see and work with on a daily basis. They never see the normal desktop
layout that we see, becaue they would not be able to read the text in
normal size.
Hence why, as Patrick says, no content must be dropped from the mobile
layout, i.e. the layout achieved using media queries.
If the website owner wants to create a second version, using a different
URL, specifically geared for mobiles, that's another matter entirely.
|
clarification: from the mobile site, not necessarily from the layout. what i mean is: if on large screen the homepage has features x, y, z, it's still fine if on small screen this is split (using not just CSS, but additional JS) to a tabbed interface with tabs for x, y, z, or even completely separate pages (one for x, one for y, one for z, etc.) |
|
@patrick, yes, accepted. I meant different layouts as opposed to having
different versions on different URLs. Including if stuff is moved to a
different page. I guess this is why the WCAG has standardised on using
"variation", as was mentioned above, for differences created using media
queries or similar. It's looking like a good term to use!
|
|
I am seriously wondering whether there is a good example where toolbars must be screen resident at all times. One of the most complex applications I use, and I use it daily, is WebStorm. It is a full feature IDE for web development. It has literally dozens of tool bars. They are all easy to call into place when needed, but when I need to edit code in 48px font I can shew them all away. My code wraps and respects indentation, and I have the whole screen. I have had a few JetBrains IDE's and none required permanent screen resident toolbars. Mail clients can operate without resident toolbars. We know that from mobile mail clients. I would really like to see just one application in which toolbars must be present on the screen all of the time. IDE's are not an example. Wayne |
|
At all time, I’m not sure…maybe. At some of the times, visible toolbar is absolutely unavoidable for even the most basic apps. The way I interpret the SC is that the editing content should be zoomable to 320 css pixels. The toolbars themselves don’t need to zoom. So, your code in visual studio and email content in Outlook need to meet zoom. Whether the toolbar is visible or not is the matter of different use cases for different apps and user preference. It is too complex for WCAG to weigh in.
…________________________________
From: WayneEDick <[email protected]>
Sent: Wednesday, December 6, 2017 4:03:38 PM
To: w3c/wcag21
Cc: Alex Li (CELA); Mention
Subject: Re: [w3c/wcag21] Zoom Content (formerly Resize content) (#77)
I am seriously wondering whether there is a good example where toolbars must be screen resident at all times.
One of the most complex applications I use, and I use it daily, is WebStorm. It is a full feature IDE for web development. It has literally dozens of tool bars. They are all easy to call into place when needed, but when I need to edit code in 48px font I can shew them all away. My code wraps and respects indentation, and I have the whole screen. I have had a few JetBrains IDE's and none required permanent screen resident toolbars.
Mail clients can operate without resident toolbars. We know that from mobile mail clients.
I would really like to see just one application in which toolbars must be present on the screen all of the time. IDE's are not an example.
Wayne
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub<#77 (comment)>, or mute the thread<https://github.com/notifications/unsubscribe-auth/AXSAIfXwOtsfj9qnOBjXNbdpRg6jx9N6ks5s9ytagaJpZM4LB3oC>.
|
Or, importantly, they can be scrollable. Sure, it is possible to call in a toolbar, but if that toolbar's options don't fit within 320px and cannot scroll, you'd have to wrap them. You'd end up with those toolbars taking over the whole screen, and then possibly not fitting in anyway and scrolling vertically. A horrible experience. Wayne - we are making good progress, this is going to take some effort to get through as it is, let's try and keep everyone on-board! Cheers, -Alastair |
|
Why don’t toolbars have to zoom if everything else does?
Doesn’t the person need to use them as well?
Why do they only need access to part of the page?
If toolbars can have this problem — why couldnt other parts of the page?
why wouldnt the exception apply to all those parts as well?
… On Dec 7, 2017, at 4:34 AM, Alastair Campbell ***@***.***> wrote:
editing content should be zoomable to 320 css pixels. The toolbars themselves don’t need to zoom.
Or, importantly, they can be scrollable. Sure, it is possible to call in a toolbar, but if that toolbar's options don't fit within 320px and cannot scroll, you'd have to wrap them. You'd end up with those toolbars taking over the whole screen, and then possibly not fitting in either.
Wayne - we are making good progress, this is going to take some effort to get through as it is, let's try and keep everyone on-board!
Cheers,
-Alastair
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#77 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3oGWxG5ONExOXyn87k8WMk22k0heks5s97ExgaJpZM4LB3oC>.
|
|
In practice they will zoom to some degree (and text contained should increase by 200%), but they might scroll or adapt in different ways, and we don't want to get in the way of that. They have a 2D nature, as for many 'toolbars' you need to have both it and the content onscreen. We are excepting things wich cannot be linearised without loosing information, that doesn't apply to other parts of the page. |
|
ok
agree
but this should be covered by the general exception then — not by example or by name.
should be covered by the general exception already which says
except for parts of the content which require two-dimensional layout for usage or meaning.
If that does not cover it — then you need to add another exception.
I am not sure that I would think a toolbar met this — but if everyone else does - OK. IF not we need to fix.
… On Dec 7, 2017, at 10:11 AM, Alastair Campbell ***@***.***> wrote:
In practice they will zoom to some degree (and text contained should increase by 200%), but they might scroll or adapt in different ways, and we don't want to get in the way of that.
They have a 2D nature, as for many 'toolbars' you need to have both it and the content onscreen.
We are excepting things wich cannot be linearised without loosing information, that doesn't apply to other parts of the page.
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#77 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3lnxLb58q-P_fuqlYuwPRfRZfTiLks5s-AAngaJpZM4LB3oC>.
|
|
Hi Gregg, It has been considered part of the general exception, and it is an example in the note. Everyone agreed previously, then Wayne questioned it... |
|
ok great. Be sure it is in the understanding doc then
… On Dec 7, 2017, at 11:00 AM, Alastair Campbell ***@***.***> wrote:
Hi Gregg,
It has been considered part of the general exception, and it is an example in the note. Everyone agreed previously, then Wayne questioned it...
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub <#77 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJph3vc96NGIWTAtPU5F7d1E0tMMUMnkks5s-AuigaJpZM4LB3oC>.
|
|
I think we should leave the exception.
That being said, I am hard pressed for a real example. I do think we need
one in the understanding document. Maybe a serious CAD program for
engineering might use it. Maybe a photo editor might find it necessary. I
use the Mathematica Cloud and it is not an example. Maybe software
engineering applications where huge UML diagrams are developed with complex
SVG would qualify. Anyway I think we should identify one.
I just cannot think of one example. I gave the complex example of a robust
IDE that does everything without permanent resident toolbars. It enlarges
its toolbars. I use them in full screen width when I need them. Then I
close them up. Microsoft Word is another non-example. That ribbon across
the top (a real win for most use cases) can be collapsed. I do it all the
time when I want the whole screen for composition.
Maybe the issue is that programs that are built now cannot change without
major work. That is a point.
I think you are all doing an excellent job. I do not object to the
exception.
…On Thu, Dec 7, 2017 at 8:05 AM, GreggVan ***@***.***> wrote:
ok great. Be sure it is in the understanding doc then
> On Dec 7, 2017, at 11:00 AM, Alastair Campbell ***@***.***>
wrote:
>
> Hi Gregg,
>
> It has been considered part of the general exception, and it is an
example in the note. Everyone agreed previously, then Wayne questioned it...
>
> —
> You are receiving this because you were mentioned.
> Reply to this email directly, view it on GitHub <https://github.com/w3c/
wcag21/issues/77#issuecomment-350011491>, or mute the thread <
https://github.com/notifications/unsubscribe-auth/
AJph3vc96NGIWTAtPU5F7d1E0tMMUMnkks5s-AuigaJpZM4LB3oC>.
>
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
<#77 (comment)>, or mute
the thread
<https://github.com/notifications/unsubscribe-auth/AH0OF9t-XH3L47NRiNN5ajABQtJWvMFeks5s-AzKgaJpZM4LB3oC>
.
|
and others
Current version of SC and Definitions
Open issues and Surveys
Open issues: SC Status page
(Links to surveys require W3C Member access)
Success Criteria (SC) Shortname
Zoom content
SC Text
Content can be displayed at a minimum width of 320 CSS pixels without loss of content or functionality, and without requiring scrolling in the direction of text except for parts of the content which require two-dimensional layout for usage or meaning.
Note: The width of 320 CSS pixels is equivalent to a browser width of 1280 pixels wide at 400% zoom.
Note: Examples of content which require two-dimensional layout are images, maps, diagrams, video, games, presentations, data tables, and interfaces where it is necessary to keep toolbars in view while manipulating content.
Suggested Priority Level
Level AA
Related Glossary additions or changes
None.
What Principle and Guideline the SC falls within.
Principle 1, Guideline 1.4.4 Resize text
Description
Zoom features in browsers make content on the page larger which helps people with mild, moderate and even quite severe vision impairments. A person can make everything bigger or smaller as needed. Zoom is the default method in all desktop browsers to increase the size of content. Mobile browsers (small screen devices) tend to use pinch-zoom, or a text-size setting in the accessibility preferences.
Technologies like HTML/CSS, PDF and ePub have methods of reflowing content to fit the width of the user-agent window. When zooming in on HTML/CSS content, pixels increase in size, so an element that is 200 pixels wide at 200% takes twice the width on screen.
NB: Mobile devices are by necessity more limited in how they can resize content. This success criteria is to ensure the content is capable of resizing to a reasonable degree. In practice people will need to use a device or user-agent capable of reflowing content such as a desktop or laptop computer.
A significant proportion of people with low vision need more than a 200% increase in the size of content. From the Webaim survey 25% of low vision users indicated needing magnification to 400% or more, which is probably more than the total number of screen reader users. (It is 42% for 300% or more).
The impact of horizontal scrolling can increase the effort required to read by 40-100 times, so avoiding scrolling should be the aim whenever feasible.
The size 400% was picked as the largest size a standard website can get to using responsive design. If the user needs to increase content more than 400%, then a complete Linearisation would be necessary which completely overrides the layout of the website.
The testing parameters are more defined than WCAG 2.0's 1.4.4, where the test should start with a browser at 1280px wide, and then zoom in to 400%. In desktop browsers that means your view is then 320px wide, equivalent to a mobile device. Many sites currently cater to that range of sizes, and that number will only increase as more sites update to be mobile friendly. What is not achieved by being mobile-friendly is testing under landscape orientation, rather than assuming a (portrait) mobile device.
It is also possible to meet this success criteria in PDF files by using the reflow feature of Acrobat Reader, which works well on many tagged PDFs with a defined order and structure. ePub files are designed to reflow so should be able to meet this criteria easily.
FAQ
Mobile devices start smaller, how does that work?
The main principle here is that the web content must be capable of resizing, it is not a device-specific issue. The testing procedure is intended to be more specific than the current 1.4.4, starting at 1280px wide and zooming 400%. This works in desktop/laptop browsers.
The whole concept is enabled by media queries, which were designed to enable reformatting for mobile devices. However, the physics of the smaller screens means that expanding text and/or other content is more constrained. The layout method browsers use on small screen devices does not reflow in the same way, it magnifies (e.g. with pinch-zoom) and causes horizontal scrolling regardless of what an author does.
That is one of the reasons to keep 1.4.4 at a lower threshold (200%) without a prohibition on 2D scrolling, there is an applicable SC for mobile. The other reason is that it covers things within the '2D' exception, such as text within data tables.
For content that is of a fixed ratio (video, images etc) they come under the "require two-dimensional layout" exception. In practice they can expand up to the width (and/or height) of the viewport, and be limited to that.
If this is considered an unresolved issue, then we could take the approach of using a minimum content size such as:
However, that creates more separation from the reason for the SC, and looks more technology focused (although it isn't actually different).
Is the 400% by area or dimension?
As per WCAG 2.0's 1.4.4, it is by dimension. I.e. you zoom 200% and the width is 200% wider (and height 200% taller).
What about sites which bring in external content?
Similar to other SCs, including content from elsewhere is still being displayed in that page therefore under the sites responsibility. There is a responsibility to transform content in an accessible way from ATAG 2.0. In practice, if the pages shows external content, it should at least provide that content the full width of the page at higher zoom levels / smaller screen sizes.
Does this mean sites have to be responsive?
Basically: yes.
Another way of saying that is sites have to adapt to different devices and browsers, or as Andy Clarke put it in 2011:
The switch to responsive design is like moving from table-based layout to CSS (actually, I think that was harder than responsive design). We've been talking about zoom and responsive design for accessibility since at least 2013, and even then it was apparent that sites were defaulting to responsive when re-designing.
Apart from particular things (covered by the two-dimensional exception) we have not found a reasonable feasibility argument that new sites/content cannot be implemented in a responsive manner.
What happens if sites move/change things at smaller sizes?
So long as the content and functionality is still available that is ok. If some content is hidden behind a show/hide btton, or navigation is moved into a drop-down it is still available. (Like the 'hamburger' icon patter for navigation).
It is possible people might get confused if things move or get hidden, however, the physics demands that something has to give, you cannot make things bigger and fit them in the same space. Also, the people who need it most would typically be zoomed-in when arriving, so may not notice the difference.
However, if content or functionality is removed that would fail this success criteria.
Unresolved issues
Testability
Expected Results
Techniques
All existing techniques for Proposed New SC: "Size (all content)"
New Techniques
- Using fluid grids. Ref: fluid grids
- Using em based media queries. Ref: em based media queries
- Using responsive images. Ref: HTML picture element and srcset attribute
- @@ Consider a failure technique on fixed sized containers and fixed position content??
- @@ Consider a failure technique on "Interfering with a user agent's ability to zoom" i.e., author using: maximum-scale or minimum-scale or user-scalable=no or user-scalable=0 in the meta element ?? @@ Note: In Pinch zoom thread on the WCAG list people did not seem to be in favor of this as a failure.
- @@ (HTML) Consider failure for preformatted text or excluding this as an exception to no two dimensional scrolling.
Related Information on LVTF wikiThe text was updated successfully, but these errors were encountered: