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
Contributor

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

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 13, 2016

Contributor

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

Contributor

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

Show comment
Hide comment
@alastc

alastc Dec 13, 2016

Contributor

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.

Contributor

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

Show comment
Hide comment
@alastc

alastc Dec 15, 2016

Contributor

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.

Contributor

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

Show comment
Hide comment
@alastc

alastc Dec 16, 2016

Contributor

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!

Contributor

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

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 16, 2016

Contributor

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.

Contributor

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

Show comment
Hide comment
@alastc

alastc Dec 16, 2016

Contributor

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.

Contributor

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

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Dec 17, 2016

Contributor

i don't think we want two sizing scs

Contributor

DavidMacDonald commented Dec 17, 2016

i don't think we want two sizing scs

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 18, 2016

Contributor

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

Contributor

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

Show comment
Hide comment
@Ryladog

Ryladog Dec 18, 2016

Ryladog commented Dec 18, 2016

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 19, 2016

Contributor

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.

Contributor

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

Show comment
Hide comment
@liamquin

liamquin Dec 19, 2016

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 19, 2016

Contributor

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

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

Show comment
Hide comment
@liamquin

liamquin Dec 19, 2016

@jnurthen

This comment has been minimized.

Show comment
Hide comment
@jnurthen

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

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.

Show comment
Hide comment
@alastc

alastc Dec 20, 2016

Contributor

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.

Contributor

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

Show comment
Hide comment
@mbgower

mbgower Jan 6, 2017

Contributor

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.

Contributor

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

Show comment
Hide comment
@alastc

alastc Jan 6, 2017

Contributor

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.

Contributor

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

Show comment
Hide comment
@mbgower

mbgower Jan 6, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@alastc

alastc Jan 7, 2017

Contributor

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.

Contributor

alastc 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 from Resize Content - Ready for Review to Resize Content Jan 9, 2017

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 18, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@alastc

alastc Jan 18, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jan 20, 2017

Contributor

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

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

Show comment
Hide comment
@alastc

alastc Jan 21, 2017

Contributor

Hi Detlev,

It has changed completely since TPAC, so I don't think any notes from that time are relevant. But on your points, are you essentially suggesting:

  • Not to have an exception for mobile-style (non reflow) user agents?
  • To re-write the description.

On some of the wording points:

Admittedly the phrasing of "Zoom functions preserve all spatial relationships" is not ideal, but it is getting at the fact that you can zoom without things overlapping or loosing information. The key at the moment is whether the SC text is reasonable, I do take on board that the description needs re-writing & expanding before it becomes an understanding document.

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.

That is trying to check for the exception: "If the spatial layout of some the content is essential to that contents use, that part of the content is exempt." So if the content is a data table or diagram, i.e. something 2D, the it is ok to have horizontal scrolling for that content.

On the minor editorial, change "increased" to "resized", I don't think that works as well in English, as we aren't trying to make sure it can be shrunk by 400%. If we were I'd agree, but that isn't the aim so increased is a better term.

Maybe we need to be more specific as to the issue of loss of content or functionality.

That's straight from WCAG 2.0, so similarly to 1.4.4 if the user cannot access content or functionality when zoomed in (that is available when not zoomed in), then it fails.

I agree with your caveats, which is good source material for the understanding document, but it is an established phrase in WCAG.

Contributor

alastc commented Jan 21, 2017

Hi Detlev,

It has changed completely since TPAC, so I don't think any notes from that time are relevant. But on your points, are you essentially suggesting:

  • Not to have an exception for mobile-style (non reflow) user agents?
  • To re-write the description.

On some of the wording points:

Admittedly the phrasing of "Zoom functions preserve all spatial relationships" is not ideal, but it is getting at the fact that you can zoom without things overlapping or loosing information. The key at the moment is whether the SC text is reasonable, I do take on board that the description needs re-writing & expanding before it becomes an understanding document.

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.

