– DRAFT –
WCAG2ICT Task Force Teleconference

<maryjom> https://github.com/w3c/wcag2ict/wiki/Scribe-list-&-instructions

Announcements

<maryjom> Link to schedule and milestones: https://github.com/w3c/wcag2ict/wiki/Schedule-and-milestones

maryjom: progress slower than expected on Reflow
… text-based interfaces appears on track for June
… appendix on criteria problematic for closed functionality, aiming for June 30 to AGWG and publication process, leading to publishing in July; this timing might be at risk
… so we focus on remaining work items of above items; Mary Jo working with Michael on technical parts

<Chuck> I will scribe for Mitch

<maryjom> w3c/wcag2ict#44

<Chuck> mitch11: is AAA in the timeline?

<Chuck> maryjo: AAA is not in the timeline, it will have to be later. None of the regulatory standards require AAA. It will take us enough time to get A and AA done for EN 301 549.

<Chuck> mitch11: the publication process doesn't preclude going back to AGWG?

<Chuck> maryjo: It does not. It's a plan in our scope statement. People want us to address AAA. I don't think we can do that along with the current round of updates. There's a lot of AAA, and it will take a while to get through them all.

maryjom: progress board is now up to date, showing AGWG progress and current tasks in progress in our task force
… we should now concurrently work on 2.1 open issues, looking for owners for a few issues
… looking to touch base with contributors on Problematic for Closed Functionality section, between our weekly calls
… similar analysis is going on for text and command line applications
… please contribute, analysis needed
… for closed functionality

GreggVan: heads up on closed functionality, problem that all the standards have, we'll see in ANPRM from Access board but for now we're the first standard tackling
… in past many assumed closed means closed to screen readers, so app must provide own speech
… but now programmatically determinable becomes important for user groups: cognitive, voice control
… expect more work required for programmatically determinable to make things functional for more disability types

maryjom: agree it's for more than blindness

<GreggVan> +1

maryjom: this analysis not expected to cover that level of detail, would be left to another standards group, because we're not tasked with coming up with requirements
… is it enough to say that, any other considerations to be noted?
… maybe we describe the wide variety of closed functionality products, they might have a specific use case or technology in mind

Project standup and planning

Discussion on definition of Device-independent pixels

<maryjom> Issue 98 for proposing guidance for 1.4.10 Reflow: w3c/wcag2ict#98

<maryjom> Link to Mitchell’s comment on the definition: w3c/wcag2ict#98 (comment)

maryjom: we agreed previously "device independent pixel" is a better term for non-web ICT
… different platforms define the concept of DIP, with different names, e.g. density-independent pixel on Android, see issue comments for size definitions
… we may want to use those definitions when they exist says Mitchell, otherwise fall back to viewing angle
… Sam contributed: devices that don't have a definition of DIP, question of whether the angle would work in such a situation
… javila mentioned tools exist for some platforms to measure angle or size

<maryjom> Link to updated proposed definition: w3c/wcag2ict#98 (comment)

Sam: some of pixel size is antiquated because it uses a curved angle
… not everything has a definition
… use definitions when available, otherwise say there are other standards out there

maryjom: let's split the definition into cases, first of which where it's defined by the platform

<maryjom> device-independent pixel visual angle of about 0.0213 degrees

maryjom: pasting from GitHub comment

<maryjom> Note: This unit is density-independent, and distinct from actual hardware pixels present in a display. The physical size of a device-independent pixel depends on the assumed viewing distance between the user and the hardware, as well as the platform. The platform may have its own standard device-independent measurement.

<maryjom> Example: In the case of a computer screen, the assumed viewing distance is considered to be an arm's length, which is around 28 inches (71 cm). At that viewing distance, the size of a device-independent pixel is 0.26 mm.

<maryjom> Poll: Is this a sufficient definition for platforms that have a concept of device-independent pixel size?

-1

GreggVan: doesn't help beyond the term, doesn't shed light

Sam: let's be explicit about arc length calculation

maryjom: I also don't know

Sam: It's using the degrees and viewing distance, but even in CSS definition it lacks the calculation

lmiller: in the 90s we used actual pixels, now is the purpose to ensure when you zoom in the item is still viewable?

maryjom: CSS pixel is used in reflow and also in other places

<maryjom> Comment with all uses of CSS pixels in WCAG: w3c/wcag2ict#98 (comment)

maryjom: pasting earlier analysis
… it's used in reflow; target size minimum (24x24 CSS pixels; 24 CSS pixel diameter circle for distance);
… AAA target size enhanced; AAA focus appearance
… "CSS pixel" is a term in definitions
… flash thresholds don't mention pixels but are based on viewing angles
… still in the linked comment, back to platform definitions: Android calls it density independent pixel; Windows calls it device-independent pixel; TBD about iOS
… may not be measuring tools
… and closed functinality software may have limited or no capabiltiy of increasing content size
… unsure of calculation

