- From: Alastair Campbell <acampbell@nomensa.com>
- Date: Wed, 15 Nov 2017 08:52:39 +0000
- To: "Repsher, Stephen J" <stephen.j.repsher@boeing.com>, Andrew Kirkpatrick <akirkpat@adobe.com>, WCAG <w3c-wai-gl@w3.org>
- Message-ID: <3861D165-8182-4333-8F97-680F5905F7AF@nomensa.com>
I’ll repeat my github comment for the benefit of those not on that thread: If a site has to provide the view required, they have to provide the 320px breakpoint. In that case you’ve done 90% of the CSS work to provide a fully responsive site. The effort to add the in between points is negligible and gets you a better UX on millions of devices. We’ve had comments (see the thread in Gregg’s comment) that we’re requiring responsive design (which is mostly true in practice) and that is too much to ask. The only relevant get-out method is to provide a completely separate mobile site, but even that is unlikely because every example of that I’ve seen does not provide all the content and features. So either we have this ‘line in the sand’ that is relatively easy to understand and test, or we get nothing. Additionally to the github comment: We could add another point of testing (I’d suggest a multiple of 320px, such as 640), but given the practicalities from the dev side I think that’s pointless. -Alastair From: "Repsher, Stephen J" -1 As I expressed on the call, survey, and GitHub, I cannot live with this new version. It has been communicated over and over again that zooming without reflow results in a huge amount of extra work for the low vision user, and this new proposal simply does not require responsive reflow. Furthermore, we are still expecting to tout this as a low vision benefit for approximately 400% zoom, yet zoom was removed as the mechanism so there’s no guarantee the user can even achieve this without faking their viewport width. Going along with just reflow, I proposed text that would in fact guarantee responsive reflow, and the concern was raised over the burden on testers to guarantee conformance at every pixel width above 320. In response, I was fine with compromising to a couple extra test widths to fill out a curve with a constant zoom factor. So if a median desktop of 1280px was assumed and thus 320 is at 4x, then the factor for 3 test widths would be 4^(1/3) = 1.59. This corresponds to test widths of 806, 508, and 320, and I rounded off the latter two to 800 and 500 but anything close would be acceptable. So the SC would just become: Reflow: Content can be presented at widths equivalent to 320, 500, and 800 CSS pixels without loss of information or functionality, and without requiring scrolling in two dimensions, except for parts of the content which require two-dimensional layout for usage or meaning. There seemed to be many folks who could live with this approach, and I do not think it was considered fairly. I’d welcome substantiated claims as to why this is still so burdensome. And although it still doesn’t truly guarantee a fully reflowing design, it does help low vision folks to find 1 of 3 spots at their comfortable zoom level that does not come with the extra burden of scrolling in 2 dimensions. Steve From: Andrew Kirkpatrick [mailto:akirkpat@adobe.com] Sent: Tuesday, November 14, 2017 12:25 PM To: WCAG <w3c-wai-gl@w3.org> Subject: CFC - Change Zoom Content to Reflow Content and change SC text Importance: High Call For Consensus — ends Thursday November 16th at 12:30pm Boston time. The Working Group has discussed a change to Zoom Content SC. The specific changes are detailed in this survey: https://www.w3.org/2002/09/wbs/35422/ZoomContent_20171109/results Call minutes: https://www.w3.org/2017/11/14-ag-minutes.html If you have concerns about this proposed consensus position that have not been discussed already and feel that those concerns result in you “not being able to live with” this decision, please let the group know before the CfC deadline. Thanks, AWK Andrew Kirkpatrick Group Product Manager, Accessibility Adobe akirkpat@adobe.com<mailto:akirkpat@adobe.com> http://twitter.com/awkawk<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Ftwitter.com%2Fawkawk&data=02%7C01%7C%7C54093524ef264326424008d51cd66c05%7Cfa7b1b5a7b34438794aed2c178decee1%7C0%7C0%7C636446629619786436&sdata=c5UP0xiniJIppvd6Esu1XA%2FbX1ykpABkhgCCmBp%2Fht8%3D&reserved=0>
Received on Wednesday, 15 November 2017 08:53:07 UTC