That is trying to check for the exception: "If the spatial layout of some the content is essential to that contents use, that part of the content is exempt." So if the content is a data table or diagram, i.e. something 2D, the it is ok to have horizontal scrolling for that content.

On the minor editorial, change "increased" to "resized", I don't think that works as well in English, as we aren't trying to make sure it can be shrunk by 400%. If we were I'd agree, but that isn't the aim so increased is a better term.

Maybe we need to be more specific as to the issue of loss of content or functionality.

That's straight from WCAG 2.0, so similarly to 1.4.4 if the user cannot access content or functionality when zoomed in (that is available when not zoomed in), then it fails.

I agree with your caveats, which is good source material for the understanding document, but it is an established phrase in WCAG.

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jan 23, 2017

Contributor

Hi Alastair,
thanks for your comments and clarifications!
First, has the draft on top of this page been updated anywhere? Are you collecting input to then edit the draft? (I mainly ask because I have also picked up two SCs and am not quite sure what the process is).

You noted that I seem to suggest "Not to have an exception for mobile-style (non reflow) user agents"

I am just not sure whether an exception makes sense - I realise that not all user agents will support reflow but do we actually need explicit exceptions if some user agents fail to support certain things? (I see a similar discussion around custom style sheets for element level changes to font, size, spacing etc via user style sheets and / or plugins that may not be (fully) supported for PDF.)
Reasons to avoid exceptions:

  • exceptions may be out of date soon (as more UAs might support reflow - you could even argue that many UA already support it by offering a reader mode)
  • exceptions reduce incentives for UA makers to cater for text resizing when it is actually and demonstrably doable (see Android Dolphin browser)

