Meeting minutes
<maryjom> genda+ Announcements
Announcements
<Chuck> Thank you so much Bruce for scribing!
alastairc chair of AG WG joining today
<maryjom> https://
maryjom: Michael Cooper working hard on back end so we have a much updated version
… this is NOT github.io so beware of that
… this Netlify version reflects preview builds going forward
<maryjom> Remaining formatting issues: w3c/
maryjom: still some formatting issues , but better user experience all around
… please add to issue 147 if you catch formatting issues not reflected in that thread
… much thanks to editors and MC -- really looking better
mitch11: Nelify not available from GitHub? Can we add links from wiki and elsewhere
<ShawnT> it should work once the change gets merged?
maryjom: Yes, but expectation is that netlify version will be linked up
Project standup and planning
<maryjom> https://
maryjom: We are working this week on reflow, next week pointing gestures
… We might also discuss NEXT week how much we want / need to focus on Understanding
… please do look at project plan
… soon after that we will start on the stable SC new with 2.2
… also there is a command-line oriented discussion happening, please see wiki for information for joining
Survey results and discussion on SC 1.4.10 Reflow
[Mary Jo screen shares from project board]
[correction, sharing from survey results]
maryjom: Phil noted in survey that hard to digest, and suggest some example at representative distances
<maryjom> Proposal in the issue: w3c/
Fernando also notes in survey that difficult to parse, and provided a proposal.
… from survey, note 2 conflates two different concept. Gregg and Mary Jo have similar concern.
<maryjom> Survey results: https://
maryjom: GreggV had some technical responses in survey, for example that cell phone and monitors both held at arms length...
… also Gregg asserts software should not be required to reflow. There are some parking lot item, but wont get to that today.
… GreggV also argued that CSS *is* device independent -- so we should stick with that. Gregg?
GreggV: From recent conversation, we can't just substitute angle of view, consider content for eBook -- author has no idea what content displayed on...
… so unit we use must have device independent measure.
<maryjom> From Thorsten's comment about pixel size: https://
maryjom: We had some editorial input and a resource that Thorsten provided.
… another reasonable comment from survey is to use mm as well as pixel examples.
… Additional suggestions for table of examples / conversions is good one.
maryjom: I do want to tackle all the closed functional issues in single blocks, since it is a cognitively dense topic.
mitch11: I will suggest we split difference -- that we focus on "up close" products first, since seems simpler use cases
maryjom: Agree, want to address more typical non-web documents and mobile first.
SamO: Device independent pixel as a concept makes sense, but is "apply as best as possible" enough or can we be less prescriptive?
… The reflow concept we have consensus, but the device independent pixel is more controversial.
GreggVan: The CSS pixel is a device independent pixel. Are they not both angle of view?
<alastairc> Except if the platform doesn't use CSS
alastairc: One of the hardware manufacturers has started using the term , makes more sense in that context. Need to be careful with endorsing one over the other.
GreggVan: If they are the same unit of measure, why not stick with CSS pixel?
mikepluke: It is very confusing to reference CSS in context on non-web technologies.
GreggVan: Might we just note that they are equivalent? Confusing to have defined term approach though.
<Zakim> Chuck, you wanted to advise that we have a queue
mitch11: If they are both defined as viewing angle, but that is more how they are derived. The normative definition for CSS pixel is a little problematic because it is so tied to CSS.
… From that perspective there is a conflict if not contradiction.
Chuck: Please mind the queue. ..
… If we go beyond what is normative in WCAG that risks going beyond charter. Do I recall from previous conversation that we wanted to ask AGWG to revisit pixel definition?
SamO: There are already requirement that use similar angle of view for closed products. To add an additional one, introduces potential conflict.
<Chuck> Regarding queue, I am not calling out any specific individual. My intent is to remind all participants that we do have a queue. So no specific names or individuals.
SamO: Also a +1 to Phil and Mike that having "CSS Pixel" in non-web reference really causes people to assume the SC is just not relevant.
GreggVan: In some places CSS pixel is defined as 1/72 or 1/96 inch so there are example of physical measure...
… but if with other work we have reference to CSS pixel. We could just address as note.
<Zakim> alastairc, you wanted to ask if a little history would help?
GreggVan: For example, Biden is president of U.S. Biden is also president of United States.
alastairc: I will try and give some historical perspective. In 2000 we had longish period of understood default baseline with 1024 and CRTs and DPI.
… Starting around 2008 web technology started facilitated reflow -- and still things were consistent enough
… But as technology improved, around 2010, DPI resolution of mobile devices really increased, 2x 4x what we had in 2000's
… Regardless, convention was still to reference and intended viewing distance and 1024 still was a useable reference expectation...
<alastairc> https://
alastairc: Still had a smooth curve among manufactures -- responsibility for legibility and useability was with manufactures -- who were doing that
alastairc: It won't be the end of the world if reflow is not supported everywhere. EPUB has a different approach than reflow, and it works well, but it is not reflow...
… but also hardware, like TVs in doc, are not going to be rotated. So manufactures are doing their part but accessibility standards can keep up that idea.
mitch11: A screen resolution setting and platform can support accessibility and scaling. I do not think how Android addresses is really different than iOS.
<GreggVan> Closed products
<GreggVan> For closed products the content should reflow as necessary so that all content and functionality is preserved for all levels of zoom or character sizing that the closed product provides.
alastairc: I agree they are similar results. Android facilitated "reflow" in their doc a couple ways, while iOS only provided text size controls -- so it was harder to do something like reflow.
GreggVan: The closed product note currently mentions responsibility for platform. Seems like it might be simple to acknowledge platform providing zoom is providing accessibly feature even if that is not reflow per se.
SamO; My concern is that reflow as term just does not work on its face. Can we come back to this SC?
<Sam> https://
maryjom: I am not sure, since we have more than one SC which uses CSS pixel, but we might tackle those in a batch.
<Zakim> alastairc, you wanted to say that if reflow isn't applicable, the others still should be
alastairc: Reflow is definitely the trickiest one. Might be address by device independent pixel, so that could put burden on platform.
… with regard to other SC including size metric, such as Target Size, those should be less problematic because platforms again well address.
GreggVan: My thinking is shifting because there are authorities which use DPI and not viewing angle.
… We need to look at other places, maybe have in front of queue.
<maryjom> Poll: Should we use Device-independent pixel?
<olivia-hs> +1
<Mike_Pluke> +1
<FernandaBonnin> +1
<ThorstenKatzmann> +1
<BryanTrogdon> +1
<GreggVan> +1 with a note talking about how it relates to CSS pixel
<alastairc> Reflow, 2.4.11 focus-appearance, taget-size (min and enh).
<alastairc> +1
<ShawnT> +1
<Sam> For refference the fix CSS Pixel is 1/96 of an inch https://
<maryjom> +1
<Sam> +1
<mitch11> +1
maryjom: We could use term for now, and have note showing relation with CSS pixel
<ChrisLoiselle> +1 with note on CSS relationship
maryjom: We have agreement on this approach, so I will take a first draft on what that might look like.
… Homework will be for members to look for situations which might be problematic.
MaryJo asks Mitch Evans to followup?
<mitch11> w3c/
<maryjom> Mitchell's device-independent pixel: w3c/
mitch11: We have covered my comment on device in defendant pixel , and that is the hardest one
rssagent, draft minutes
<maryjom> Non-web documents, Mitch's comment: w3c/
mitch11: Okay the next one to consider would be around non-web documents
… If the document needs certain layout, responsibility lies with both agent and author, so I made a suggestion noting exception for content requiring two dimensional layout
GreggV: The proposed note is similar to allowing exception for when cant be accessible, then don't need to be accessible...
… it is circular definition. If content format does not support reflow, then it is not accessibly supported , but there is a conflict because reflow software is different than reflow content.
… for example, reflow data table is not funtional.
maryjom: Mitch is just splitting up non-web documents from non-web software.
mitch11: Agree that it varies by format type. PDF used to be example, but reflow can be supported now...
… we need to fact check what we mean by "document type" but I think that means , maybe for example , two version of EPUB...
… it hits up against fundamental alteration and similar concepts.
alastairc: PDF is an example , since image breaks reflow in PDF which otherwise supports. Canvas is a modern concept where the two-dimensional nature is essential.
… But is WCAG2ICT aimed at platforms or content authors?
<mitch11> I must drop, thanks
maryjom: Survey on survey did not have enough responses, so i will reopen.
GreggVan: Essential an only be applied if fundamental alteration. If other product, fundamental alteration cannot be provided...
… with a table, can still reflow within cell. If cannot meet with technology, then it is not accessibility support, so use something else.
maryjom: I will try to incorporate more comments into current draft.