Skip to content
This repository has been archived by the owner. It is now read-only.

Zoom Content (formerly Resize content) #77

Closed
allanj-uaag opened this Issue Dec 1, 2016 · 207 comments

Comments

Projects
None yet
@allanj-uaag
Copy link
Contributor

commented Dec 1, 2016

Current version of SC and Definitions

Open issues and Surveys

Open issues: SC Status page

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:

Content displays at 320 CSS pixels wide 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.

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:

Web design is responsive design, Responsive Web Design is web design, done right.

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

  • What if the text is already huge?
  • What about native text inputs which are only one line, as filling it in will require scrolling.
  • A more intuitive method of saying "without requiring scrolling in the direction of text"
  • We have two resize SCs at AA now, should we promote 1.4.4 to A?
  • Is it ok to have the 1280px starting point in the testability section but not the SC? If not, should we move to saying "content should work at 320 CSS pixels wide".

Testability

  1. Display content in a user agent capable of zooming 400% and start with a window width of 1280px at a 100% zoom level.
  2. Increase zoom (for all content) to 400%
  3. Check whether all content scales and is perceivable with no loss of content or functionality (e.g. boxes do not overlap, controls are not obscured or separated from their labels, etc.).
  4. If horizontal scrolling is present, check that the content causing scrolling would not make sense without the scrolling.

Expected Results

  • Check # 3 is true.
  • Check # 4 is true.

Techniques

All existing techniques for Proposed New SC: "Size (all content)"

  1. G146: Using liquid layout and ''AND'' using measurements that are relative to other measurements in the content by using one or more of the following techniques:
  2. G206: Providing options within the content to switch to a layout that does not require the user to scroll horizontally to read a line of text

New Techniques

  1. Using fluid grids. Ref: fluid grids
  2. Using em based media queries. Ref: em based media queries
  3. Using responsive images. Ref: HTML picture element and srcset attribute
  4. @@ Consider a failure technique on fixed sized containers and fixed position content??
  5. @@ 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.
  6. @@ (HTML) Consider failure for preformatted text or excluding this as an exception to no two dimensional scrolling.
Related Information on LVTF wiki
@DavidMacDonald

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2016

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. "

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 13, 2016

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.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 15, 2016

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:
"If the user-agent does not provide a means of reflowing content, two dimensional scrolling is exempt."

I'd like to keep it general rather than put 'mobile' in the SC text, we can explain that in the understanding doc.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 16, 2016

If it is possible to replace the current 1.4.4, I would adjust the second exception:

If the user-agent does not provide a means of reflowing content, two dimensional scrolling is exempt but text-only sizing should work up to 200%.

I'm not entirely happy with that wording, but also trying to avoid having lots of caveats!

@DavidMacDonald

This comment has been minimized.

Copy link
Contributor

commented Dec 16, 2016

If the user-agent does not provide a means of reflowing content, content of the web page can be resized up to 200% without loss of content or functionality, and two demential scrolling is exempt.

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.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 16, 2016

The problem is that the 'switch' between layout methods is not at a particular screen size.

  • Desktops go down to, well, 1024px wide and 10" screens, ish?
  • iOS (e.g. iPad) goes from 4" up to 12", and at no size will it let you zoom + reflow or increase the text size of web content except by pinch-zoom with horizontal scrolling.

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:

Text can be resized up to 200% without loss of content or functionality, or two dimensional scrolling.

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:

  1. Text should be able to resize 200% on any user-agent or content.
  2. Content should be able to resize 400% in desktop-style layouts.
  3. Removing layout should leave a correct reading order.

That should still maintain compatibility with WCAG 2.0, it only increase the requirement.

@DavidMacDonald

This comment has been minimized.

Copy link
Contributor

commented Dec 17, 2016

i don't think we want two sizing scs

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 18, 2016

Well, there are two layout methods with very different attributes, so you either have two or ignore mobile.

@Ryladog

This comment has been minimized.

Copy link

commented Dec 18, 2016

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2016

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.

@liamquin

This comment has been minimized.

Copy link

commented Dec 19, 2016

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 19, 2016

Is a user agent that allows resizing to 800% non-compliant?

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.

So "islands of inaccessibility" are allowed?

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.

How can it zoom and still fit content to the viewport without reflowing?

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.

This still seems weird to me. A reflow might be necessary at a 10% increase (110%) and in another circumstance not needed at 500%.

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:

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.
@liamquin

This comment has been minimized.

Copy link

commented Dec 19, 2016

@jnurthen

This comment has been minimized.

Copy link

commented Dec 20, 2016

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.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 20, 2016

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.

