1.4.10 Reflow - CSS Pixel Definition / interpretation

[maryjom]

To focus work on the Definition of CSS pixel as applied to non-web documentation and software, I have created this issue.

Where CSS pixels is used

"CSS pixels" is used in several places in WCAG 2.2:

• 1.4.10 Reflow - to define the vertical scrolling content width of 320 CSS pixels and horizontal scrolling height of 256 CSS pixels. The note also gives the equivalent viewport scrolling at 400% zoom of 1280 x 1024 CSS pixels.
• 2.5.8 Target Size (Minimum) - where the size of the target is at least 24 by 24 CSS pixels. If under that size, the elements must be positioned so that if a 24 CSS pixel diameter circle is centered on the bounding box of each, the circles do not intersect another target or the circle for another undersized target
• 2.5.5 Target Size (Enhanced) Level AAA - where the size of the target is 44 by 44 CSS pixels
• 2.4.11 Focus Appearance Level AAA - where the area of the focus indicator is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component
• The WCAG definition of CSS pixels which states:

visual angle of about 0.0213 degrees

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. 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).

• The first note in the definition of general flash and red flash thresholds which states:

NOTE: For general software or Web content, using a 341 x 256 pixel rectangle anywhere on the displayed screen area when the content is viewed at 1024 x 768 pixels will provide a good estimate of a 10 degree visual field for standard screen sizes and viewing distances (e.g., 15-17 inch screen at 22-26 inches). This resolution of 75 - 85 ppi is known to be lower, and thus more conservative than the nominal CSS pixel resolution of 96 ppi in CSS specifications. Higher resolutions displays showing the same rendering of the content yield smaller and safer images so it is lower resolutions that are used to define the thresholds.

• Example in the definition of perimeter which states:

EXAMPLE 16: The perimeter calculation for a 2 CSS pixel perimeter around a rectangle is 4h+4w, where h is the height and w is the width. For a 2 CSS pixel perimeter around a circle it is 4𝜋r.

Using Device-independent pixels vs. CSS pixels for non-web contexts

• The TF came to consensus on using "device-independent pixel" after the discussion in the 20 April meeting.

Current proposal for device-independent pixel definition

device independent pixel
visual angle of about 0.0213 degrees

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 display.

Example: In the case of a computer display, 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 approximately 0.26 mm.

Comments on the topic of the CSS pixel definition from Issue #98

From Mitch on 18 April

Nit: Better to say "in the case of a mobile phone app"

My concerns for discussion:

• I'm unclear whether it's necessary to rename "CSS pixel" to "device independent pixel" if the essence of the definition is unchanged.
• As I've shown, Android defines a device independent pixel. It turns out to be 1/160 of inch or 0.15875 mm, not 0.26 mm. iOS and desktop operating systems also define the device independent pixel. I suggest we use those platform definitions when they exist, and fall back to viewing angles otherwise.

MJM Note During the 20 April meeting, the poll indicated all wanted to use "device-independent pixel" with a note talking about how it relates to CSS pixel.

---

Patrick Lauke's (18 April comment)

As I've #101 (comment), Android defines a device independent pixel. It turns out to be 1/160 of inch or 0.15875 mm, not 0.26 mm.

note that these definitions don't necessarily match the reality of different physical screen dimensions between devices. they're an approximation/idealised measure at best (just like CSS pixels, which can vary wildly between different monitors/devices)

to take an example: pick up two different android (or even iOS) devices with differing screen sizes, and measure (with a physical ruler) the size of interface components defined in dps (or Apple "points"). they will vary. Definitions that try to pin things down to a definitive size as measured on screen will almost certainly only be idealised/not correct.

---

Sam Ogami (19 April comment)

Some systems don’t have idea of pixel size, not changeable by author. This is a case where web requirement is not reverent and should not be applied. There are already other requirements for text size outside of WCAG2ICT. In addition to adding note 3 from MJ comment into this SC the closed products section a general note about pixels should be added as it CSS pixels or device independent pixels are in other SC also.

Jon Avila (4 May comment) & Mary Jo's response to this specific comment

Jon: While the definition is appropriate I can't help but wonder given that this SC is aimed at users with low vision that we should at least acknowledge somewhere that people with low vision would likely not be using the device at such a viewing distance. but that this is the standard viewing distance.

