RE: How 1.4.4 Resize text applies when mobile templates kick in

The challenge is the range of resolutions people use on the desktop and available resolutions on mobile devices. Some people like the lower resolutions like 800x600 which isn’t the norm for laptops these days. Also the sizing aspect only works for a x percentage of low vision users. What about those users who cannot use the browser size functionality and rely on a magnification software? Shouldn’t the standard include them as well to make sure the page renders correctly in their software?



Sean Murphy
Accessibility Software engineer
seanmmur@cisco.com
Tel: +61 2 8446 7751      Cisco Systems, Inc.
The Forum 201 Pacific Highway
ST LEONARDS
2065
Australia
cisco.com
 Think before you print.
This email may contain confidential and privileged material for the sole use of the intended recipient. Any review, use, distribution or disclosure by others is strictly prohibited. If you are not the intended recipient (or authorized to receive for the recipient), please contact the sender by reply email and delete all copies of this message.

From: Matthew Putland [mailto:matthew.putland@mediaaccess.org.au]
Sent: Wednesday, 9 November 2016 11:19 AM
To: w3c-wai-ig@w3.org
Subject: RE: How 1.4.4 Resize text applies when mobile templates kick in


Ø  I am in agreement that we need to define some requirements around resolution as this is a huge factor that is currently a hole which leads to different results based on what resolution was used for testing.

Yes, I’d love for this to be more clearly defined either as a note or within WCAG 2.1, as 1.4.4 Resize text just isn’t clear enough. If lower resolutions will trigger a 1.4.4 Resize text fail and higher resolutions will not, then issues could potentially be missed in an accessibility audit.  If a mobile template that omits content kicks in only after 200% browser zoom then it won’t be a problem with 1.4.4 Resize text as it stands currently, but accessibility auditors and developers do need to know which resolutions to test.

Question is, what resolution would we test to? Would testing the smallest-width resolution that’s still in use be chosen, like 1024x768? Or should we go with more popular resolutions like 1366x768? Is there a better solution to this problem anyway?

Cheers,

Matthew Putland
Senior Analyst, Digital Accessibility | Media Access Australia
61 Kitchener Avenue, Victoria Park WA 6100
Tel: 08 9311 8230 (direct) 02 9212 6242 (main) Mobile: 0431 924 288 Web: www.mediaaccess.org.au<http://www.mediaaccess.org.au/>

My working hours are from 11am-7:30pm AEST (8am-4:30pm AWST).

Media Access Australia<http://www.mediaaccess.org.au/> - inclusion through technology and Access iQ®<http://www.accessiq.org/> - creating a web without limits. Follow us on Twitter @mediaaccessaus<https://twitter.com/mediaaccessaus> @AccessiQ<https://twitter.com/accessiq>


From: Jonathan Avila [mailto:jon.avila@ssbbartgroup.com]
Sent: Wednesday, 9 November 2016 4:40 AM
To: WAI Interest Group <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: RE: How 1.4.4 Resize text applies when mobile templates kick in


Ø  A related matter for me is which width needs to be tested for the 200% resize with responsive design. Our designers have noted that on desktop broswer widths of 320px, zooming up to 200% causes truncation of text which is impossible to fully reveal, even with horizontal scrolling. I would suggest that shrinking a desktop browser down to a width of 320 is not an equivalent test to zooming a mobile browser with a native width of 320 to 200%

I wouldn’t think about this as equivalent to testing a mobile browser to 200% as mobile browsers support pinch zoom which would cause horizontal scrolling on responsive sites on mobile.  I would look at this issue as a desktop issue for people with low vision.  That is at 800x600 resolution on my desktop when I zoom to 200% or don’t zoom I may trigger a breakpoint and thus don’t end up with horizontal scrolling.  At 200% of 800x600 the smallest viewport width would be 400px.  The challenge seems to be that user agents don’t allow users with low vision to zoom in without causing the viewport width to shrink.  I am in agreement that we need to define some requirements around resolution as this is a huge factor that is currently a hole which leads to different results based on what resolution was used for testing.

Jonathan

Jonathan Avila
Chief Accessibility Officer
SSB BART Group
jon.avila@ssbbartgroup.com<mailto:jon.avila@ssbbartgroup.com>
703.637.8957 (Office)

