Note from March 1st call

The TF call today was all about Reflow, the challenges of meeting it, and explaining the SC to developers.

Attendance (16):  Alastair Campbell, Bruce Bailey, Brett Humphrey, Dan Bjorge, David Cox, Duff Johnson, Francis Storr, Giacomo Petri, Gundula Niemann, Laura Oakly, Mike Gifford, Mike Gower, Patrick Lauke, Scott O’Hara, Stephen James, and one other (my apologies).

Detailed notes are at bottom of the Reflow scratchpad<https://docs.google.com/document/d/1NhXS0Gfdsgl67pIhK0BYmayTq_v45CJMP0Ve36Uui3Q/edit#heading=h.4i34heg5js16>.  Please be encouraged to make corrections or add comments.  We will be return to reflow in the future.  Please continue thinking of examples where content should pass (perhaps because of an exception), and content that should fail the SC.

Brett Humphrey started today’s conversation by shared his perspective as a seasoned developer who has low vision, and discussion flowed from there.

As part of the discussion, Alastair provided some background about SC 1.4.10 Reflow<https://www.w3.org/TR/WCAG22/#reflow>.  This is the only part of the longer notes that I am choosing to excerpt here.


  *   The requirement originated from work of the Low Vision Accessibility Task Force<https://www.w3.org/WAI/GL/task-forces/low-vision-a11y-tf/>, largely in response to SC 1.4.4 Resize Text<https://www.w3.org/TR/WCAG22/#resize-text> (200% zooming) not being of sufficient utility for many people with low vision.
  *   LV TF concluded that for browser zoom (alone) to be sufficient, support to 1000% would be necessary.  That’s not feasible for most webpages, and so the TF focused on reflow.
  *   AG WG included web applications as the reflow SC matured for WCAG 2.1.
  *   The numbers chosen, when they were chosen, were reasonable.  For example, 320 is the width of a bunch of 2010's Android devices.
  *   Nowadays, some desktop UA can’t emulate 320x256.  (As the SC note suggests, one can test by using a 1280x1024 browser window with zoom at 400%.)
  *   Our TF discussions have mostly been about scoping “content” in the context of 1.4.10, and the exception.

Next week (March 8th) we are back to our standing agenda<https://github.com/w3c/wcag/wiki/Meeting-minutes-index#standing-agenda>.

  1.  Review ‘For discussion’ items.
  2.  Review ‘Drafted’ items (30 min), either:

  *   move back to In progress, with more work to do;
  *   move to Ready for approval, if there is general agreement the issue is sufficiently resolved; or
  *   leave in Drafted, if discussion was not concluded satisfactorily.

  1.  Review ‘To do’.
  2.  Time permitting, items of interest to participants, including open discussions.

Duff Johnson proposes the following open discussion for TF consideration:



A few of the PDF Association’s Failure Techniques are specific to PDF/UA-1, and are not WCAG failures. One example is PDF/UA-1 prohibition on skipped heading levels.



We [PDF A] could include a general statement acknowledging this fact on the front-end of our site… or we could include specific mention at the level of the individual technique…. or both.  Or something else.



The PDF Accessibility WG would like some input on how we should present such cases, as we’d prefer to minimize any speedbumps on the way to the AGWG hoped-for-formal acceptance of our PDF Techniques as WCAG Techniques.