Mary Jo: I think that is true for web content as well - not just the application of WCAG to non-web ICT. If it is generally true for all tech, any statement to that effect should go into WCAG. WCAG's definition is based on the CSS reference pixel and that is how it is defined.

Mary Jo (10 May comment) posted some css reference pixel size calculations

See comment regarding calculated pixel size. However, as Patrick pointed out, the calculation was incorrect and would still misrepresent the sizes as viewed on different displays for different software platforms. Additionally, in the 11 May meeting it was pointed out the arc length calculation should be used - not the law of sines. Sam also mentioned that the formula should be included with the definition, since not all closed functionality products have any software ruler for pixel measurements and not all platforms have the concept of CSS pixels.

Paraphrased Patrick's comment response:

(generally, my advice is to never actually try and work out the "physical"/"real world" measure of something like CSS pixels, particularly using the "intuitive" definition given in the CSS spec. too many variables and assumptions, and that's even before you also dive into user settings, you just end up going in circles.

Jon Avila (10 May comment)

There is software such as pixel rules for Windows, Mac, and Android that could be used with non-web software and non-web documents - obviously for hardware it would be difficult to measure that precisely though as software isn't an option.

Mary Jo's response: Some software doesn't reside on top of a software platform (e.g. in closed functionality software), so there likely isn't a device-independent pixel defined, and likely no measuring tools to help. In the case of 1.4.10 Reflow, I'm not sure how a software author would make the appropriate measurements and calculations to ensure is met. In many cases, closed functionality software doesn't have the capability of increasing content size to 400% or maybe not at all.

Mary Jo (10 May comment) potential change to the device-independent pixel definition

Maybe we simply use the definition of #98 (comment) (above) and state that a device-independent pixel's size is dependent on the software platform's definition. In Android, it is called a "density-independent pixel (DP)" and in Windows it is called "device-independent pixel". I don't know if a DIP in those platforms is actually defined based on the viewing angle (I haven't found documentation about what it is based on.)

Patrick's response:
EDIT: found Android article on supporting different pixel densities and I think this part is relevant here:

One dp is a virtual pixel unit that's roughly equal to one pixel on a medium-density screen (160 dpi, or the "baseline" density).

Taking "one pixel on a medium-density screen" to (very handwavily) mean "one CSS pixel" (because that, roughly, matches reality - and keep in mind that on mobile/tablet, they don't have to deal with things like users changing the OS resolution etc), this shakes out nicely to basically saying that on android, read the SC to mean "320 dp / 256 dp" effectively).

Detlev (12 May comment) suggests using "nearest equivalent"

If adaptation to a portrait orientation is tested at all, it seems reasonable to adapt to existing, i.e. available, sizes, e.g., by adding a note that the reference to 320 px should be extended to "320 px or its nearest available equivalent" (if we can't have "up to").

Bruce and Mitch responded in support of this approach and Mitch gave an example in MacOS that you can't get down to a viewport of 320 CSS pixels.

[patrickhlauke]

visual angle of about 0.0213 degrees

as already suggested, I'd say scrap this part. the CSS pixel is not being used because of its visual size, but because it's the minimum stable unit of measure for web content (all other CSS units, even mm, cm, in, pt, etc are anchored on it)

[maryjom]

@patrickhlauke I don't think we're completely at liberty to do that, as WCAG2ICT is just supposed to provide "interpretation" not substantively change the requirement or definitions.

[mapluke]

Scrapping the "visual angle of about 0.0213 degrees" would not only change the core of the original CSS pixel definition, but it would throw away the only truly device and content independent definition of character size.

It is only the angle that a character subtends at the eye that determines whether it is large enough to read (although things like poor contrast can reduce the legibility of an otherwise legible character). Visual angle-based definitions don't depend on factors such as viewing distance or whether that character is made up of multiple pixels or is printed on a piece of paper.

Because visual angle is not the most practical thing to measure, WCAG SCs and their WCAG2ICT interpretations do need to introduce more tangible measures such as CSS pixel/device-independent pixel, but these should be expressed in a way that preserves as best as possible the underlying need to define things correctly in terms of visual angle.

Ideally, the SCs and the definition should work equally well for the radically different scenarios of software that is rendering small characters on a watch display and software that is driving a large wall-mounted information display. We've focussed on mobile phone and PC display, but these are not the most challenging use cases.

[patrickhlauke]

However, the SC can't make an actual physical size a requirement, when this is completely outside of the control of authors...

[maryjom]

I think I finally found all of the pertinent definition discussion points from Issue #98 and included them in sections in the first part of this issue. If you think I missed something, please add in here.

[maryjom]

There are two directions we could go with this - stick with the WCAG CSS pixel definition and simply add notes to that effect or create a Device-independent pixel definition, include the formula to calculate the arc length of the viewing angle, provide a listing of devices and viewing distance ranges.

For the "use the CSS pixels option", maybe the notes could be something like:

Note 1: Non-web software and its accompanying platform software does not use measurements of CSS pixels. Therefore, platform-specific pixel density-independent measurements should be used. Examples include: px in iOS and MacOS, density-independent pixels (DP) for Android, and device-independent pixels for Windows.

Note 2: Some non-web software cannot rely on device or density independent pixels as a substitute for CSS pixels because it resides on closed functionality products or is on a platform that has no equivalent concept. Such software should use the formula to calculate the arc-length of the viewing angle using the optimal viewing distance from the screen to calculate the reference pixel size.

[maryjom]

• U.S. Occupational Safety and Health Administration (OSHA) recommendations for computer monitor distance of between 20 and 40 inches (50 to 100 cm).
• Desktop: 24-36 inches (61.0 to 91.4 cm)- From ChatGPT, unknown original source (Mike)
• self-service kiosk optimal viewing distance is between 18 and 36 inches. (from National Institute of Standards and Technology (NIST) study) @Lboniello Please add a link to this resource.
• Mobile phone: 12-18 inches (30.5 to 45.7 cm) - From ChatGPT, unknown original source (Mike)
• Laptop: 20-30 inches (50.8 to 76.2 cm) - From ChatGPT, unknown original source (Mike)
• Smart watches: 6-12 inches (15.2 to 30.5 cm) From ChatGPT, unknown original source (Mike)

Factors such as screen size, resolution, and personal visual acuity can also influence the optimal viewing distance. Note that persons with low vision will often view displays at a much closer distance.

The reference pixel length = Length of Arc = θ × (π/180) × d
d is the distance to the screen

[mraccess77]

On a tangential note - Some of the challenges with optimal viewing distances is that they assume typical vision and thus when you are not in that typical range the screen may actually be harder to see because it is assumed that a person will not be viewing from other distances such as closer. I continue to recommend anytime we talk about viewing distance that we must have a note addressing the fact that this is not the distance that many people with low vision will be viewing it at.

[mapluke]

UI designers will typically use all of the figures that we have accumulated for deciding what character size to use to ensure that text is comfortably readable by someone with typical vision using their UI at the appropriate distance(s) for the intended class of product. As both @maryjom and @mraccess77 have pointed out, people with low vision will often need to use the product at radically shorter viewing distances to be able to read the text at all (sometimes even using a lupe with the product almost in contact with the face)!

An additional complicating factor is that some classes of product, such as wall-mounted displays, will prevent users from adjusting the viewing distance at all. The focus of 1.4.10, and all other WCAG SCs, on content rather than how that content is presented makes it impossible to take such important practical considerations into account.

[mitchellevan]

These two notes are promising: #162 (comment)

I suggest we discuss one note at a time, in context of the platforms that they pertain to.

2023-05-23 draft note 1 addresses mobile and desktop software modern software on smart watch, smartphone, and desktop operating systems; and possibly some gaming platforms. Any concerns?

2023-05-23 draft note 2 addresses the following. This is the harder one in my opinion, please bring examples on specific platforms:

• Software that runs on specific hardware, like kiosks or office equipment, where the author often does know the physical screen size
• Software, like TV streaming apps, where the author does not know the physical screen size but still probably knows something about the intended usage.

An additional complicating factor is that some classes of product, such as wall-mounted displays, will prevent users from adjusting the viewing distance at all. The focus of 1.4.10, and all other WCAG SCs, on content rather than how that content is presented makes it impossible to take such important practical considerations into account.

@mapluke, can you be more specific about which kinds of wall-mounted displays? If it's a PC attached to a projector, or a phone casting to a TV, then we can use the device-independent pixels defined for those platforms. A very different category of devices are like Section 508's "variable message signs." Are there other kinds we should be considering?

Acknowledging that there are no bright lines today, and in the future technology will surely change again — can we reasonably expect evaluators to come up with an "assumed viewing distance" (WCAG's phrase)? Kind of like how 1.4.4 Resize Text never set a screen size... On the one hand it would have been convenient for evaluators to have a hard rule like "800 by 600". But on the other hand, technology changes. Today some test at 1024 width, others at 1280 width; it's chaos, but it's arguably better chaos than stuck at 640 or 800 width forever.

[mitchellevan]

On a tangential note - Some of the challenges with optimal viewing distances is that they assume typical vision and thus when you are not in that typical range the screen may actually be harder to see because it is assumed that a person will not be viewing from other distances such as closer. I continue to recommend anytime we talk about viewing distance that we must have a note addressing the fact that this is not the distance that many people with low vision will be viewing it at.

I agree this would be a good note, but it should not change what we recommend for evaluating the success criteria. In fact, the smaller the "assumed viewing distance", the less stringent all of the criteria become... Thus forcing people with low vision to lean still further in, further reducing the "assumed viewing distance", a downward spiral.

[mitchellevan]

Reminder: In our 2023-05-11 call, we briefly considered pursuing an erratum for the WCAG definition of 'CSS pixel.' The idea was to mark a Note starting from "A CSS pixel is the canonical unit of measure..." down to the end of the paragraph. The result would be clarifying that the normative definition is just these words: "visual angle of about 0.0213 degrees".

I wouldn't go to the effort of an erratum for no reason, but if it turns out necessary to make things work in WCAG2ICT then I'm all for it.

[mitchellevan]

My original comment 2023-05-25

I found more sources for viewing distances on wearable, mobile, and TV platforms. I've derived viewing distances based on measurable information about pixels on the respective platforms. See attached:

CSS_pixels_and_viewing_distances_WCAG2ICT.xlsx

I found these details surprising yet believable:

• Both Apple and Google use longer viewing distances for watches than they do for phones.
• Viewing distances for smart TVs are inconsistent. Apple tvOS uses a distance within a range recommended by the Society of Motion Picture and Television Engineers (SMPTE), but on the low end of that range so it's somewhat weaker for accessibility. Android TV and FireTV use a high viewing distance, which is stronger for accessibility but it's beyond the SMPTE range.

TV platforms in particular will be a stress test for our WCAG2ICT notes.

Update 2023-06-02

I was wrong when I said a higher viewing distance is "stronger for accessibility." It's actually a mixture.

• A higher viewing distance has larger device-independent pixels. When viewport size is measured in fewer, larger pixels, this makes 1.4.10 Reflow less stringent.
• At the same time, larger pixels make interactive controls and focus indicators physically larger. This makes the Target Size and Focus Appearance criteria more stringent.

[maryjom]

I have updated my note above to try to improve on the proposed note language and incorporated a couple of potential examples from @mitchellevan's comment:

For the "use the CSS pixels option", maybe the notes could be something like:

Note 1: Non-web software and its accompanying platform software does not use measurements of CSS pixels. Therefore, platform-specific pixel density-independent measurements should be used. Examples include: px in iOS and MacOS, density-independent pixels (DP) for Android, and device-independent pixels for Windows.

Note 2: Some non-web software cannot rely on device or density independent pixels as a substitute for CSS pixels because it resides on closed functionality products or is on a platform that has no equivalent concept. Such software should use the formula to calculate the arc-length of the viewing angle using the optimal viewing distance from the screen to calculate the reference pixel size. Examples include:

• Software that runs on specific hardware, like kiosks or office equipment, where the author knows the physical screen size and, potentially, the pixel density.
• Software, like TV streaming apps, where the author does not know the physical screen size or viewing distance, but may know something about the intended usage. Calculations of the reference pixel size would be an approximation in such cases.

[pday1]

Thanks all for the discussion. I've attempted to take this and use in proposing content for target size in issue #80 (comment)

[mitchellevan]

In response to #162 (comment) and #80 (comment) and yesterday's Task Force call, I propose the following more detailed WCAG2ICT notes for css pixel.

Pasting again for context:

CSS pixel

visual angle of about 0.0213 degrees

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. 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).

Adding for WCAG2ICT:

For non-web software:

Note 1: Non-web software and its accompanying platform software do not use measurements of CSS pixels. Therefore, a visual-angle pixel measurement should be used which approximates the CSS Values and Units Module Level 3 reference pixel.

Note 2: Where available, a platform-defined visual-angle pixel should be used.

• Documentation for software developers often specifies a visual-angle pixel for the platform. Examples include: ‘px’ in iOS and MacOS, ‘density-independent pixels (DP)’ for Android, and ‘device-independent pixels’ for Windows.
• A platform might define a visual-angle pixel, yet not document it publicly. On a platform with both a web browser and non-web software, it is possible to obtain the visual-angle pixel by observing a web page element whose size in CSS pixels is known.

Note 3: Examples where a visual-angle pixel may not be defined in the platform:

• Software that runs on specific hardware, such as kiosks or office equipment, where the author may know the physical screen size and pixel density.
• Software, such as streaming apps on smart TV platforms, where the author does not know the physical screen size but may know an appropriate viewing distance or viewing angle.

Note 4: Where a platform-defined visual-angle pixel is not available, the following calculation is consistent with the reference pixel:

• Choose a midrange viewing distance (v) appropriate for most users.
• The length of the visual-angle pixel is the viewing distance (v) divided by 2688.

Note 5: The number 2688 is the ratio of viewing distance to length of the reference pixel (nominal arm’s length of 28 inches divided by 1/96 inch). When a device renders a visual-angle pixel with a length of L, it signifies that a viewing distance for the device is L times 2688.

Note 6: Most software and devices are usable at more than one viewing distance. However, for a visual-angle pixel to be considered an approximation for the reference pixel, the viewing distance of the visual-angle pixel must be plausible (ed.: or perhaps “logical”?). For example, in software designed for use with a touchscreen, a visual-angle pixel longer than 0.11 inch (0.28 mm) would not be plausible, because this would signify a viewing distance of more than arm’s length.

Note 7: People with low vision often use devices at less than the standard viewing distance. However, basing the visual-angle pixel on a midrange viewing distance provides a balance of benefits for users with disabilities. If a longer viewing distance were chosen as the basis for the visual-angle pixel, the viewport would be measured with a smaller number of larger pixels, causing Success Criterion 1.4.10 Reflow to be less stringent. If a shorter viewing distance were chosen, user interface components would be measured with a larger number of smaller pixels, causing the Target Size and Focus Appearance criteria to be less stringent.

Summary of my additions:

• Introduced the term 'visual-angle pixel', new to WCAG but used similarly in CSS3. (I'm not attached to this term. We could also try something like "device-independent pixels," I'd be fine with that too.)
• Added the possibility of defined-but-not-documented
• Added a way to determine the visual-angle pixel where it's not platform-defined, being careful not to say this is the only possible valid calculation.
• Even when the visual-angle pixel is platform-defined, if it doesn't resemble the reference pixel then don't use it.
• Added a note in response to @mraccess77's comments representing low-vision users

[patrickhlauke]

• Added a way to determine the visual-angle pixel where it's not platform-defined, being careful not to say this is the only possible valid calculation.
• Even when the visual-angle pixel is platform-defined, if it doesn't resemble the reference pixel then don't use it.

With those two points, doesn't that essentially invalidate the entire SC, which relies on a precisely defined (for better or worse) measure? It just pulls the rug from under the SC's normative foundation, in effect...

[ferBonnin]

Note 2: Where available, a platform-defined visual-angle pixel should be used.

• Documentation for software developers often specifies a visual-angle pixel for the platform. Examples include: ‘px’ in iOS and MacOS, ‘density-independent pixels (DP)’ for Android, and ‘device-independent pixels’ for Windows.

Note 6: Most software and devices are usable at more than one viewing distance. However, for a visual-angle pixel to be considered an approximation for the reference pixel, the viewing distance of the visual-angle pixel must be plausible (ed.: or perhaps “logical”?).

Nit: For iOS I think it should be 'pt' instead of 'px'

Do we know if the DP/ DPI examples in these platforms are defined using the visual angle?
And more generally, how Note 2 and Note 6 relate to each other? is it going to be the responsibility of each author to determine if the platform's visual-angle pixel is plausible / logical?

[patrickhlauke]

Another nit: for Windows, it's "effective pixels" (epx) rather than "device-independent pixels"

And no, I don't believe platforms define their units with direct reference to some visual angle, which makes the "specifies a visual-angle pixel for the platform" bit ... a bit dubious. For instance, take two different iPhones, one a "mini" or "SE" size, one a regular/pro one. despite having different physical/hardware pixel counts, they generally run at the same logical resolution...but their physical screen sizes are different, so an apple "point" has different physical dimensions (since both types of phones would be held at the same distance from the eye, in general)...

In some cases, there may be an "implication" of the idea that the measures scale based on a particular visual angle (see for instance https://learn.microsoft.com/en-us/windows/apps/design/layout/screen-sizes-and-breakpoints-for-responsive-design#effective-pixels-and-scale-factor), but they don't actually say something like "which is why our epx represents X steradians" or other such obscure definitions.

[maryjom]

After the conversation in the 8 June meeting, we decided to have the notes proposed for 2.5.8 Target size be applied to the CSS pixel definition (though the platform-specific terms are still being verified by @ferBonnin for the Windows platform). I've also attempted to take in salient points from Mitchell's latest comment.

NOTE 1: Non-web software and their accompanying platform software do not use measurements of CSS pixels. Therefore, platform-specific pixel density-independent measurements should be used. Examples include: pt for iOS and MacOS, density-independent pixels (DP) for Android, and device-independent pixels for Windows.

NOTE 2: Non-web software that either doesn't have the concept of device or density independent pixels or measurements by pixels, should use the formula contained in the definition of a reference pixel to calculate the arc-length of the viewing angle using the optimal viewing distance from the screen to calculate the reference pixel size.

Examples where device-independent pixels may not be defined in the platform include:

• Software that runs on specific hardware, like kiosks or office equipment, where the author knows the physical screen size and, potentially, the pixel density.
• Software, like TV streaming apps, where the author does not know the physical screen size or viewing distance, but may know something about the intended usage.

When there is no platform-defined device/density independent pixel measurement, the reference pixel size can be approximated in the following manner:

• Choose a viewing distance: The value for the viewing distance should be logical for the use case and type of display. As an example, a touchscreen would need to have a viewing distance less than an arm’s length - 28 inches (71 cm).
• Calculate the length of the reference pixel: Take the viewing distance (v) and divide it by 2688.

Note 3: People with low vision often use devices at less than the standard viewing distance. However, basing the visual-angle pixel on a midrange viewing distance provides a balance of benefits for users with disabilities. If a longer viewing distance were chosen as the basis for the visual-angle pixel, the viewport would be measured with a smaller number of larger pixels, causing Success Criterion 1.4.10 Reflow to be less stringent. If a shorter viewing distance were chosen, user interface components would be measured with a larger number of smaller pixels, causing the Target Size and Focus Appearance criteria to be less stringent.

[maryjom]

Here's a link to the WCAG 2.2 definition of CSS pixel
This is the latest proposal for WCAG2ICT, being surveyed and then discussed on 29 June. This would be added to the section Glossary Items with Specific Guidance.

CSS pixel

visual angle of about 0.0213 degrees

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. 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).

Guidance When Applying "CSS pixel" to Non-web Documents and Software

This applies directly as written and as described in the WCAG 2.2 glossary.

Note 1: Non-web software and its accompanying platform software do not use CSS pixel measurements. Therefore, platform-defined density-independent pixel measurements which approximate the CSS reference pixel should be used. Examples of platform-defined density-independent pixel measurements include: points (pt) in iOS and macOS, density-independent pixels (dp) for Android, and effective pixels (epx) for Windows.

Note 2: Examples where a density-independent pixel may not be defined in the platform:

• Software designed for specific hardware, such as kiosks or office equipment, where the author knows the physical screen size and, potentially, the pixel density.
• Software, such as streaming apps on smart TV platforms or similar software, where the author may lack information about the physical screen size but may know an appropriate viewing distance or viewing angle.

When there is no platform-defined density-independent pixel measurement, the reference pixel size can be approximated in the following manner:

-Determine a viewing distance: The chosen viewing distance should align with the use case and display type. For instance, in the case of a touchscreen, the viewing distance should be less than the length of an arm, typically around 28 inches (71 cm).
-Calculate the length of the reference pixel: Divide the viewing distance (v) by 2688.

Note 3: Most software and devices are usable at more than one viewing distance. However, for a density-independent pixel to be considered an approximation for the reference pixel, the viewing distance of the visual-angle pixel must be plausible. For example, in software designed for use with a touchscreen, a visual-angle pixel longer than 0.11 inch (0.28 mm) would not be plausible, because this would signify a viewing distance of more than arm’s length.

Note 4: People with low vision often use devices at less than the standard viewing distance. However, basing the device-independent pixel on a typical viewing distance provides a balance of benefits for users with disabilities. If a longer viewing distance were chosen as the basis for the device-independent pixel, the viewport would be measured with a smaller number of larger pixels, causing Success Criterion 1.4.10 Reflow to be less stringent. If a shorter viewing distance were chosen, user interface components would be measured with a larger number of smaller pixels, causing the 2.5.8 Target Size and 2.4.13 Focus Appearance criteria to be less stringent.

[maryjom]

Consensus from the meetings on 22 June (for Note 1) and 29 June (for the other notes) is as follows:

Guidance When Applying "CSS pixel" to Non-web Documents and Software

This applies directly as written and as described in the WCAG 2.2 glossary.

Note 1: Non-web software and its accompanying platform software do not use CSS pixel measurements. Therefore, use platform-defined density-independent pixel measurements which approximate the CSS reference pixel. Examples of platform-defined density-independent pixel measurements include: points (pt) in iOS and macOS, density-independent pixels (dp) for Android, and effective pixels (epx) for Windows.

Note 2: Examples where a density-independent pixel may not be defined in the platform:

• Software designed for specific hardware, such as kiosks or office equipment, where the author knows the physical screen size and, potentially, the pixel density.
• Software, such as streaming apps on smart TV platforms or similar software, where the author may lack information about the physical screen size but may know an appropriate viewing distance or viewing angle.

When there is no platform-defined density-independent pixel measurement, the reference pixel size can be approximated in the following manner:

• Determine a viewing distance that matches the use case and display type. For instance, in the case of a touchscreen, the viewing distance is normally less than the length of an arm, typically around 28 inches (71 cm).
• Calculate the size of the reference pixel: Divide the viewing distance by 2688. The number 2688 is obtained by dividing 28 inches (arm's length) by the derived reference pixel size (1/96 inch).

Note 3: Most software and devices are usable at more than one viewing distance. However, only viewing distances that are plausible for the product can be considered an appropriate approximation for the reference pixel. For example, in software designed for use with a touchscreen, a visual-angle pixel longer than 0.11 inch (0.28 mm) would not be plausible, because this would signify a viewing distance of more than arm’s length.

Note 4: People with low vision often use devices at less than the standard viewing distance. However, basing the device-independent pixel on a typical viewing distance provides a balance of benefits for users with disabilities. If a longer viewing distance were chosen as the basis for the device-independent pixel, the viewport would be measured with a smaller number of larger pixels, causing Success Criterion 1.4.10 Reflow to be less stringent. If a shorter viewing distance were chosen, user interface components would be measured with a larger number of smaller pixels, causing the 2.5.8 Target Size and 2.4.13 Focus Appearance criteria to be less stringent.

[ChrisLoiselle]

@maryjom do you want this on comments-by-guideline-and-success-criterion or within comments-on-definitions-in-wcag-2.2-glossary-in-appendix-a ? I will update per what you advise. Thanks for clarifying.

[maryjom]

@ChrisLoiselle This goes into the glossary section. Remember, don't include the original WCAG content, as it will be automatically included. Just the WCAG2ICT Guidance on applying "CSS Pixel" section and notes.

[maryjom]

Closing this issue, as the content is merged into the editor's draft.