Success Criterion 2.5.8: Target Size (Minimum) (Level AA)

[pday1]

From Success Criterion 2.5.8:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: The target offset is at least 24 CSS pixels to every adjacent target;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• Inline: The target is in a sentence or block of text;
• User agent control: The size of the target and target offset is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed;

NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

Additional Guidance When Applying Success Criterion 2.5.8 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8 and Benefits from Understanding Success Criterion 2.5.8 (also provided below).

Note 1: CSS pixels may not be applicable in a non-web context. 6.24mm can be taken as an approximate equivalent for 24 CSS pixels. Somebody please check my work as I'm not sure I properly understand CSS pixels! I used the definition of a reference pixel, and in particular "For reading at arm’s length, 1px thus corresponds to about 0.26 mm (1/96 inch)."

Note 2: Systems that have a greater reading distance than desktop and mobile usage may benefit from larger target sizes.

[Lboniello]

@pday1
I'm in agreement that some alternative to pixels would be extremely useful. We've gotten in the habit of measuring the target height of the "I" on any content displayed in a kiosk interface to determine if the font size is sufficient, so I would imagine that an alternative on the pixel front would be helpful as well. Distance from viewing should also be noted and factored in, as noted above.

I unfortunately don’t have any experience with an alternative to pixels, either.

[patrickhlauke]

Just jumping in, in relation to that "note 1", to say: while yes, there is an ideal definition for what size a reference pixel would be, the reality will depend on many more factors, not least of them decisions taken by device manufacturers. there is no guarantee that in the wild, a relationship such as "6.24mm can be taken as an approximate equivalent for 24 CSS pixels" will be true, and it's outside of a developer's control to know/address this for the most part.

the same holds true for operating-system-specific measurements, such as Apple's "points" - which are different from typographic points. overall there's basically very little guarantee (except when working specifically on a known device) that an author can accurately predict the real-world (as measured on screen) dimensions of something they define.

which is why for WCAG, we had to settle for CSS pixels (which are also the base unit of measure that all other units in CSS, like mm, cm, etc, are derived from/anchored on ... and similarly, defining something in CSS for web content as 10mm generally does not guarantee it actually will be 10mm in the real world, as measured on the actual screen of a device/monitor for a desktop/laptop)

[bruce-usab]

Please note that the "inline" exception has been refined as part of the work with moving WCAG 2.2 to CR.

Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;

https://www.w3.org/TR/WCAG22/#target-size-minimum

[maryjom]

@pday1 Is this ready for the Task Force to review?

[pday1]

@maryjom I think it could be useful to discuss next week - at least to get more input from the wider team.

[maryjom]

Along with the discussion of the SC interpretation itself are the new definitions that come with this SC:

CSS pixel

From the WCAG 2.2 definition for 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).

pointer input

input from a device that can target a specific coordinate (or set of coordinates) on a screen, such as a mouse, pen, or touch contact

NOTE
See the Pointer Events definition for "pointer" [pointerevents].

target

From the WCAG 2.2 definition for target:

region of the display that will accept a pointer action, such as the interactive area of a user interface component

NOTE
If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same page.

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “Web page” with “non-web document or software”.

With this substitution, it would read:

target

region of the display that will accept a pointer action, such as the interactive area of a user interface component

NOTE
If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same [non-web document or software].

target offset

From the WCAG 2.2 definition for target offset:

length of the longest possible line that starts at an edge of a target (A), intersects a second edge of A, and ends at the closest edge of a second target (B). For horizontally aligned targets, target offset is measured with a horizontal line. For vertically aligned targets, target offset is measured with a vertical line. For targets that are neither, target offset is measured diagonally.

Two targets are horizontally aligned if a horizontal line can be drawn that goes through both targets, but no vertical line can be drawn that goes through both targets. Two targets are vertically aligned if a vertical line can be drawn that goes through both targets, but no horizontal line can be drawn that goes through both targets.

NOTE
The target offset from A to B may be different than the target offset from B to A, if the sizes of these targets differ.

[maryjom]

