W3C home > Mailing lists > Public > w3c-wai-ig@w3.org > October to December 2016

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

From: Phill Jenkins <pjenkins@us.ibm.com>
Date: Wed, 2 Nov 2016 11:12:09 -0600
To: WAI Interest Group <w3c-wai-ig@w3.org>
Message-Id: <OF5D9B3637.F6F56910-ON8625805F.005D6A7E-8625805F.005E8085@notes.na.collabserv.com>
"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.4 Resize text: Except for captions and images of text, text can 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
 
CanAdapt Solutions 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.






picture
(image/jpeg attachment: 01-part)

Received on Wednesday, 2 November 2016 17:12:51 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 2 November 2016 17:12:51 UTC