Visit us online: Website<http://www.ssbbartgroup.com/> | Twitter<https://twitter.com/SSBBARTGroup> | Facebook<https://www.facebook.com/ssbbartgroup> | Linkedin<https://www.linkedin.com/company/355266?trk=tyah> | Blog<http://www.ssbbartgroup.com/blog/>
Join SSB at Accessing Higher Ground This Month!<http://www.ssbbartgroup.com/blog/join-ssb-accessing-higher-ground-month/>

The information contained in this transmission may be attorney privileged and/or confidential information intended for the use of the individual or entity named above. If the reader of this message is not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this communication is strictly prohibited.

From: Michael Gower [mailto:michael.gower@ca.ibm.com]
Sent: Thursday, November 03, 2016 11:01 AM
To: Phill Jenkins
Cc: WAI Interest Group
Subject: RE: How 1.4.4 Resize text applies when mobile templates kick in

I encounter many organizations that offer a significantly reduced set of information/functionality on their mobile site.
A case in point would be bcferries.com, which has a very rich corporate portal on the desktop which they reduce to a simple mobile site. This mobile version only covers current conditions at each of their terminals. At one point, this mobile site automatically appeared when one went to the main url, I assume based on media queries. It looks like BC Ferries has now elected NOT to cause their mobile site to appear automatically. The user must directly select a "mobile device" link to trigger the simplified information.

wikipedia.org is an example of a site that does alter content based on media. If you compare the same article on a laptop versus mobile, on the latter the entire left nav area is omitted, meaning the mobile user loses out on content and functionality. However, It includes a "Desktop" link at the bottom of the page that offers the full content of the desktop experience on the mobile device.

So, I'm encountering reduced content sets on mobile sites, but I'm assuming as long as they offer an ability to also get to the full site version. It sounds like the WG feeling is that if they don't offer a method to get to the full content, they would fail.

A related matter for me is which width needs to be tested for the 200% resize with responsive design. Our designers have noted that on desktop broswer widths of 320px, zooming up to 200% causes truncation of text which is impossible to fully reveal, even with horizontal scrolling. I would suggest that shrinking a desktop browser down to a width of 320 is not an equivalent test to zooming a mobile browser with a native width of 320 to 200% -- and testing bears that out. However, the point the design made is that he's uncertain at which widths he's supposed to confirm the desktop meets 1.4.4. He demonstrated on several flagship accessibility websites which use responsive design, that the sites fail resize when the browser window is taken down to a reduced width. So his question is, what is the minimum browser desktop width he needs to test to confirm that 1.4.4 is properly being met.

Michael Gower
IBM Accessibility
Research

1803 Douglas Street, Victoria, BC  V8T 5C3
gowerm@ca.ibm.com<mailto:gowerm@ca.ibm.com>
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:        "Phill Jenkins" <pjenkins@us.ibm.com<mailto:pjenkins@us.ibm.com>>
To:        WAI Interest Group <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Date:        2016-11-02 10:22 AM
Subject:        RE: How 1.4.4 Resize text applies when mobile templates kick in
________________________________



"Often the mobile/tablet version of websites do not contain the same content as the desktop version."

Can you give some example?

I've seen complex grids turn into card views as a result of narrowing the browser width (not zoom) on a desktop, all the information, but formatted very differently.
My interpretation of "without loss of content or functionality" does not include exact same format, or exact same relative place of information.  We should encourage reflow of format and responsive design in my opinion.

and a question for the group:  if we interpret that 1.4.4 must keep all the information in the same relative place, then keeping all that information in complex grid formats (e.g. data tables) will require left-right scrolling.

Usually responsive design keeps all the information and all the functionality.  However, there are examples of only have one search instead of two, or only one set of footer links, or you have to really scroll down to find all the sections, of there is no longer the sub menus requiring a person to select a menu item to determine its sub menu - is that a loss of functionality - no in my opinion because it still requires one and only one user interaction,  We need more specific examples to better discuss this than general statements.
___________
Regards,
Phill Jenkins
pjenkins@us.ibm.com<mailto:pjenkins@us.ibm.com>





