Tasks for wide review

[LJWatson]

To prepare for horizontal review (as part of wide review) the following tasks need to be completed by the Editors:

Accessibility

Complete the FAST checklist. Document the responses in Markdown so I can include them when I open the request for review with the APA WG.

Create an "Accessibility" section in the specification that states this self-review has been completed, and documenting any accessibility considerations that were identified (if any).

I18n

Complete the short i18n checklist. Document the responses in Markdown so I can include them when I open the request for review with the I18n WG.

Privacy

Complete the self-review for privacy and security. Document the responses in Markdown so I can include them when I open the request for review with the Privacy IG and Security respectively.

Also take into account Mitigating browser fingerprinting in web specifications and RFC6973.

Create a "Privacy" section in the specification that states this self-review has been completed, and documenting any privacy considerations that were identified (if any).

Security

Referring to the self-review checklist completed for privacy, create an "Accessibility" section in the specification that states this self-review has been completed, and documenting any accessibility considerations that were identified (if any).

[garykac]

I18n

The short I18n checklist has been completed and the following item requires a comment:

• "describes a format or data that is likely to need localisation":
  This specification defines values that are not intended for display to the user, although there
  is nothing preventing sites from exposing these values.

[garykac]

Accessibility

This specification simply defines a set of values that are valid for use in the code attribute. Thus, it does not introduce any features that have accessibility concerns.

The FAST checklist has been completed and nothing is applicable to this specification.

A note related to the FAST checklist item: "If technology provides internationalization support": This specification inherently defines {{KeyboardEvent/code}} values for keyboards and provides human-readable names (like "ShiftLeft", "ControlRight", "AltGr" or "KeyQ").

These special key values are defined as human-readable strings so that code to detect special keys can be easier to understand. While these values are not intended to be exposed directly to users, there is nothing preventing that. Apps that choose to expose these values would need to determine whether or not it is appropriate to translate these strings for presentation (e.g.: presenting "Backspace" as "Suppr. arrière" for French users).

[garykac]

Privacy / Security self-review

2.1 What information might this feature expose to Web sites or other parties, and for what purposes is that exposure necessary?
This spec defines a set of valid values for the code attribute of the various key events. This is necessary for sites that need to identify the position of the key that is being pressed (for example, WASD keys for games), in a way that supports different keyboard layouts.

2.2 Do features in your specification expose the minimum amount of information necessary to enable their intended uses?
Yes

2.3 How do the features in your specification deal with personal information, personally-identifiable information (PII), or information derived from them?
N/A

2.4 How do the features in your specification deal with sensitive information?
N/A

2.5 Do the features in your specification introduce new state for an origin that persists across browsing sessions?
No

2.6 Do the features in your specification expose information about the underlying platform to origins?
There are a few special code values that can be used to identify particular keyboards. For example, IntlBackslash, IntlRo and IntlYen. The user would have to type these keys for the information to be exposed.

2.7 Does this specification allow an origin to send data to the underlying platform?
No

2.8 Do features in this specification enable access to device sensors?
No

2.9 Do features in this specification enable new script execution/loading mechanisms?
No

2.10 Do features in this specification allow an origin to access other devices?
No

2.11 Do features in this specification allow an origin some measure of control over a user agent’s native UI?
No

2.12 What temporary identifiers do the features in this specification create or expose to the web?
None

2.13 How does this specification distinguish between behavior in first-party and third-party contexts?
No difference

2.14 How do the features in this specification work in the context of a browser’s Private Browsing or Incognito mode?
No difference from normal behavior

2.15 Does this specification have both "Security Considerations" and "Privacy Considerations" sections?
Yep!

2.16 Do features in your specification enable origins to downgrade default security protections?
Nope

2.17 How does your feature handle non-"fully active" documents?
This attribute is only associated with key events, which are only sent if the document is fully active.

2.18 What should this questionnaire have asked?
???

3.1 Passive Network Attackers
N/A. These are values for a static attribute on an event.

3.2. Active Network Attackers
N/A

3.3. Same-Origin Policy Violations
N/A

3.4 Third-Party Tracking
N/A

3.5 Legitimate Misuse
A site could capture all keypresses and build a map of the values generated by the keyboard. If the user types enough any of the special keys are are only present on certain keyboards, then the site could try to match those values against a database of known keyboard layouts to narrow down the possible keyboard being used.

[garykac]

The appropriate sections of the specification have all been updated with this information.

[LJWatson]

Thanks @garykac . Requests for horizontal review have been made:

• A11y: UI Events Keyboard Events Code Values 2022-11-29 2023-01-31 a11y-request#48
• I18n: UI Events Keyboard Events Code Values 2022-11-29 > 2023-01-31 i18n-request#200
• Privacy:UI Events Keyboard Events Code Values 2022-11-29 2023-01-31 w3cping/privacy-request#109
• Security: UI Events Keyboard Events Code Values 2022-11-29 2023-01-31 security-request#45
• TAG: UI Events Keyboard Events Code Values review request w3ctag/design-reviews#790

[LJWatson]

The A11y review appears to be complete. They had one question about braille and other alternate input devices, but I've responded to explain that to the best of my knowledge these devices utilise standard key codes and values and so they're implicitly covered already. I've asked APA to confirm there are no issues arising on the Github issue.

The I18n review is still pending and I've sent a gentle nudge for news.

The PING review is complete with no issues arising.

There has been no response from the Sec review. I've sent a gentle nudge with a CC to PLH.

The TAG review is complete with no issues arising.

Sugest we leave it another week or so in case the I18n review completes, then I think it's OK to begin the transition process unless @marcoscaceres or @siusin think otherwise?