@pday1 This is an SC that WCAG 2.2 moved from a Level AAA to Level AA requirement. Along with that, it appears there are a number of changes to the language of 2.5.8 Target Size (Minimum) in WCAG 2.2 as part of that movement. The project labels this SC to be part of WCAG 2.2 incorporations into the WCAG2ICT Note, so I would prefer to work on issues labeled with WCAG 2.1 for now. Apologies for not noticing that earlier.

[pday1]

OK no problem. I suggest we park this then - I've put a note in the title

[maryjom]

As an aside... When we talk about 2.5.8 touch target, info I found about fingertip size:

• the adult fingertip size is approximately 10mm (according to the U.S. govt. UX design website)
• MIT Touch Lab found that the average person’s fingertips are 1.6–2cm (0.6­­–0.8 in) wide

The U.S. govt. website is recommending touch targets be 44px by 44px. I'm not sure if they mean CSS pixels or actual pixels - it isn't clear.

Also, I found this Android Developers' video on touch target testing (from 1 year ago) that supports use of the platform-specific density-independent pixels (DP) when testing the touch target size. The test tool he used in the video was checking for 48 x 48 DP. Not sure how that compares in size to the 24 x 24 CSS pixels required by 2.5.8 touch target or if this is instead testing for the AAA which is 44 x 44 CSS pixels.

Nielsen Norman Group has an article on Touch Targets on Touchscreens where the conclusion says to have usable touch targets, they should measure at least 1 cm x 1 cm in the rendered size with adequate space (unspecified in the article) between touch targets.

[patrickhlauke]

again: unless they are designing for one, unchangeable, known physical screen size at a known, unchangeable resolution, authors cannot control the real-world (as measured on the physical screen) size that content/controls are rendered. which is why even apple, google, and microsoft guidance uses abstracted measures like dp, point, effective pixel - rather than cm.

[maryjom]

@patrickhlauke I understand, but we also have to interpret for software on closed products - where the CSS pixel size and device-independent pixels may have no meaning whatsoever. So the SC, as it is written, is not so easily applied. Usability information gleaned from these, and potentially other sources, would have to inform some other form of requirement or best practice.

[patrickhlauke]

sure, but my point is a measure of size that relates to actual physical size as measured on the device/screen will for non-web documents will turn this into direct conflict with web documents which do not (and cannot) base things on actual physical size. so potentially on the same device you'd start having things that pass if they're web content but fail if they happen to be non-web/native, or vice-versa.

[patrickhlauke]

(note that this discussion here is target size, not reflow capability)

[maryjom]

My former comment deleted. I had reflow on the brain because of this morning's WCAG2ICT meeting.

[maryjom]

@pday1 In the 2nd half of the 25 May meeting, we decided to see if this SC would be easier to think about with regard to CSS pixels and application to non-web software and documentation. Can you make the necessary updates to include the latest language for 2.5.8 Target Size from the WCAG 2.2 Candidate Recommendation published recently? We'd like to discuss this in the 1 June meeting.

[pday1]

(Taking latest CR language and combining with discussion on CSS pixels ...)

From Success Criterion 2.5.8:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are 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;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• Inline: The target is in a sentence or its size is otherwise constrained by the line-height of non-target text;
• User agent control: The size of the target is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed.

NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

NOTE
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

Additional Guidance When Applying Success Criterion 2.5.8 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8 and Benefits from Understanding Success Criterion 2.5.8 (also provided below).

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: px in 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 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.

As an example, for a system that is designed to be read at approximately an arm's length, 6.24mm can be taken as an approximate equivalent for 24 CSS pixels, as at that distance, 1px corresponds to about 0.26 mm (1/96 inch).

[mitchellevan]

I was pondering whether software platforms with very small, very large, or distant screens might cause anything in this criterion to become problematic.

My conclusion: There's no problem.

I considered the following examples.

