Bug 1920483 Comment 1 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

It's expected that interactive target areas are to be 48dp or larger to allow users with limited dexterity and users on the go to better target and tap controls (per [WCAG 2.2 Level AAA Success Criteria 2.5.5 and 2.5.8 Target Size (Enhanced and Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)). More details could be found in [BBC Accessibility guide](https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/target-touch-size/).

### Items included:
1. **This text should not be detected as interactive**
    * @Jeff, do you know why it could be marked up as a control by automatic tools like the Scanner?
    * Assuming, there is no action associated with it - If there is an event listener attached to it or/and it's coded as a button or such, this would need to be removed because it'll be misleading for assistive technology users and would create a high `access-S3` issue
    * If this text is, in fact, actionable - its visual styling would need to be adjusted to visually communicate it for users without assisstive technology too, and this would again be a high `access-S3` issue.
2. **[Main size concern]** Usually, the size of 27pd would be triaged as `access-S2`. That's being said, the 6-digit code input field's height is an `access-S3` issue, because the item is an inline control - it's length is larger than 48dp which also enlarges the total area that can be tapped by being long, while the ability to activate and fill in the input is crucial for the entire flow.
3. **These two lines (items 3 and 4) need to be combined in one container that is a link** - so it would be just one tab/swipe stop for assistive technology, to reduce duplication and avoid confusion, since both the URL and the title should be pointing to the same target. This would allow for a larger touch target to be created. 

### Possible remediation for Item 2:
The size of the icon is not the main source of the size increase, because having a visually empty but actually tappable (interactive) space around the search icon is included in the size calculation. Also, for the [minimum compliance with WCAG 2.2](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) it would be acceptable to have the touch/interactive target area for the image button to be, let's say, 44 dp but the empty space between this touch area and any other interactive element to be 2 dp on each side (2+44+2 = 48). 

Also, consider making the entire block for the input actionable instead of the label/placeholder text alone.
It's expected that interactive target areas are to be 48dp or larger to allow users with limited dexterity and users on the go to better target and tap controls (per [WCAG 2.2 Level AAA Success Criteria 2.5.5 and 2.5.8 Target Size (Enhanced and Minimum)](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html)). More details could be found in [BBC Accessibility guide](https://www.bbc.co.uk/accessibility/forproducts/guides/mobile/target-touch-size/).

### Items included:
1. **This text should not be detected as interactive**
    * @Jeff, do you know why it could be marked up as a control by automatic tools like the Scanner?
    * Assuming, there is no action associated with it - If there is an event listener attached to it or/and it's coded as a button or such, this would need to be removed because it'll be misleading for assistive technology users and would create a high `access-S3` issue
    * If this text is, in fact, actionable - its visual styling would need to be adjusted to visually communicate it for users without assistive technology too, and this would again be a high `access-S3` issue.
2. **[Main size concern]** Usually, the size of 27pd would be triaged as `access-S2`. That's being said, the 6-digit code input field's height is an `access-S3` issue, because the item is an inline control - it's length is larger than 48dp which also enlarges the total area that can be tapped by being long, while the ability to activate and fill in the input is crucial for the entire flow.
3. **These two lines (items 3 and 4) need to be combined in one container that is a link** - so it would be just one tab/swipe stop for assistive technology, to reduce duplication and avoid confusion, since both the URL and the title should be pointing to the same target. This would allow for a larger touch target to be created. 

### Possible remediation for Item 2:
The size of the icon is not the main source of the size increase, because having a visually empty but actually tappable (interactive) space around the search icon is included in the size calculation. Also, for the [minimum compliance with WCAG 2.2](https://www.w3.org/WAI/WCAG22/Understanding/target-size-minimum.html) it would be acceptable to have the touch/interactive target area for the image button to be, let's say, 44 dp but the empty space between this touch area and any other interactive element to be 2 dp on each side (2+44+2 = 48). 

Also, consider making the entire block for the input actionable instead of the label/placeholder text alone.

Back to Bug 1920483 Comment 1