Meeting minutes
w3c/wcag2ict#328
Lots of changes, but mostly editorial, so don't need to take back to the TF
w3c/wcag2ict#328
Lots of changes, but mostly editorial, so don't need to take back to the TF
issue 145
<maryjom> w3c/
Latest from issue conversation: taken from loic's input, and Gregg's comments on that.
Not all success criteria have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. WCAG2ICT was also used to determine whether or not to apply certain success criteria.
… For example, some local standards such as Section 508 in the US, and EN 301 549 in Europe, state that non-Web documents and non-Web software do not need to comply with WCAG 2.0 Success Criteria 2.4.1 Bypass Blocks, 2.4.5 Multiple Ways, 3.2.3 Consistent Navigation, and 3.2.4 Consistent Identification.
… In addition, EN 301 549 also states that non-Web software does not need to comply with 2.4.2 Page titled and 3.1.2 Language of parts. Regulators should consider the applicability of individual success criteria to non-web documents and software.
Direct link: w3c/
Question is where this should be put in the document
https://
But this is now a long section
So may need another sub-heading; maybe "Applicability of success criteria"
bruce_bailey: Suggest inserting this new text after note 2 in the Guidance section.
Discussion about inserting as a NOTE to draw attention to text
Or sub headings
Guidance is H3, so could add as H4
Proposal for sub heading: Terminology in a non-web context
Then include text from "The Task Force found" to end of NOTE 2
Plus the new text about local regulations & legislation
<bruce_bailey> Interpretation of web terminology in a non-web context
w3c/
For adding to the 5 SCs: Regulators should consider the applicability of individual success criteria to non-web documents and software.
bruce_bailey: Spotted a bug in reference to Key Terms in the Introduction, but Key Terms is not in Introduction - so just refer to Key Terms
In Applying SC 2.4.1. NOTE 1
Issue 4
Requires PR by Bruce.
Not completed yet - needs more work
Lots of merge conflicts that had to be managed - so needs some more sanity checking
Issue 4
There is an issue open in AG WG on Resize Text as well.
What if your platform doesn't support 200%?
Similar in non-web context.
More recent discussion: https://
<maryjom> https://
Current editor's draft content in link above
Applying SC 1.4.4 Resize Text to Non-Web Documents and Software
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.4.4.
NOTE 1
Content for which there are software players, viewers or editors with a 200 percent zoom feature would automatically meet this success criterion when used with such players, unless the content will not work with zoom.
NOTE 2
The Intent section refers to the ability to allow users to enlarge the text on screen at least up to 200% without needing to use assistive technologies. This means that the application provides some means for enlarging the text 200% (zoom or otherwise) without loss of content or functionality or that the application works with the platform features
that meet this requirement.
NOTE 3
See also the Comments on Closed Functionality.
https://
https://
G142 is web specific
"The objective of this technique is to ensure content can be scaled uniformly by using a Web technology supported by user agents that change text size via a Zoom tool."
Reflow content for reference: Option 3A: Mitchell’s edits to Option 3 (to replace current editor’s draft’s Notes 6 & 7)
NOTE 6: As written, this success criterion can only be met by non-web documents or software where the underlying user agent or platform can present content at a width equivalent to 320 CSS pixels for vertical scrolling content and a height equivalent to 240 CSS pixels for horizontal scrolling content.
When the underlying user agent or platform does not support these dimensions for scrolling, reflow is encouraged as this capability is important to persons with low vision. As a reasonable benchmark, evaluate at the nearest size to what the Reflow success criterion specifies.
For platforms that do not support zoom, scrolling, and reflow, user needs such as low vision are often addressed by other means (including but not limited to using sufficiently large text and single screen designs).
From Google doc: https://
<bruce_bailey> ADA, 508, EN 301 549, ACAA -- for kiosks a minimum (largish) font size it the requirement.
<bruce_bailey> Supporting resize for software driving kiosk is not necessary and counter productive.
<bruce_bailey> Pinch to Zoom on mobile meets 1.4.4 resize text, on its face.
+1 to Bruce's comments on kiosks/ATMs/fare machines
Chuck: Add or statement to end of NOTE 2
… I'm not sure that I caught the full content of Chuck's suggestion
<bruce_bailey> G142 for OS features, like pinch to zoom
<bruce_bailey> Using a technology that has commonly-available user agents that support zoom
Chuck: to the extent that such features exist in the platform
This is what we have in SC problematic for closed: 1.4.4 Resize Text—because the text rendering support in a closed environment may be more limited than the support found in user agents for the Web, meeting Success Criterion 1.4.4 in a closed environment may place a much heavier burden on the content author;
Add generic statement at top of closed functionality: Regulators should consider the applicability of individual success criteria to non-web documents and software. See section [ref to the new section at end of guidance section]
<bruce_bailey> VA applied WCAG to kiosks AFTER wcag2ict and 508, so i think it needs to be explicit
<bruce_bailey> s/wcag2ictt/wcag2ict