- 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>
Hello, 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 without..." 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. P -- Patrick H. Lauke -- Senior Accessibility Engineer The Paciello Group https://www.paciellogroup.com 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