From:        "Beranek, Nicholas" <Nicholas.Beranek@capitalone.com<mailto:Nicholas.Beranek@capitalone.com>>
To:        Matthew Putland <matthew.putland@mediaaccess.org.au<mailto:matthew.putland@mediaaccess.org.au>>, WAI Interest Group <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Date:        11/02/2016 11:06 AM
Subject:        RE: How 1.4.4 Resize text applies when mobile templates kick in
________________________________



Hey Matthew,

The SC description says it right there: “without loss of content or functionality”. Therefore, if you zoom into the browser to 200%, you would expect everything to still be there, albeit perhaps in a different format.

With that, let’s think about possible solutions for when a user has a lower resolution. One solution would be to detect if the user has zoomed into the page. Unfortunately, there doesn’t appear to be a reliable method of doing this. Detect-zoom got very close, but browsers have modified how they handle zoom (e.g. Firefox changes the devicePixelRatio value on manual zoom so you can’t differentiate between zoom mode and a retina device). Here’s the library for more information: https://github.com/tombigel/detect-zoom


We do the best we can. You can try Detect-zoom and see how well that works out for you. You can also check the pixel ratio and set up CSS media queries to account for that and try to sift out mobile devices.

I hope this helps,

Nick Beranek
Capital One

From: Matthew Putland [mailto:matthew.putland@mediaaccess.org.au]
Sent: Tuesday, November 01, 2016 8:59 PM
To: WAI Interest Group <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Subject: How 1.4.4 Resize text applies when mobile templates kick in

Hi WAI Interest Group,

Apologies in advance if this has been asked before.

1.4.4 Resize text states that:
1.4.4<http://www.w3.org/TR/2008/REC-WCAG20-20081211/#visual-audio-contrast-scale>Resize text: Except for captions<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#captionsdef>and images of text<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#images-of-textdef>, text<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#textdef>can be resized without assistive technology<https://www.w3.org/TR/UNDERSTANDING-WCAG20/visual-audio-contrast-scale.html#atdef> up to 200 percent without loss of content or functionality.

I often find on many desktop websites that a mobile/tablet website template will kick in at 175%/200% browser zoom, which I’m guessing is due to the width of the page becoming smaller and so the webpage assumes a mobile or tablet template. Often the mobile/tablet version of websites do not contain the same content as the desktop version, preventing people with low-vision from reading the content at a level that is comfortable for them.

Sometimes content is purposely omitted on the mobile version because it doesn’t work too well on a mobile device, like perhaps an embedded twitter feed. If you’re using browser zoom to read on a twitter feed, and then it disappears, how frustrating is that!? I’ve seen many mobile views put content into expandable menu’s, such as the main navigation bar on a desktop website converting into a hamburger menu on the mobile version, which I view as being perfectly fine as long as the button/menu passes the rest of WCAG 2.0.

What should I be recommending to developers to try to resolve this issue? Is it as simple as stating that all content on desktop should also be available on mobile in some way? Can it be resolved just by ensuring that the mobile template doesn’t kick in until after 200% zoom? – but I’ve noticed that different screen resolutions will cause the responsive design to appear at different zoom levels. The smaller your resolution, the less browser zoom before the mobile template kicks in.

1.4.4 Resize text doesn’t really address this issue exactly, and I’m wondering if WCAG 2.1 will?

Cheers,

Matthew Putland
Senior Analyst, Digital Accessibility | Media Access Australia
61 Kitchener Avenue, Victoria Park WA 6100
Tel: 08 9311 8230 (direct) 02 9212 6242 (main) Mobile: 0431 924 288 Web: www.mediaaccess.org.au<http://www.mediaaccess.org.au/>

My working hours are from 11am-7:30pm AEST (8am-4:30pm AWST).

Media Access Australia<http://www.mediaaccess.org.au/>- inclusion through technology and Access iQ®<http://www.accessiq.org/>- creating a web without limits. Follow us on Twitter @mediaaccessaus<https://twitter.com/mediaaccessaus>@AccessiQ<https://twitter.com/accessiq>

[We launched Affordable Access @ ACCANECT www.affordableaccess.com.au]<http://www.affordableaccess.com.au/>


