Meeting minutes
Regrets from James Harrington and Laura Miller
Announcements
<bbailey> Happy GAAD
2.4.13 Focus Appearance
<PhilDay> Link to issue: w3c/
<PhilDay> Applying SC 2.4.13 Focus Appearance to Non-Web Documents and Software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.4.13, replacing “user agent” with “user agent or platform software”.
<PhilDay> With these substitutions, it would read:
<PhilDay> When the keyboard focus indicator is visible, an area of the focus indicator meets all the following:
<PhilDay> • is at least as large as the area of a 2 CSS pixel thick perimeter of the unfocused component or sub-component, and
<PhilDay> • has a contrast ratio of at least 3:1 between the same pixels in the focused and unfocused states.
<PhilDay> Exceptions:
<PhilDay> • The focus indicator is determined by the [user agent or platform software] and cannot be adjusted by the author, or
<PhilDay> • The focus indicator and the indicator's background color are not modified by the author.
<PhilDay> NOTE 1
<PhilDay> What is perceived as the user interface component or sub-component (to determine enclosure or size) depends on its visual presentation. The visual presentation includes the component's visible content, border, and component-specific background. It does not include shadow and glow effects outside the component's content, background, or border.
<PhilDay> NOTE 2
<PhilDay> Examples of sub-components that may receive a focus indicator are menu items in an opened drop-down menu, or focusable cells in a grid.
<PhilDay> NOTE 3
<PhilDay> Contrast calculations can be based on colors defined within the technology (such as HTML, CSS and SVG). Pixels modified by [user agent or platform software] resolution enhancements and anti-aliasing can be ignored.
<PhilDay> NOTE 4 (Added) (copied from 1.4.10 and 2.5.8)
<PhilDay> In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to non-web documents and non-web software.
<PhilDay> NOTE 5 (ADDED) (FOR NON-WEB SOFTWARE) - from 2.1.2
<PhilDay> This criterion applies when focus can be moved using a keyboard interface. Some software may accept input from a keyboard, keypad, or controller, yet not offer any mechanism for focus; for example, the keys are mapped directly to functions without moving focus between on-screen controls. In this case, there is no concept of focus, and therefore
<PhilDay> keyboard traps cannot exist and this success criterion would be satisfied.
<PhilDay> And for SC problematic for closed functionality (derived from 2.4.7):
<PhilDay> 2.4.13 Focus Appearance — Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some ICT with closed functionality may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the user interface is designed
<PhilDay> not to need that. For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this success criterion would be satisfied.
<PhilDay> • We have 1 proposal to review, derived from similar SCs including 1.4.10, 2.12, 2.4.7, 2.5.8
PhilDay: Derived from similar SCs
… Went through existing mentions of keyboard and mentions of focus
bbailey: What have we done with SCs mentioning user agents?
PhilDay: We use user agent or platform software
bbailey: User agent seems the wrong word, that's just covering assistive technologies
… There might be things that are not assistive technologies
Daniel: No comments
loicmn: Same
bbailey: Why do we need the CSS pixel?
PhilDay: It's in the original SC
… Note 4 is consistent wherever we mention CSS pixels
bbailey: 4 or 3?
PhilDay: 4 in IRC
<PhilDay> NOTE 4 (Added) (copied from 1.4.10 and 2.5.8)
<PhilDay> In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to non-web documents and non-web software.
bbailey: Not sure why the note numbering changed from the previous proposal
Daniel: I think the scripts should take care of the numbering
<PhilDay> 2.4.13 Focus Appearance — Presumes that there is a mode of operation where focus can be moved and controlled by keyboard. Some ICT with closed functionality may offer tactilely discernible input such as a numeric keypad or other functional groups of keys, but do not offer any mechanism for conveying focus because the user interface is designed
<PhilDay> not to need that. For example, the keys are used to select options from a spoken menu rather than to move an onscreen focus element between multiple options. In this case, there is no concept of focus, thus there is no need for a visible indicator and this success criterion would be satisfied.
PhilDay: Sound all of us are happy with the proposed wording
<PhilDay> DRAFT RESOLUTION: For 2.4.13 Focus Appearance incorporate proposal into the editor’s draft, as is
<loicmn> +1
<bbailey> +1
<PhilDay> +1
<Daniel> +1
RESOLUTION: For 2.4.13 Focus Appearance incorporate proposal into the editor’s draft, as is
Announcements
2.5.5 Target Size (Enhanced)
<PhilDay> Link to issue: w3c/
<PhilDay> • We have 1 proposal to review, derived from similar SCs including 1.4.10, 2.5.8
PhilDay: Derived from similar SCS
<PhilDay> Applying SC 2.5.5 Target Size (Enhanced) to non-web documents and non-web software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.5, replacing “user agent” with “user agent or platform software”.
<PhilDay> With these substitutions, it would read:
<PhilDay> The size of the target for pointer inputs is at least 44 by 44 CSS pixels except when:
<PhilDay> Equivalent
<PhilDay> The target is available through an equivalent link or control on the same page that is at least 44 by 44 CSS pixels;
<PhilDay> Inline
<PhilDay> The target is in a sentence or block of text;
<PhilDay> User Agent Control
<PhilDay> The size of the target is determined by the **[user agent or platform software]** and is not modified by the author;
<PhilDay> Essential
<PhilDay> A particular presentation of the target is essential to the information being conveyed.
<PhilDay> NOTE (ADDED) - from other places where CSS pixels are referenced
<PhilDay> In technologies where CSS is not used, the definition of 'CSS pixel' applies as described in Applying “CSS pixel” to non-web documents and non-web software.
<PhilDay> NOTE (ADDED) (FOR NON-WEB DOCUMENTS) - from 2.5.8
<PhilDay> Some non-web 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
<PhilDay> the content.
<PhilDay> NOTE(ADDED) (FOR NON-WEB SOFTWARE) - from 2.5.8
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> And in SC problematic for closed functionality (from 2.5.8):
<PhilDay> 2.5.5 Target Size (Enhanced) — This success criterion uses CSS pixels for defining the target size. ICT with closed functionality may not use CSS pixels as a standard measurement, but the definition of ‘CSS pixel’ still applies as described in Applying “CSS pixel” to non-web documents and non-web software. If the system supports a
<PhilDay> density-independent pixel measurement, it should be used in place of CSS pixels.
<PhilDay> NOTE
<PhilDay> If the viewing distance and pixel density of the system are unknown, approximating the reference pixel as described in Applying “CSS pixel” to non-web documents and software is not possible.
<PhilDay> NOTE
<PhilDay> For non-web software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for a CSS pixel are dependent on the viewing distance or pixel density of the display.
<PhilDay> SC problematic: 2.5.5 Target Size (Enhanced) — This success criterion uses CSS pixels for defining the target size. ICT with closed functionality may not use CSS pixels as a standard measurement, but the definition of ‘CSS pixel’ still applies as described in Applying “CSS pixel” to non-web documents and non-web software. If the system
<PhilDay> supports a density-independent pixel measurement, it should be used in place of CSS pixels.
<PhilDay> NOTE
<PhilDay> If the viewing distance and pixel density of the system are unknown, approximating the reference pixel as described in Applying “CSS pixel” to non-web documents and software is not possible.
<PhilDay> NOTE
<PhilDay> For non-web software designed to run on specific known hardware, a physical size standard would be more straightforward to apply, as calculations for a CSS pixel are dependent on the viewing distance or pixel density of the display.
<bbailey> looks good
<PhilDay> DRAFT RESOLUTION: For 2.5.5 Target Size (Enhanced) incorporate proposal into the editor’s draft, as is
<Daniel> +1
<bbailey> +1
<PhilDay> +1
<loicmn> +1
RESOLUTION: For 2.5.5 Target Size (Enhanced) incorporate proposal into the editor’s draft, as is
2.5.6 Concurrent Input Mechanisms
<PhilDay> Link to issue: w3c/
<PhilDay> • We have 1 proposal to review, with input from Bruce & Mary Jo. Content links to the definition of Content on & off the web
<PhilDay> Applying SC 2.5.6 Concurrent Input Mechanisms to Non-Web Documents and Software
<PhilDay> This applies directly as written, and as described in Intent from Understanding Success Criterion 2.5.6, replacing “Web content” with “Content”.
<PhilDay> With these substitutions, it would read:
<PhilDay> [Content] does not restrict use of input modalities available on a platform except where the restriction is essential, required to ensure the security of the content, or required to respect user settings.
<loicmn> Good for me
<PhilDay> DRAFT RESOLUTION: For 2.5.6 Concurrent Input Mechanisms incorporate proposal into the editor’s draft, as is
<loicmn> +1
<Daniel> +1
<bbailey> +1
<PhilDay> +1
RESOLUTION: For 2.5.6 Concurrent Input Mechanisms incorporate proposal into the editor’s draft, as is
3.1.3 Unusual Words
<PhilDay> Link to issue: w3c/
<PhilDay> • We have 1 proposal to review, derived from similar SCs:
<PhilDay> o 1.4.4 Resize Text
<PhilDay> o 2.4.2 Page Titled
<PhilDay> o 1.2.9 Audio-Only (Live)
<PhilDay> Applying SC 3.1.3 Unusual Words to non-web documents
<PhilDay> This success criterion is problematic to apply directly to non-web documents because not all document formats provide support for a mechanism to provide definitions of words or phrases. Where the non-web document format provides such a mechanism, the non-web document should work with these features to the extent the format provides. Doing so would
<PhilDay> still address the user needs identified in Intent from Understanding Success Criterion 3.1.3.
<PhilDay> Applying SC 3.1.3 Unusual Words to non-web software
<PhilDay> This success criterion is problematic to apply directly to non-web software because not all platforms provide support for a mechanism to provide definitions of words or phrases. Non-web software needs to work with platform capabilities where they exist, but when the platform does not provide capabilities, it is unreasonable for all apps on a
<PhilDay> particular platform to build in their own mechanism to provide definitions of words or phrases. Where the platform does provide a suitable mechanism, the non-web software should work with these features to the extent the platform provides. Doing so would still address the user needs identified in Intent from Understanding Success Criterion 3.1.3.
<PhilDay> NOTE (FOR NON-WEB SOFTWARE)
<PhilDay> See also the Comments on Closed Functionality.
<PhilDay> And in SC problematic for closed:
<PhilDay> 3.1.3 - This success criterion is problematic to apply to ICT with closed functionality as they may not provide support for a mechanism to provide definitions of words or phrases.
PhilDay: Similar SCs separate non-web documents and non-web software
… Although we are saying similar things, so we could also combine them
bbailey: Is it because of the reference to closed functionality?
<loicmn> Good for me
PhilDay: And also document formats and platform capabilities
<PhilDay> DRAFT RESOLUTION: For 3.1.3 Unusual Words incorporate proposal into the editor’s draft, as is
<loicmn> +1
<PhilDay> +1
Daniel: Good to be consistent
<Daniel> +1
<bbailey> +1
RESOLUTION: For 3.1.3 Unusual Words incorporate proposal into the editor’s draft, as is
Discuss content for SCs without proposals (Level AAA)
<PhilDay> https://
PhilDay: Based on the AAA SC projec tstatus there's 3
… You did 2.5.6 Bruce
… You also had another one that Laura created, don't see you against any others
PhilDay: Because we haven't had otherpeople drafting these draft, we should probably stop here and I'll work on the other three
… There is also editorial passes to be made
… Also some open comments in the AAA SCs should be worked on
… there are notes in the AAA that should disappear
<PhilDay> https://
<PhilDay> The sections that follow contain guidance on applying the Level AAA success criteria from WCAG 2 to non-web documents and non-web software. The text of each success criterion from WCAG 2 is copied as quoted text. Following that, the WCAG2ICT guidance is provided. The WCAG2ICT guidance can be found in the sections where the headings begin with
<PhilDay> "Applying..." to highlight that this is the content specific to this document. Within these sections custom notes added by WCAG2ICT are marked with the text "ADDED".
<PhilDay> EDITOR'S NOTE
<PhilDay> These two notes apply as written to non-web software and non-web documents.
<PhilDay> From the WCAG 2 Layers of Guidance section of WCAG 2.2:
<PhilDay> Note that even content that conforms at the highest level (AAA) will not be accessible to individuals with all types, degrees, or combinations of disability, particularly in the cognitive, language, and learning areas. Authors are encouraged to consider the full range of techniques, including the advisory techniques, Making Content Usable for
<PhilDay> People with Cognitive and Learning Disabilities, as well as to seek relevant advice about current best practice to ensure that web content is accessible, as far as possible, to this community. Metadata may assist users in finding content most suitable for their needs.
<PhilDay> From the Conformance level section of WCAG 2.2:
<PhilDay> NOTE 1
<PhilDay> It is not recommended that Level AAA conformance be required as a general policy for entire sites because it is not possible to satisfy all Level AAA success criteria for some content.
PhilDay: I am referring to the opening paragraph and the two notes. I think the editor's note needs to be re-written
Daniel: We should probably take another pass with different eyes now that things are more stable
bbailey: I thought we wanted to say something about AAA up at the beginning
… Theere's an issue about this, I started to look at it
bbailey: We may end up having to put some of these things twice
<PhilDay> Guidance in this document
<PhilDay> WCAG2ICT provides informative guidance (guidance that is not normative and does not set requirements) with regard to the interpretation and application of Web Content Accessibility Guidelines (WCAG) to non-web information and communications technologies (ICT). WCAG2ICT is a Working Group Note (in contrast to WCAG 2.0, WCAG 2.1, and WCAG 2.2, which
<PhilDay> are W3C Recommendations). WCAG2ICT provides informative guidance on applying WCAG 2.0, 2.1, and 2.2 Level A and AA success criteria to non-web ICT, including non-web documents and non-web software.
PhilDay: My initial thought is to just add a sentence to say we now include AAA, but we may need something more substantive than that
bbailey: That's the right place.
bbailey: Happy to volunteer for those one or two remaining SCs
PhilDay: Just pick the one you want and I'll take on the other two
PhilDay: Hopefully we'll have the last four SCs for review