Sam: believe it's using the arc length because old CRT curved glass
… CSS difficult or not possible for small screens, especially in combination with touch target size
… other existing requirements, e.g. digital signage, in standards like EN and 508
… size... 508 based on fixed measurement; EN uses calculation with a different viewing angle (based on capital H)

<Chuck> mitch11: referring to other standards, I like that as a fallback. We should also remember that the EN updates are looking to us for guidance.

<Chuck> mitch11: If we say "look to the other standards", it becomes circular. We should do our best and not just refer to the other standards, as they are trying to refer to us?

<Chuck> maryjo: You '-1' voted on the definition, anything to add?

<Chuck> mitch11: It doesn't come across as a definition. I agree with other comments that ask for the calculation and specificity.

<Chuck> maryjo: I'll look to others in the group to find the calculation.

<Chuck> mitch11: Your poll question was about the platform part. We shouldn't need a calculation. We should define platform. The definition you listed, android for example, they don't define it based on viewing angle.

<Chuck> mitch11: It's defined by an arbitrary number defined in software. They could come to market with another device with a difference.

<Chuck> maryjo: If you are using the platform definition, they are likely to have measuring tools based on that.

<Chuck> mitch11: Screenshots and then their conversions. That would be one such tool.

<Chuck> maryjo: Sounds not so good.

<Chuck> mitch11: You can measure the viewport once and then you know.

<Sam> Arc Length Formula (if θ is in degrees) s = 2 π r (θ/360°) where r is the view distance

GreggVan: agree the poll question looked like a discussion not a defintiion
… perhaps the definition is an abstract concept intended to be device independent, but it doesn't have a physical size - if that's the truth
… and the rest in a note
… a good definition can be inserted into a sentence to substitute for the word, might be overly verbose but it would work
… size varies, angle of view varies, but useful for handwaving technique
… concern: if it has no size and no angle of view, we'll make up an imaginary thing, troubling
… and if this is the reality, be up front about that, if it's true that it's not based on angle or size

maryjom: currently it is defined as angle, same as WCAG

GreggVan: so if it is an angle of view, what was the discussion about everybody defining it differently

maryjom: recapping the draft

GreggVan: if a platform has something different okay, but we'll have our definition - might we warn platforms differ?

<GreggVan> +1 to that

<Chuck> mitch11: I think it would help alot to... we have to do it at notes. It's normative WCAG. I think also a goodly part of this confusion is already a problem in WCAG. All the text you have there in original WCAG wasn't a note. That would already have a problem. I think we have to... word substitution won't do it. We have to patch in notes.

<Chuck> mitch11: I missed "note and example"....

<Chuck> mitch11: I didn't undertand it because... did you insert note into what is not a note?

<Chuck> maryjo: Looking for a definition in WCAG...

<Chuck> maryjo: <looking up and reading WCAG definition>

<maryjom> WCAG2ICT doesn't have this part of the WCAG definition included:

<maryjom> A CSS pixel is the canonical unit of measure for all lengths and measurements in CSS. This unit is density-independent, and distinct from actual hardware pixels present in a display.

<maryjom> User agents and operating systems should ensure that a CSS pixel is set as closely as possible to the CSS Values and Units Module Level 3 reference pixel [css3-values], which takes into account the physical dimensions of the display and the assumed viewing distance (factors that cannot be determined by content authors).

Sam: WCAG and elsewhere use an abstraction of a pixel, but people need a measurement, put a calipers to the screen
… platform definition can differ from what's physically on the screen

GreggVan: does WCAG have a typo, could this be a missing "note" nomenclature?
… and we can then substitute the note

<dmontalvo> Mitch: I like the idea of making an errata, if we can get it done, that would be great. Even if tehy can't take it, we can pretend that it is

<dmontalvo> ... I don't think The platform definitions are arbitrary, I think they are derived from the platform maker's decisions as to what should be the visual distance

<dmontalvo> ... You can obtain what the platform considers to be the visual distance, if we can't get to that, then we should define the visual distance

Sam: propose a side call

GreggVan: or in the email chain

maryjom: some have opposed the email chain; support a side call

<Sam> +1 to move comment

maryjom: move the comment to its own issue

GreggVan: yes move; stay as close as possible to the definition. Say how what they wrote can apply, rather than just writing something new

maryjom: and also non-web doc, non-web software distinction?

<Zakim> GreggVan, you wanted to say applies as defined in WCAG with CSS Pixes replaced by Device independent pixel , and "for content and software" for CSS, and NOTE insterted in front of the NOTE to identify it as a note.

<Sam> thank you... have to drop

GreggVan: different definition would create havoc
… we want what they want, something concrete

maryjom: look for email about availability for side call