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



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



________________________________________________________

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.