• Software developer documentation for popular watches, smartphones, and personal computers all recommend target sizes that are in a similar range and measured in device-independent pixels. So this criterion should not create an unreasonable imposition on developers on any of these platforms.
• Some LG smart TVs have a mouse pointer built into the TV remote (autoplay YouTube video at 0:45). As the person viewing the screen gets further away from the screen, the pointing device travels with them, so it makes sense for pointer targets to scale up proportionally.
• If one applies this criterion to platforms that do not specify an equivalent of a CSS pixel or device-independent pixel, but do offer a touchscreen or pointing device anything like the ones described above, I expect that the same principles will hold.

[mitchellevan]

@patrickhlauke wrote

sure, but my point is a measure of size that relates to actual physical size as measured on the device/screen will for non-web documents will turn this into direct conflict with web documents which do not (and cannot) base things on actual physical size. so potentially on the same device you'd start having things that pass if they're web content but fail if they happen to be non-web/native, or vice-versa.

If a platform has a web browser on it, then it's possible to measure native software dimensions in terms of CSS pixels.

1. View something of a known CSS pixel size in a web browser.
2. Measure the physical size on the screen (any screen, doesn't matter). This becomes your ruler.
3. Measure the native app with the same ruler on the same screen.

Is there any software platform where this doesn't work? I can't think of any.

[mitchellevan]

In my last two comments, I've been careful to say "software" platforms. PDF is problematic for SC 2.5.8 Target Size.
Unlike all software I've seen, PDF documents typically do not have a default scale or zoom level for displaying the document on screens.

So I'm thinking of a note something like the following. It's probably more general than just for Target Size.

Some document formats do not have a default zoom level, but have commonly available user agents that allow users to view the content at a wide range of sizes. When evaluating such documents, it is a best practice to choose a starting zoom level appropriate for the intended usage of the content.

[maryjom]

Are there other notes needed for documents? I see @mitchellevan proposed:

Some document formats do not have a default zoom level, but have commonly available user agents that allow users to view the content at a wide range of sizes. When evaluating such documents, it is a best practice to choose a starting zoom level appropriate for the intended usage of the content.

However, is the "intended usage" of the content always known, and would the "appropriate zoom level" be obvious?

[pday1]

Changes agreed in WCAG2ICT call on 1st June.

• Make change for user agent - "user agent or platform software"
• Also have a note for documents as per Mitch -Mitch to propose modified language. But separate and make clear that it is for non-web documents (not in with the non-web software)
• Add definition to "bounding box" or "minimum bounding box"
• Remove benefits reference from all previous SCs and this one
• May need another note for closed functionality products that do not support device independent pixels, could also include touch target size reference - TBD by closed functionality sub-group

[maryjom]

I've taken comments and agreed upon changes from the meeting and synthesized into the following:

From Success Criterion 2.5.8:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are 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;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;
• User agent control: The size of the target and target offset is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed;

NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

NOTE
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

Additional Guidance When Applying Success Criterion 2.5.8 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8 (also provided below), replacing "user agent" with "user agent or platform software".

With these substitutions, it would read:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are 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;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;
• [User agent or platform software] control: The size of the target and target offset is determined by the [user agent or platform software] and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed;

NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

NOTE
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

(for non-web documents)

Note: Some document formats do not have a default zoom level, but have commonly available user agents that allow users to view the content at a wide range of sizes. When evaluating such documents, it is a best practice to choose a starting zoom level appropriate for the intended usage of the content.

(for non-web software)

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: px in 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 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.

As an example, for a system that is designed to be read at approximately an arm's length, 6.24mm can be taken as an approximate equivalent for 24 CSS pixels, as at that distance, 1px corresponds to about 0.26 mm (1/96 inch).

NOTE 3: See also the discussion on Closed Functionality.

The specific content to add to the Appendix on SC problematic for closed functionality is being developed by the sub-group.

---

Definitions to add for this SC:

To the section Glossary Items that Apply to All Technologies, add:

• bounding box
• pointer inputs

To the section Glossary Items with Specific Guidance, add:

target
region of the display that will accept a pointer action, such as the interactive area of a user interface component

NOTE
If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same page.

Guidance When Applying “target” to Non-Web Documents and Software

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “page” with “non-web document or content presented by software”.

With this substitution, it would read:
target
region of the display that will accept a pointer action, such as the interactive area of a user interface component

NOTE
If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same [non-web document or content presented by software].

[patrickhlauke]

Note the nitpicks/extra thoughts on this over on #162 (comment)

[maryjom]

After the 8 June conversation, this is where we landed:

From Success Criterion 2.5.8:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are 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;
• Equivalent: The function can be achieved through a different control on the same page that meets this criterion.
• Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;
• User agent control: The size of the target and target offset is determined by the user agent and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed;

NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

NOTE
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

Additional Guidance When Applying Success Criterion 2.5.8 to Non-Web Documents and Software:

This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.8 (also provided below), replacing "user agent" with "user agent or platform software", and "on the same page" with "in the same non-web document or software".

With these substitutions, it would read:

The size of the target for pointer inputs is at least 24 by 24 CSS pixels, except where:

• Spacing: Undersized targets (those less than 24 by 24 CSS pixels) are 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;
• Equivalent: The function can be achieved through a different control [in the same non-web document or software] that meets this criterion.
• Inline: The target is in a sentence, or is in a bulleted or numbered list, or its size is otherwise constrained by the line-height of non-target text;
• [User agent or platform software] control: The size of the target and target offset is determined by the [user agent or platform software] and is not modified by the author;
• Essential: A particular presentation of the target is essential or is legally required for the information being conveyed;

NOTE
Targets that allow for values to be selected spatially based on position within the target are considered one target for the purpose of the success criterion. Examples include sliders with granular values, color pickers displaying a gradient of colors, or editable areas where you position the cursor.

NOTE
For inline targets the line-height should be interpreted as perpendicular to the flow of text. For example, in a language displayed vertically, the line-height would be horizontal.

(for non-web documents)

Note: Some document formats do not have a default zoom level, but have commonly available user agents that allow users to view the content at a wide range of sizes. When evaluating such documents, it is a best practice to choose a starting zoom level appropriate for the intended usage of the content.

(for non-web software)

NOTE: See also the discussion on Closed Functionality.

The specific content to be added to the Appendix on SC problematic for closed functionality is being developed by the sub-group.

---

Definitions to add for this SC:

To the section Glossary Items that Apply to All Technologies, add:

• bounding box
• pointer inputs

To the section Glossary Items with Specific Guidance, add:

target
region of the display that will accept a pointer action, such as the interactive area of a user interface component

NOTE
If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same page.

Guidance When Applying “target” to Non-Web Documents and Software

This applies directly as written and as described in the WCAG 2.2 glossary, replacing “page” with “non-web document or content presented by software”.

With this substitution, it would read:
target
region of the display that will accept a pointer action, such as the interactive area of a user interface component

NOTE
If two or more targets are overlapping, the overlapping area should not be included in the measurement of the target size, except when the overlapping targets perform the same action or open the same [non-web document or content presented by software].

---

Notes for the CSS definition

@ferBonnin is investigating what terms are used in Microsoft products. Patrick mentioned "effective pixels" (epx), but I had based the proposal on what I had found - a fairly recent [Windows App Development article](DirectWrite measures font sizes in DIPs) on the Microsoft site comparing DIP and "device independent pixels" and says that DeviceWrite uses DIP. Maybe for Win32 apps DIP is used and then EPX is used for Universal Windows Platform apps?

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: px in 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 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.

[mitchellevan]

From our 2023-06-01 Task Force discussion on target size I offered to try to update this part of the draft:

(for non-web documents)

Note: Some document formats do not have a default zoom level, but have commonly available user agents that allow users to view the content at a wide range of sizes. When evaluating such documents, it is a best practice to choose a starting zoom level appropriate for the intended usage of the content.

The idea was: could evaluating a PDF for 2.5.8 Target Size be based on the "actual size" viewing of the PDF?

A limitation is that not all PDF viewers (a.k.a. user agents) give the user a way to view the PDF at actual size. I tried viewing a downloaded Yosemite Park map PDF in the following user agents:

• Windows: Adobe Acrobat viewer
• Windows: Chrome browser
• Windows: Firefox browser
• Android: Adobe Acrobat
• Android: Google Drive viewer

The PDF viewing user agents on Windows offered an easy to find "100%" or "actual size" zoom level, but the mobile user agents neither defaulted to "actual size" nor offered a way to switch to it. These mobile user agents neither inform the user of the current zoom level nor offer a choice of discrete zoom levels; they only offer a wide continuous range of zoom.

Another problem with relying on "actual size" comes from the fact that it is a print concept. Suppose a PDF contained links designed for usable target sizes in a desktop user agents, yet the "actual size" was set in the PDF for a tiny piece of paper such as a 55 mm wide business card. This would cause the 2.5.8 evaluation to fail for a reason that doesn't actually affect users.

So I suggest we do one of two things.

1. Keep the above note as-is, or
2. Modify it as follows

(for non-web documents)

Note: Some document formats are designed to be viewed at a wide range of zoom levels provided by the user agent, but the commonly available user agents for the format do not provide a consistent base zoom level from which to evaluate this criterion. For such documents it is a best practice to evaluate target sizes at a zoom level where the purpose of the targets is visually understandable.

Acrobat Viewer on Android, just after opening a downloaded PDF of a wide map

Acrobat Viewer on Windows: the same PDF with zoom set to "actual size"

Source of the downloaded Yosemite map

[maryjom]

On 29 June, the TF agreed to update the non-web documents note as follows:

(for non-web documents)
NOTE: Some document formats are designed for viewing at a wide range of zoom levels provided by the user agent. However, the commonly available user agents for these formats may lack a consistent base zoom level from which to evaluate this criterion. For such documents, evaluate target sizes at a zoom level that aligns with the intended usage of the content.

[maryjom]

I think I had missed this one in the closed functionality survey because 2.5.8 is actually a WCAG 2.2 criteria and we hadn't really discussed those further in our sub-group meetings. So if we don't have this bullet ready for the First Public Working Draft, we can just add an editor's note on the 2.5.8 SC guidance that it will be developed for the next draft.

[pday1]

Notes 1 and 2 need rework.
Need to say something along the lines of closed products - there is a large variety in display sizes and a lack of pixel density independent measurements, thus a physical measurement may be more useful.
However, this should be defined in such a way as to still be feasible for devices with very small screens.

This is a very rough note as a reminder to myself, rather than being a well-written proposal, suitable for review!

[maryjom]

Copying in the thoughts from the Google spreadsheet Closed Functionality analysis of the SC:

Phil: Problematic due to using CSS pixels as previously discussed in reflow. Physical equivalents would greatly help in implementing this type of requirement. Similarly, testing may not be feasible by any other than the content creator

Mary Jo: Agree, that closed functionality would more likely to not have any method of measuring size of targets using software, would likely not have any concept of device-independent pixels or CSS pixels, and often would be tied to a particular display/configuration (so the pixel density wouldn't be changeable). If there was a concept of pixel density-independent measures, recommend using that. Otherwise, a physical size fallback based on the research for fingertip size could be developed by a standards organization.

[maryjom]

@pday1 Once you get the closed functionality bullets to a state where the TF can review them, I can add them to the next survey.

[samogami]

The word 'page' is web specific and not applicable to non-web ICT.
We need to change the second bullet removing "on the same page that" so it reads:
"Equivalent: The function can be achieved through a different control meets this criterion."

[mraccess77]

Re: Sam's comment - While page should be removed, we need to find a way to make sure the alternative isn't just available anywhere in the software but within the same context as otherwise this could be met in unintended ways that do not provided an equitable experience.

[samogami]

Sorry. @maryjom resolved issue in her comment #80 (comment) with replacing "on the same page" with "in the same non-web document or software".

[maryjom]

Since this SC has been incorporated into the WCAG2ICT FPWD, I've spun off remaining work into a new issue - #258. This way we'll have a fairly clean comment stream.