@mbgower

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2017

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:

  1. Firefox does not in fact zoom up to 400%. So is the burden of doing so shifted to every author of every page until the time when every user agent can zoom to that magnification?
  2. At 400% on many sites there tends to be some loss of content when reflowing. As an example, some menu controls can end up obscuring some nearby text. Or long words will break without hyphenation. On many pages the loss is minor, but it causes me concern since it now becomes a debate about when a loss of content is considered a failure.

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.

If the user needs to increase content more than 400%, then reflow would be necessary.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2017

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.

I find the sentence on reflow confusing

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.

@mbgower

This comment has been minimized.

Copy link
Contributor

commented Jan 6, 2017

@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.

From discussions on other SCs it seems that some UAs need to support an SC, but not all.

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.
My concerns about overhead to get to 400% notwithstanding, I think this is a worthy candidate.

@alastc

This comment has been minimized.

Copy link
Contributor

commented Jan 7, 2017

if the presence of the scrollbars is the failure

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.

So the requirement is really to author content that can zoom without requiring horizontal scrolling.

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.

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.

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.

as well as move the requirement from AA to A

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.

@awkawk awkawk changed the title Resize Content - Ready for Review Resize Content Jan 9, 2017

@mbgower

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2017

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."

@alastc

This comment has been minimized.

Copy link
Contributor

commented Jan 18, 2017

Possibly, but in the guidelines section the SCs need to meet the SC acceptance requirements. Perhaps as the first line in the understanding document?

@detlevhfischer

This comment has been minimized.

Copy link
Contributor

commented Jan 20, 2017

I realise this has seen a fair amount of criticism / change suggestions already so I am not sure this still helps..
As to the difference in resize behaviour between desktop and mobile:
A SC that asks for resizing via text reflow would act as an incentive to mobile browser makers to honour users' UA's system level settings of text size, and use heuristics to apply them to main text content (in the same way as browsers' reader modes use heuristics to determine where to offer enlargeable content, and what content to leave out). That would also address the concern in some of the TPAC comments that some content better remains at the same size (e.g. top of the page navigation controls).

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.:

  • when there are other means to get to the same content on another page (as with navigation menus that may not open submenus but the same submenu content is present on a page linked to from the main menu item).
  • when there is a control to switch to the desktop layout (which then also means that users have to accept two dimensional scrolling)
@alastc

This comment has been minimized.

Copy link
Contributor

commented Jun 22, 2017

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

@guyhickling

This comment has been minimized.

Copy link

commented Jul 28, 2017

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".

@alastc

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2017

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:
https://rawgit.com/w3c/wcag21/62-63-71-conformance-changes/guidelines/#conformance-reqs

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!)

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jul 28, 2017

in the same location on the page as the content being replaced

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.

@mbgower

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2017

@guyhickling

content should not be removed from mobile versions

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.
There's going to need to be clear language about how such a technique fails.

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.

@alexswli

This comment has been minimized.

Copy link

commented Jul 28, 2017

@alastc

This comment has been minimized.

Copy link
Contributor

commented Jul 28, 2017

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

@alexswli

This comment has been minimized.

Copy link

commented Jul 28, 2017

Thanks Alastair! Should have read the thread. Glad we are not debating the same thing over again. -Alex

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

@mbgower

We also need to be careful of when a mobile version is designed specifically for a mobile context [...] 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 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)

@mbgower

This comment has been minimized.

Copy link
Contributor

commented Jul 31, 2017

@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.
As you mention, this should be acceptable IF

  1. there is an affordance to easily switch to the full website and
  2. the full website is responsive.

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.

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

I am talking about the relatively common implementation, where a media query detects the person using a mobile device and they are sent to an abridged (and highly customized) version based on that

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)

@guyhickling

This comment has been minimized.

Copy link

commented Jul 31, 2017

@patrickhlauke

This comment has been minimized.

Copy link
Member

commented Jul 31, 2017

Hence why, as Patrick says, no content must be dropped from the mobile
layout, i.e. the layout achieved using media queries.

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.)

@guyhickling

This comment has been minimized.

Copy link

commented Jul 31, 2017

@WayneEDick

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

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

@alexswli

This comment has been minimized.

Copy link

commented Dec 7, 2017

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

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 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

@GreggVan

This comment has been minimized.

Copy link

commented Dec 7, 2017

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

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.

@GreggVan

This comment has been minimized.

Copy link

commented Dec 7, 2017

@alastc

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

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...

@GreggVan

This comment has been minimized.

Copy link

commented Dec 7, 2017

@WayneEDick

This comment has been minimized.

Copy link
Contributor

commented Dec 7, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
You can’t perform that action at this time.