From: David MacDonald [mailto:david100@sympatico.ca]
Sent: Wednesday, 2 November 2016 12:31 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>>
Cc: Andy Keyworth <akeyworth@tbase.com<mailto:akeyworth@tbase.com>>; WAI Interest Group <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>; Mohammad, Ashraf <Ashraf.Mohammad@sabre.com<mailto:Ashraf.Mohammad@sabre.com>>
Subject: Re: Is the <form> tag mandatory for 2.4.5?

+1

Cheers,
David MacDonald

CanAdaptSolutions Inc.
Tel:  613.235.4902
LinkedIn <http://www.linkedin.com/in/davidmacdonald100>
twitter.com/davidmacd<http://twitter.com/davidmacd>
GitHub<https://github.com/DavidMacDonald>
www.Can-Adapt.com<http://www.can-adapt.com/>

 Adapting the web to all users
           Including those with disabilities

If you are not the intended recipient, please review our privacy policy<http://www.davidmacd.com/disclaimer.html>

On Thu, Oct 27, 2016 at 1:48 PM, Andrew Kirkpatrick <akirkpat@adobe.com<mailto:akirkpat@adobe.com>> wrote:
Except that then you wind up with massive entanglement of issues. If you have a label missing on a field you might fail 2.4.5, or if you have alt missing on an input of type image for a search button you might fail 2.4.5.

I would say that you can pass 2.4.5 by providing multiple ways (e.g. global navigation, sitemap, search) and users with disabilities of all sorts will be able to utilize the multiple ways if each way is correctly implemented. If the form for search is missing a label or has some other issue, some users will be affected but not all types, so the error should be identified for what it is – a missing label or whatever it is – and the page would then still pass 2.4.5 but have a 4.1.2/1.1.1/etc issue.

AWK

Andrew,

I understand your point. If I can stretch my argument a bit, it would be that:

1.     I did not mean to imply multiple ways to navigate a page, but to locate pages/sought-for content.

2.     IF a search box as I described is presented as evidence of a way to meet 2.4.5, and

3.     IF the search box does not use <form> tags, which may impact screen reader identification,

4.     THEN an argument may be made that the search box does not fully meet the requirements for 2.4.5, at least on its own.

Andy Keyworth
Online Accessibility and Product Development Specialist
Certified ADA Coordinator
T-Base Communications
Phone: 613-236-0866<tel:613-236-0866>|Toll free: 1-800-563-0668 x1256<tel:1-800-563-0668%20x1256>
www.tbase.com<http://www.tbase.com/>|Ogdensburg, NY | Ottawa, ON
For accessibility stories to inform & inspire, follow #tbasestories<http://tbase.com/blog-tags/t-base-stories>!
SIMPLIFYING ACCESSIBLE COMMUNICATIONS.TM

This email may contain information that is privileged and confidential. If you have received this communication in error, please delete this email message immediately.

From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com]
Sent: October-27-16 1:27 PM
To: Andy Keyworth; WAI Interest Group
Cc: Mohammad, Ashraf
Subject: Re: Is the <form> tag mandatory?

Andy,
I would disagree that 2.4.5 applies to a form on a page since 2.4.5 reads:

Multiple Ways: More than one way is available to locate a Web page<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-mult-loc.html#webpagedef> within a set of Web pages<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-mult-loc.html#set-of-web-pagesdef>except where the Web Page is the result of, or a step in, a process<http://www.w3.org/TR/UNDERSTANDING-WCAG20/navigation-mechanisms-mult-loc.html#processdef>. (Level AA)

You seem to be describing the need for multiple ways to navigate a single page, but 2.4.5 only applies to the location of a page within a set.

Thanks,
AWK

Andrew Kirkpatrick
Group Product Manager, Standards and Accessibility
Adobe

akirkpat@adobe.com<mailto:akirkpat@adobe.com>
http://twitter.com/awkawk


From: Andy Keyworth <akeyworth@tbase.com<mailto:akeyworth@tbase.com>>
Date: Thursday, October 27, 2016 at 13:03
To: WAI-IG <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Cc: "Mohammad, Ashraf" <Ashraf.Mohammad@sabre.com<mailto:Ashraf.Mohammad@sabre.com>>
Subject: RE: Is the <form> tag mandatory?
Resent-From: WAI-IG <w3c-wai-ig@w3.org<mailto:w3c-wai-ig@w3.org>>
Resent-Date: Thursday, October 27, 2016 at 13:04

