W3C home > Mailing lists > Public > public-agwg-comments@w3.org > August 2017

WCAG 2.1 public comment (The Paciello Group)

From: Patrick H. Lauke <plauke@paciellogroup.com>
Date: Tue, 22 Aug 2017 20:41:16 +0100
To: public-agwg-comments@w3.org
Cc: Leonie Watson <LWatson@PacielloGroup.com>, Ian Pouncey <ipouncey@paciellogroup.com>, Steve Faulkner <sfaulkner@paciellogroup.com>
Message-ID: <c353929a-7ed8-da6a-47eb-e747e10a4c4d@paciellogroup.com>

find below a few collated comments on behalf of The Paciello Group on 
some of the new SCs/changes from the last working drafts (with apologies 
for not sending the ones from the previous one sooner/before the latest 
WD dropped).

SC 1.4.10: it seems the normative part of the SC is missing the actual 
core idea here of allowing users to zoom content sufficiently. While the 
320 CSS px size is good and testable, this SC could be nominally passed 
if the content was zoomed to 101% (as long as content fits in 320 CSS 
px). The current normative wording only guarantees that content doesn't 
start creating horizontal scrollbars in viewports that are 320 CSS px 
wide, not whether or not that content is readable or if the user was in 
fact able to zoom at all up to that point. Suggest that the idea of 
allowing up to 400% zoom, coupled with minimum viewport width, would 
better serve the original idea/outcome. "Content can be zoomed up to 
400% and it will still fit into a viewport of 320 CSS pixels width 

SC: 2.6.10 The SC itself is fine, but the definition of "essential" is 
weak - the exceptions here are not strong enough. In all cases, an 
argument can be made that those examples quoted as exemptions could in 
fact be made to work in either orientation (e.g. in the case of the 
piano application, the piano keys could be split into two horizontal 
rows of keys when in portrait mode; the cheque example could allow for 
the image of the cheque to be zoomable/pannable in portrait mode). The 
only hurdle here is that yes, it would mean more work on the part of 
designers/developers to cater to a different aspect ratio/orientation, 
but it's not necessarily intrinsically *essential* to the 
content/activity to be shown in that particular way. So the exceptions 
here are mostly due to the fact that it would put undue (?) burden on 
developers? It may also be far too easy, looking at current wording, for 
a designer/developer to make something that only works in one 
orientation because they designed it that way and then claim that it's 
essential that it only work in that mode.
Also, term "essential" is too generic. Suggest the term defined should 
be a lot more specific, like "essential orientation". Lastly, since the 
normative SC text relies on on the definition of "essential", assuming 
that this makes the wording of the definition also normative - and for 
this reason, extra care should be taken to make sure it's not "handwavy" 
with regards to the exemptions (as noted above).

SC 3.2.6: we feel that the normative SC text here is far too 
tech-specific, despite the attempt to use more generic/made-up names 
like "up-event". The SC text should really be "ensure that users do not 
accidentally activate...". Then, in the understanding document, 
elaborate about common situations where accidental activation can 
happen, e.g. on touchscreen, if scripting reacts to the finger being 
placed on the screen (the "down-event", i.e. "touchstart" or 
"pointerdown"), this will result in accidental triggering, and that the 
simplest remedy here is to react to the "up-event" (i.e. "touchend" or 
"pointerup"). The same for mouse interactions (reacting to "mouseup" or 
indeed "click" rather than "mousedown"). Then mention alternatives where 
users can potentially set this via configuration/settings.

SC 5.1.2: it's worth being careful that screen size is not the only 
variable that could trigger a different version/view of the same page. 
One example would be feature/API detection (i.e. JavaScript that checks 
for the presence of touch-event support, and from that infers - wrongly 
perhaps - that the user is on a mobile device). There are also further 
media queries that can be used by authors to trigger alternative 
views/layouts. The wording, therefore, could do with being more 
generalised/not focused only on screen size. If the definition were to 
be expanded to cover all sorts of factors outside of the user's direct 
control, need to be careful that this wouldn't turn accidentally into a 
508 style "must work without JavaScript or CSS" as the setting (whether 
JS is turned on or off) may arguably also be "outside of the user's 
control" in certain environments/situations, though.

Patrick H. Lauke
Senior Accessibility Engineer
The Paciello Group
A VFO™ Company http://www.vfo-group.com/
This message is intended to be confidential and may be legally 
privileged. It is intended solely for the addressee. If you are not the 
intended recipient, please delete this message from your system and 
notify us immediately. Any disclosure, copying, distribution or action 
taken or omitted to be taken by an unintended recipient in reliance on 
this message is prohibited and may be unlawful.
Received on Tuesday, 22 August 2017 19:41:39 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 18:53:04 UTC