On the other hand I am aware that we need realism and should not ask for things that cannot be achieved by web authors (that's why I wondered whether ir would make sense to distinguish between text content and text based controls).

A wording suggestion for section Testability (certainly not the last word, but avoids the hard-to-parse double negative of "would not make sense without the scrolling":
"If increased content does not reflow and instead requires horizontal scolling or panning, check that the two-dimensional layout of the content is essential for its use"

You write: "On the minor editorial, change "increased" to "resized", I don't think that works as well in English, as we aren't trying to make sure it can be shrunk by 400%."

Not being a native speaker I am not the best judge as to how well these terms will work, but I have been told that there are situations where LV users indeed shrink rather than increase content - so to cover those cases, resize seems more neutral. I guess that was the reason why SC 1.4.4 does use the term resize rather than _increase. (In testing I have never seen a LV user shrinking stuff but if the default size is large and the real estate limited, it might happen.)

As to "loss of content or functionality" - that content stuff is eliminated at different breakpoints was not a common thing at the time of WCAG 2.0 and therefore wasn't addressed in wording at the time, but is quite common now. We need to think of testers that might fail content because things disappear when zooming in - by design, not because something then breaks. It would be good to spell out that this scenario is not addressed in this SC (or if it is, as it arguably affects LV users who need magnification more than other users) it would need to make the difference explicit and spell out under which conditions that (intentional) type of "loss of content or functionality" would be acceptable. So while this is indeed an established phrase in WCAG it might need updating to make it unambiguous.

Contributor

detlevhfischer commented Jan 23, 2017

Hi Alastair,
thanks for your comments and clarifications!
First, has the draft on top of this page been updated anywhere? Are you collecting input to then edit the draft? (I mainly ask because I have also picked up two SCs and am not quite sure what the process is).

You noted that I seem to suggest "Not to have an exception for mobile-style (non reflow) user agents"

I am just not sure whether an exception makes sense - I realise that not all user agents will support reflow but do we actually need explicit exceptions if some user agents fail to support certain things? (I see a similar discussion around custom style sheets for element level changes to font, size, spacing etc via user style sheets and / or plugins that may not be (fully) supported for PDF.)
Reasons to avoid exceptions:

  • exceptions may be out of date soon (as more UAs might support reflow - you could even argue that many UA already support it by offering a reader mode)
  • exceptions reduce incentives for UA makers to cater for text resizing when it is actually and demonstrably doable (see Android Dolphin browser)

On the other hand I am aware that we need realism and should not ask for things that cannot be achieved by web authors (that's why I wondered whether ir would make sense to distinguish between text content and text based controls).

A wording suggestion for section Testability (certainly not the last word, but avoids the hard-to-parse double negative of "would not make sense without the scrolling":
"If increased content does not reflow and instead requires horizontal scolling or panning, check that the two-dimensional layout of the content is essential for its use"

You write: "On the minor editorial, change "increased" to "resized", I don't think that works as well in English, as we aren't trying to make sure it can be shrunk by 400%."

Not being a native speaker I am not the best judge as to how well these terms will work, but I have been told that there are situations where LV users indeed shrink rather than increase content - so to cover those cases, resize seems more neutral. I guess that was the reason why SC 1.4.4 does use the term resize rather than _increase. (In testing I have never seen a LV user shrinking stuff but if the default size is large and the real estate limited, it might happen.)

As to "loss of content or functionality" - that content stuff is eliminated at different breakpoints was not a common thing at the time of WCAG 2.0 and therefore wasn't addressed in wording at the time, but is quite common now. We need to think of testers that might fail content because things disappear when zooming in - by design, not because something then breaks. It would be good to spell out that this scenario is not addressed in this SC (or if it is, as it arguably affects LV users who need magnification more than other users) it would need to make the difference explicit and spell out under which conditions that (intentional) type of "loss of content or functionality" would be acceptable. So while this is indeed an established phrase in WCAG it might need updating to make it unambiguous.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 23, 2017

Contributor

Are you collecting input to then edit the draft?

Yes, but unfortunately in github only the issue creator can edit the description, so I'll ask Jim to update it in one go.

I am just not sure whether an exception makes sense

I've come to that conclusion as well, I"ll remove it in the next update.

A wording suggestion for section Testability...

That's great, thanks.

I have been told that there are situations where LV users indeed shrink rather than increase content - so to cover those cases, resize seems more neutral.

That is true, but not to 400%. There are reasons (such as lack of peripheral vision, tunnel vision) where you have a visual impairment, but don't want to increase the size of text. You want to keep it in a narrow column.

The SC for Linearisation is more important here, for example see this test page and select "Linearise 20em wide". However, you wouldn't want to decrease the text-size to 25%!
Also, if users know they can resize the window and it reflows, that is a good outcome as well and it is based on the same (responsive) principle.

that content stuff is eliminated at different breakpoints was not a common thing at the time of WCAG 2.0 but is quite common now

There were equivalents though, where you wouldn't fail a menu with drop-downs so long as the information was available (e.g. selecting the menu item with a drop-down gets you to a page with those links).

We need to think of testers that might fail content because things disappear when zooming in - by design

Within the SC text, or as part of understanding docs? The principle should be that a user who is zoomed-in can achieve everything the non-zoomed user can. It doesn't have to be the same, but everything should be achievable.
If content is hidden and not available, that should fail. If it is hidden but you can select to "see more", that's fine.

Would it be ok to outline that in the understanding?

Contributor

alastc commented Jan 23, 2017

Are you collecting input to then edit the draft?

Yes, but unfortunately in github only the issue creator can edit the description, so I'll ask Jim to update it in one go.

I am just not sure whether an exception makes sense

I've come to that conclusion as well, I"ll remove it in the next update.

A wording suggestion for section Testability...

That's great, thanks.

I have been told that there are situations where LV users indeed shrink rather than increase content - so to cover those cases, resize seems more neutral.

That is true, but not to 400%. There are reasons (such as lack of peripheral vision, tunnel vision) where you have a visual impairment, but don't want to increase the size of text. You want to keep it in a narrow column.

The SC for Linearisation is more important here, for example see this test page and select "Linearise 20em wide". However, you wouldn't want to decrease the text-size to 25%!
Also, if users know they can resize the window and it reflows, that is a good outcome as well and it is based on the same (responsive) principle.

that content stuff is eliminated at different breakpoints was not a common thing at the time of WCAG 2.0 but is quite common now

There were equivalents though, where you wouldn't fail a menu with drop-downs so long as the information was available (e.g. selecting the menu item with a drop-down gets you to a page with those links).

We need to think of testers that might fail content because things disappear when zooming in - by design

Within the SC text, or as part of understanding docs? The principle should be that a user who is zoomed-in can achieve everything the non-zoomed user can. It doesn't have to be the same, but everything should be achievable.
If content is hidden and not available, that should fail. If it is hidden but you can select to "see more", that's fine.

Would it be ok to outline that in the understanding?

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jan 23, 2017

Contributor

@alastc

"...there are situations where LV users indeed shrink rather than increase content - so to cover those cases, resize seems more neutral."

"That is true, but not to 400%."

400% is just an upper limit, and the need may rarely arise to size down (more modestly). That's why I still think resize is the better (more generic) term, even though in most cases it is indeed = increase. But I'll leave it at that.

"Would it be ok to outline that in the understanding?"

Yes, fine!

Contributor

detlevhfischer commented Jan 23, 2017

@alastc

"...there are situations where LV users indeed shrink rather than increase content - so to cover those cases, resize seems more neutral."

"That is true, but not to 400%."

400% is just an upper limit, and the need may rarely arise to size down (more modestly). That's why I still think resize is the better (more generic) term, even though in most cases it is indeed = increase. But I'll leave it at that.

"Would it be ok to outline that in the understanding?"

Yes, fine!

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 24, 2017

Contributor

If you make a site capable of resizing upwards 400%, is there anything you need to do to enable it to resize downwards? I can't think of anything.

I think that leaves the current proposal at:

"The content of the Web page can be increased up to 400% without loss of content, functionality or two-dimensional scrolling, except where spatial layout of some the content is essential to that content's use, that part of the content is exempt."

Contributor

alastc commented Jan 24, 2017

If you make a site capable of resizing upwards 400%, is there anything you need to do to enable it to resize downwards? I can't think of anything.

I think that leaves the current proposal at:

"The content of the Web page can be increased up to 400% without loss of content, functionality or two-dimensional scrolling, except where spatial layout of some the content is essential to that content's use, that part of the content is exempt."

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 24, 2017

Contributor

The content of the Web page can be increased up to 400% without loss of content, functionality or two-dimensional scrolling, except where spatial layout of some the content is essential to that content's use, that part of the content is exempt.

Okay, a whole bunch of suggested minor tweaking.

  • Although "up" is in Resize Text, I'd suggest it is superfluous. Took out.
  • I wondered about adding "fixed" before "spatial". All content is spacial layout to some degree. Isn't it when the spacial layout is fixed that it becomes the consideration? This is a weak suggestion.
  • You're missing "of" after "some", but I don't think you need the word "some" anyway. Took out.
  • Changed "content's use" to "content's use or meaning". I wanted to make this just "meaning", since I would think issues that can't be responsively designed to 400% would be meaning problems, not usage, but I left "use" in.
  • Then thought we could probably remove the second use of content, so took it out too.
  • The final clause is unnecessary, so removed. If the exception needs elaboration, it can be done in the body of the SC.

I end up with:

The content of the Web page can be resized to 400% without loss of content, functionality or two-dimensional scrolling, except where fixed spatial layout is essential to use or meaning.

Contributor

mbgower commented Jan 24, 2017

The content of the Web page can be increased up to 400% without loss of content, functionality or two-dimensional scrolling, except where spatial layout of some the content is essential to that content's use, that part of the content is exempt.

Okay, a whole bunch of suggested minor tweaking.

  • Although "up" is in Resize Text, I'd suggest it is superfluous. Took out.
  • I wondered about adding "fixed" before "spatial". All content is spacial layout to some degree. Isn't it when the spacial layout is fixed that it becomes the consideration? This is a weak suggestion.
  • You're missing "of" after "some", but I don't think you need the word "some" anyway. Took out.
  • Changed "content's use" to "content's use or meaning". I wanted to make this just "meaning", since I would think issues that can't be responsively designed to 400% would be meaning problems, not usage, but I left "use" in.
  • Then thought we could probably remove the second use of content, so took it out too.
  • The final clause is unnecessary, so removed. If the exception needs elaboration, it can be done in the body of the SC.

I end up with:

The content of the Web page can be resized to 400% without loss of content, functionality or two-dimensional scrolling, except where fixed spatial layout is essential to use or meaning.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 24, 2017

Contributor

Hi Mike,

That's mostly good, my only concern is that the exception is then page-level.

I.e. if there is some content that is 2D, you can answer 'true' to the whole page, rather than just that content.

Oh - and to comment on the potential grey area: A data-table or fixed size diagram could create horizontal scrolling, but generally the browser will still bring reflowable content within the viewport, and the larger bits then stick-out, so you can scroll to see the rest of them if needed. But just for that content.

Contributor

alastc commented Jan 24, 2017

Hi Mike,

That's mostly good, my only concern is that the exception is then page-level.

I.e. if there is some content that is 2D, you can answer 'true' to the whole page, rather than just that content.

Oh - and to comment on the potential grey area: A data-table or fixed size diagram could create horizontal scrolling, but generally the browser will still bring reflowable content within the viewport, and the larger bits then stick-out, so you can scroll to see the rest of them if needed. But just for that content.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 24, 2017

Contributor

Ah, why not remove "page" then?

Content can be resized to 400% without loss of content, functionality or two-dimensional scrolling, except where fixed spatial layout is essential to use or meaning.

Having spent a lot of time rethinking "page" references to make WCAG applicable to other technologies in WCAG2ICT, I've always wondered why it even needs to be specified. (Another topic!)

Even if you want to leave "page" in, I think it would be simple to clarify the exception in the Understanding doc, along with a whole raft of other matters that have been flagged in this very useful discussion.

Contributor

mbgower commented Jan 24, 2017

Ah, why not remove "page" then?

Content can be resized to 400% without loss of content, functionality or two-dimensional scrolling, except where fixed spatial layout is essential to use or meaning.

Having spent a lot of time rethinking "page" references to make WCAG applicable to other technologies in WCAG2ICT, I've always wondered why it even needs to be specified. (Another topic!)

Even if you want to leave "page" in, I think it would be simple to clarify the exception in the Understanding doc, along with a whole raft of other matters that have been flagged in this very useful discussion.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jan 24, 2017

Contributor

I would be happy with that, but I've been told that the page is the unit of testing so anything acting within the page needs to be called out. I'm happy to be wrong about that though.

Contributor

alastc commented Jan 24, 2017

I would be happy with that, but I've been told that the page is the unit of testing so anything acting within the page needs to be called out. I'm happy to be wrong about that though.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jan 24, 2017

Contributor

Okay, we can wait for clarity on the necessity of the "page" language, grin.
Regardless, as I said, some language can be put in the SC document clarifying that the exception applies to only the portion of the page which relies on a fixed spatial relationship. The rest of the page content must continue to meet the resize requirement.

Contributor

mbgower commented Jan 24, 2017

Okay, we can wait for clarity on the necessity of the "page" language, grin.
Regardless, as I said, some language can be put in the SC document clarifying that the exception applies to only the portion of the page which relies on a fixed spatial relationship. The rest of the page content must continue to meet the resize requirement.

@kerstinp

This comment has been minimized.

Show comment
Hide comment
@kerstinp

kerstinp Jun 6, 2017

@DavidMacDonald @alastc

I'm not convinced when it comes to PDF. As written I see a lot of problems. I really would like to recommend that PDF is addressed in a chapter of this SC. That this SC will also apply to PDF should be made very clear for commenters of the next working draft.

kerstinp commented Jun 6, 2017

@DavidMacDonald @alastc

I'm not convinced when it comes to PDF. As written I see a lot of problems. I really would like to recommend that PDF is addressed in a chapter of this SC. That this SC will also apply to PDF should be made very clear for commenters of the next working draft.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jun 6, 2017

Contributor

As written I see a lot of problems.

Can you see any way of writing it that wouldn't be problematic? Given that no-one seems to know how it actually works, and many of the issues appear to be bugs in the implementation, I don't see a way to work-around that.

Overall, I don't think we should work around it, it is not working for the user-population who need it, and there is nothing we can tell authors to do that would easily mitigate it except working through the issues.

Contributor

alastc commented Jun 6, 2017

As written I see a lot of problems.

Can you see any way of writing it that wouldn't be problematic? Given that no-one seems to know how it actually works, and many of the issues appear to be bugs in the implementation, I don't see a way to work-around that.

Overall, I don't think we should work around it, it is not working for the user-population who need it, and there is nothing we can tell authors to do that would easily mitigate it except working through the issues.

@kerstinp

This comment has been minimized.

Show comment
Hide comment
@kerstinp

kerstinp Jun 6, 2017

@alastc

Can you see any way of writing it that wouldn't be problematic?

No. I don't see options to write that in a way that wouldn't be problematic. Sorry. :-( Also I see a conflict between this new SC and the existing 1.4.8 Nr. 5.

kerstinp commented Jun 6, 2017

@alastc

Can you see any way of writing it that wouldn't be problematic?

No. I don't see options to write that in a way that wouldn't be problematic. Sorry. :-( Also I see a conflict between this new SC and the existing 1.4.8 Nr. 5.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jun 6, 2017

Contributor

That's ok (for now), we need to establish good new SCs, then work on the conflicts. (Otherwise you couldn't create good new SCs.)

Contributor

alastc commented Jun 6, 2017

That's ok (for now), we need to establish good new SCs, then work on the conflicts. (Otherwise you couldn't create good new SCs.)

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jun 6, 2017

Contributor

I'm fine with it for now -- but we will need to put a note in there to say the two-dimensional part will have to be addressed at some point. As it reads now a Latin based page could have horizontal scrolling but not vertical and could pass.

Contributor

mraccess77 commented Jun 6, 2017

I'm fine with it for now -- but we will need to put a note in there to say the two-dimensional part will have to be addressed at some point. As it reads now a Latin based page could have horizontal scrolling but not vertical and could pass.

@mbgower

This comment has been minimized.

Show comment
Hide comment
@mbgower

mbgower Jun 6, 2017

Contributor

It took 9 years to get WCAG 2 right.

@DavidMacDonald, first, not everyone would agree it was "right." Second, I'm pretty sure that everyone would agree that nine years is too long.

So, I think we've got to be more focused on agreeing on principle, and where we get bogged down in definitions, providing context for those variations in some way and seeking the public's input much more quickly. The basic concept of this SC has been pretty solid for some time. Instead of several of us taking shots at various ways of trying to say the same thing most fittingly, we could have tossed this out to the larger community to churn on it and focused on ushering some other SCs into that group-agreement-on-principle state. My two bits to speed up the process.

In light of what I just wrote, although I prefer the version that stuck with two-dimensional scrolling, I can live with the axis version.

Contributor

mbgower commented Jun 6, 2017

It took 9 years to get WCAG 2 right.

@DavidMacDonald, first, not everyone would agree it was "right." Second, I'm pretty sure that everyone would agree that nine years is too long.

So, I think we've got to be more focused on agreeing on principle, and where we get bogged down in definitions, providing context for those variations in some way and seeking the public's input much more quickly. The basic concept of this SC has been pretty solid for some time. Instead of several of us taking shots at various ways of trying to say the same thing most fittingly, we could have tossed this out to the larger community to churn on it and focused on ushering some other SCs into that group-agreement-on-principle state. My two bits to speed up the process.

In light of what I just wrote, although I prefer the version that stuck with two-dimensional scrolling, I can live with the axis version.

@DavidMacDonald

This comment has been minimized.

Show comment
Hide comment
@DavidMacDonald

DavidMacDonald Jun 6, 2017

Contributor

maybe an editors note that we are seeking input on PDF. To me I think one of three things will happen if this goes through.

  • Adobe and other UA manufacturers will give reflow some new attention.
  • There will be a quickening of the exodus from PDF as content on the web beyond archiving documents, and the solution will become ever increasing extract PDF to HTML for conformance.
  • The SC or the WCAG 2.1 will be rejected by stakeholders who rely on PDF.

As an aside, I don't think there is any way to pass this in a Livecycle fillable (PDF wrapped) form which I think will be dying in the coming years.

Perhaps we can leverage the language from adaptive text SC.

If the technology allows it...

@mbgower Perhaps "right" isn't the right word, because there are always tradeoffs between industry and the disability community. Perhaps it would be more accurate to say "WCAG 2.0 was one of the most successful standards ever."

Contributor

DavidMacDonald commented Jun 6, 2017

maybe an editors note that we are seeking input on PDF. To me I think one of three things will happen if this goes through.

  • Adobe and other UA manufacturers will give reflow some new attention.
  • There will be a quickening of the exodus from PDF as content on the web beyond archiving documents, and the solution will become ever increasing extract PDF to HTML for conformance.
  • The SC or the WCAG 2.1 will be rejected by stakeholders who rely on PDF.

As an aside, I don't think there is any way to pass this in a Livecycle fillable (PDF wrapped) form which I think will be dying in the coming years.

Perhaps we can leverage the language from adaptive text SC.

If the technology allows it...

@mbgower Perhaps "right" isn't the right word, because there are always tradeoffs between industry and the disability community. Perhaps it would be more accurate to say "WCAG 2.0 was one of the most successful standards ever."

@detlevhfischer

This comment has been minimized.

Show comment
Hide comment
@detlevhfischer

detlevhfischer Jun 14, 2017

Contributor

I wonder whether testing this SC would require resizing the desktop browser window to 320px width OR starting with 1280px width and then zooming to 400% - or whether both approaches should be equally valid. (As noted by @mbgower, testing in Firefox would not allow the second option currently as it linits out at 300%).
At a width as narrow as 320px, the vertical scrollbar in IE and Firefox can cover the right edge of content, which can make a difference when assessing whether all content is available. (The Chrome browser does not seem to allow a width that narrow (or takes into account the scrollbar width in a different way).
Take www.zdf.de as example, a site with a carefully optimised responsive design. At 320px width/ 100% zoom, vertical scrollbars mostly cover the orange dots at the right side that expand to show social media icons. (On small screen mobile devices like Moto E, all is fine.) On the narrow desktop browser view of 320px width, there aren't horizontal scrollbars showing up that would allow access to the orange dots.
Maybe this is not really an issue, just putting it in for the record...

Contributor

detlevhfischer commented Jun 14, 2017

I wonder whether testing this SC would require resizing the desktop browser window to 320px width OR starting with 1280px width and then zooming to 400% - or whether both approaches should be equally valid. (As noted by @mbgower, testing in Firefox would not allow the second option currently as it linits out at 300%).
At a width as narrow as 320px, the vertical scrollbar in IE and Firefox can cover the right edge of content, which can make a difference when assessing whether all content is available. (The Chrome browser does not seem to allow a width that narrow (or takes into account the scrollbar width in a different way).
Take www.zdf.de as example, a site with a carefully optimised responsive design. At 320px width/ 100% zoom, vertical scrollbars mostly cover the orange dots at the right side that expand to show social media icons. (On small screen mobile devices like Moto E, all is fine.) On the narrow desktop browser view of 320px width, there aren't horizontal scrollbars showing up that would allow access to the orange dots.
Maybe this is not really an issue, just putting it in for the record...

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jun 14, 2017

Contributor

Hi Detlev,

Browsers (and operating systems) do deal with scrollbars differently, but the inner viewport width should be consistent. On MacOS scrollbars don't appear until you scroll, and then float over the top. That means they don't impact the width calculations, which is helpful in this case!

We can add something about that in the understanding, I don't think it should impact the SC text because it is the content that should be 320px, it is up to the tester to know how to get to that.

Theoretically you should be able to test either by narrowing or from zooming, but I suggest we stick to zooming because that will highlight more issues. For example, sticky headers are more of a problem at 320px wide by 200px high (roughly the height from zooming on desktop), compared to 320px by 600px you get from narrowing the window.

We could mention that in FF you can test to 400% by narrowing to 960px wide, then zooming to 300%.

Contributor

alastc commented Jun 14, 2017

Hi Detlev,

Browsers (and operating systems) do deal with scrollbars differently, but the inner viewport width should be consistent. On MacOS scrollbars don't appear until you scroll, and then float over the top. That means they don't impact the width calculations, which is helpful in this case!

We can add something about that in the understanding, I don't think it should impact the SC text because it is the content that should be 320px, it is up to the tester to know how to get to that.

Theoretically you should be able to test either by narrowing or from zooming, but I suggest we stick to zooming because that will highlight more issues. For example, sticky headers are more of a problem at 320px wide by 200px high (roughly the height from zooming on desktop), compared to 320px by 600px you get from narrowing the window.

We could mention that in FF you can test to 400% by narrowing to 960px wide, then zooming to 300%.

@mraccess77

This comment has been minimized.

Show comment
Hide comment
@mraccess77

mraccess77 Jun 22, 2017

Contributor

I would also add that in testing the MS Windows scale factor should also be factored in for platforms that allow the user to adjust the dpi/scale.

Contributor

mraccess77 commented Jun 22, 2017

I would also add that in testing the MS Windows scale factor should also be factored in for platforms that allow the user to adjust the dpi/scale.

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jun 22, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@guyhickling

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

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.

Show comment
Hide comment
@alastc

alastc Jul 28, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jul 28, 2017

Member

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.

Member

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

Show comment
Hide comment
@mbgower

mbgower Jul 28, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@alexswli

alexswli Jul 28, 2017

alexswli commented Jul 28, 2017

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Jul 28, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@alexswli

alexswli Jul 28, 2017

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

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

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jul 31, 2017

Member

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

Member

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

Show comment
Hide comment
@mbgower

mbgower Jul 31, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jul 31, 2017

Member

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)

Member

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

Show comment
Hide comment
@guyhickling

guyhickling Jul 31, 2017

guyhickling commented Jul 31, 2017

@patrickhlauke

This comment has been minimized.

Show comment
Hide comment
@patrickhlauke

patrickhlauke Jul 31, 2017

Member

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

Member

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

Show comment
Hide comment
@guyhickling

guyhickling Jul 31, 2017

guyhickling commented Jul 31, 2017

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Dec 7, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@alexswli

alexswli Dec 7, 2017

alexswli commented Dec 7, 2017

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 7, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@GreggVan

GreggVan Dec 7, 2017

GreggVan commented Dec 7, 2017

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 7, 2017

Contributor

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.

Contributor

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

Show comment
Hide comment
@GreggVan

GreggVan Dec 7, 2017

GreggVan commented Dec 7, 2017

@alastc

This comment has been minimized.

Show comment
Hide comment
@alastc

alastc Dec 7, 2017

Contributor

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

Contributor

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

Show comment
Hide comment
@GreggVan

GreggVan Dec 7, 2017

GreggVan commented Dec 7, 2017

@WayneEDick

This comment has been minimized.

Show comment
Hide comment
@WayneEDick

WayneEDick Dec 7, 2017

Contributor
Contributor

WayneEDick commented Dec 7, 2017

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.