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
voice: (250) 220-1146 * cel: (250) 661-0098 *  fax: (250) 220-8034



From:   "Phill Jenkins" <pjenkins@us.ibm.com>
To:     WAI Interest Group <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





From:        "Beranek, Nicholas" <Nicholas.Beranek@capitalone.com>
To:        Matthew Putland <matthew.putland@mediaaccess.org.au>, WAI 
Interest Group <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>
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.4Resize text: Except for captionsand images of text, textcan be 
resized without assistive technology 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
 
My working hours are from 11am-7:30pm AEST (8am-4:30pm AWST).
 
Media Access Australia- inclusion through technology and Access iQ®- 
creating a web without limits. Follow us on Twitter @mediaaccessaus
@AccessiQ
 

 
 
From: David MacDonald [mailto:david100@sympatico.ca] 
Sent: Wednesday, 2 November 2016 12:31 AM
To: Andrew Kirkpatrick <akirkpat@adobe.com>
Cc: Andy Keyworth <akeyworth@tbase.com>; WAI Interest Group <
w3c-wai-ig@w3.org>; Mohammad, Ashraf <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 
twitter.com/davidmacd
GitHub
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
 
On Thu, Oct 27, 2016 at 1:48 PM, Andrew Kirkpatrick <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| Toll free: 1-800-563-0668 x1256
www.tbase.com|Ogdensburg, NY | Ottawa, ON
For accessibility stories to inform & inspire, follow #tbasestories!
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 within 
a set of Web pagesexcept where the Web Page is the result of, or a step 
in, a process. (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
http://twitter.com/awkawk

 
From: Andy Keyworth <akeyworth@tbase.com>
Date: Thursday, October 27, 2016 at 13:03
To: WAI-IG <w3c-wai-ig@w3.org>
Cc: "Mohammad, Ashraf" <Ashraf.Mohammad@sabre.com>
Subject: RE: Is the <form> tag mandatory?
Resent-From: WAI-IG <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| Toll free: 1-800-563-0668 x1256
www.tbase.com|Ogdensburg, NY | Ottawa, ON
For accessibility stories to inform & inspire, follow #tbasestories!
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] 
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>:
Hi Steve,

On 27/10/2016 17:56, Steve Faulkner wrote:
 
On 27 October 2016 at 16:42, Christophe Strobbe <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>.

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
 
 
-- 
Christophe Strobbe
Akademischer Mitarbeiter
Responsive Media Experience Research Group (REMEX)
Hochschule der Medien
Nobelstraße 10
70569 Stuttgart
Tel. +49 711 8923 2749
 
“I drink tea and I know things.” 
Falsely attributed to Christophe Lannister.
 
 
-- 
Charles McCathie Nevile - web standards - CTO Office, Yandex
chaals@yandex-team.ru- - - Find more at 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.