In auditing websites, I’ve noticed a real impact on screen reader usability when the <form>…</form> is absent. This has been most apparent on pages where there is a prominent form in the content which wraps using the “<form>” tags, but also a search box in the page header which does not do the same. In these cases, the search box function is noticeably less easy to find and use.

I would argue this can have an impact on whether the site can claim to meet WCAG 2.0 Success Criterion 2.4.5, “Multiple Ways”.

Andy Keyworth
Online Accessibility and Product Development Specialist
Certified ADA Coordinator
T-Base Communications
Phone: 613-236-0866<tel:613-236-0866>|Toll free: 1-800-563-0668 x1256<tel:1-800-563-0668%20x1256>
www.tbase.com<http://www.tbase.com/>|Ogdensburg, NY | Ottawa, ON
For accessibility stories to inform & inspire, follow #tbasestories<http://tbase.com/blog-tags/t-base-stories>!
SIMPLIFYING ACCESSIBLE COMMUNICATIONS.TM

This email may contain information that is privileged and confidential. If you have received this communication in error, please delete this email message immediately.

From:chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>[mailto:chaals@yandex-team.ru]
Sent: October-27-16 12:44 PM
To: Christophe Strobbe; Steve Faulkner
Cc: WAI Interest Group
Subject: Re: Is the <form> tag mandatory?

Because you don't *need* a form tag to make it possible to fill in some input elements and send the data - assuming javascript is running properly, which is not always the case but happens most of the time.

You can't work out what is in the particular form being submitted if you don't have a form tag, but then you have to have a specialised browser extension or a particularly friendly developer who made that possible or you can't do that anyway in practice.

The point about the tags being mandatory is that if you want the DOM to record a form, you need both tags to go into the parser. Whereas for example you can leave out both the start and end tags for tbody or body and it will still create the elements…


27.10.2016, 18:37, "Christophe Strobbe" <strobbe@hdm-stuttgart.de<mailto:strobbe@hdm-stuttgart.de>>:
Hi Steve,

On 27/10/2016 17:56, Steve Faulkner wrote:

On 27 October 2016 at 16:42, Christophe Strobbe <strobbe@hdm-stuttgart.de<mailto:strobbe@hdm-stuttgart.de>> wrote:
According to the HTML5 specification, the both the start tag and the end
tag of the form element are mandatory:
<https://www.w3.org/TR/html5/forms.html#the-form-element>.

Hi Christophe, they are not mandatory to use, but if you do have a start tag <form> you must have an end tag </form>

How does that rhyme with the statement "Neither tag is omissible." in the HTML5.0 specification?
(You can find the same statement about elements such as label, legend, textarea, header, footer, main, aside, section, nav and figure. For example, how would you know that something is a legend when there is neither a start tag nor an end tag?)
The omission of tags follows certain rules: <https://www.w3.org/TR/html5/syntax.html#optional-tags><https://www.w3.org/TR/html5/syntax.html#optional-tags>.

Best regards,

Christophe


Ashraf, use of the form element is not a requirement for accessibility. If the interaction you have designed does not need a form element to function then that is fine.

--

Regards

SteveF
Current Standards Work @W3C<http://www.paciellogroup.com/blog/2015/03/current-standards-work-at-w3c/>


--
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749<tel:%2B49%20711%208923%202749>

“I drink tea and I know things.”
Falsely attributed to Christophe Lannister.


--
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru<mailto:chaals@yandex-team.ru>- - - Find more at http://yandex.com<http://yandex.com/>



________________________________

The information contained in this e-mail is confidential and/or proprietary to Capital One and/or its affiliates and may only be used solely in performance of work or services for Capital One. The information transmitted herewith is intended only for use by the individual or entity to which it is addressed. If the reader of this message is not the intended recipient, you are hereby notified that any review, retransmission, dissemination, distribution, copying or other use of, or taking of any action in reliance upon this information is strictly prohibited. If you have received this communication in error, please contact the sender and delete the material from your computer.