WCAG2ICT deliverable of Accessibility Guidelines WG
Home Page: https://wcag2ict.netlify.app/
License: Other
This is the repository for WCAG2ICT Task Force. This is the latest editor's draft.
From Success Criterion 2.5.4:
Functionality that can be operated by device motion or user motion can also be operated by user interface components and responding to the motion can be disabled to prevent accidental actuation, except when:
- Supported Interface: The motion is used to operate functionality through an accessibility supported interface;
- Essential: The motion is essential for the function and doing so would invalidate the activity.
4.1.3 Status Messages (Level AA): In content implemented using markup languages, status messages can be programmatically determined through role or properties such that they can be presented to the user by assistive technologies without receiving focus.
that first sentence "In content implemented using markup languages" in practice exempts native applications. I'm not sure this was actually intended? Particularly looking at, say, native apps that show toasts/notifications, this means generally that there's no SC that would apply if those notifications are not announced at all?
Could we define what is meant when we use @@ in the template-for-success-criterion.md.
Example:
From [Success Criterion @@ x.x.x @@](@@ URL for the SC in WCAG 2.2 @@):
In the WCAG2ICT Note from 2013, the Excluded from Scope section has a bullet that is complex to read and could potentially be misunderstood. This should be clarified in the the update to the WCAG2ICT Note.
The current bullet reads:
Because this document deals with applying WCAG, which is a standard for web content accessibility, to ICT it does not deal with such things as closed products and requirements for non-user interface aspects of platforms, nor individual components. As such, this document is not sufficient by itself to ensure accessibility in non-web documents and software.
(state of VoiceOver/Talkback turned on)In iOS explicitly provides a "Cancel" button to close the layer pop-up, Android does not have an explicit way to close the layer pop-up. However, the user can close the layer pop-up with a gesture (two-finger-tap). If gestures are not considered it should be developer to create a completely custom implementation? Or is gesture a mechanism for cancellation? I think this issue is extension of w3c/wcag#1070
iOS:
Android:
I believe that the way that the previous WCAG2ICT Task Force handled the guidance for handling the four SCs that referred to "a set of (or multiple) Web pages" (SCs 2.4.1, 2.4.5, 3.2.3, 3.2.4) to both non-Web software and to non-Web documents needs to be reconsidered.
The team responsible for developing the European EN 301 549 standard were unable to accept the WCAG2ICT guidance for these four SCs and chose to exclude all four of these SCs from the sections dealing with non-Web software and the one dealing with non-Web documents. The U.S. Access Board also chose to exclude the application of these four SCs to non-Web software but did not exclude them for non-Web documents.
Both groups presumably considered that it was of almost zero value, and an unnecessary complication, to include four requirements that were applicable to "a set of software programs" when it was almost impossible to find any real-world examples that met the very specific WCAG2ICT sets of software programs definition. The official European view on why we chose not to apply the four SCs to sets of non-Web documents is contained in the wording notes in EN 301 549 such as:
to explain their absence. There is no doubt that many sets of non-Web documents exist, although the number is less than might be expected when the very restrictive definition of such sets is taken into account.
I am very concerned that the omission of these SCs from the two most influential ICT accessibility standards is failing to address some common accessibility problems relating to consistency of identification and navigation that may frequently occur within the many millions of software and documents that do not belong to WCAG2ICT-defined "sets".
A co-worker made a careful examination of the WCAG Understanding material and identified a lot of material that relates to issues within a web page rather than between web pages in a set of web pages. Some examples are:
I believe that the only practical solution is to entirely eliminate any reference to a "set of software" and a "set of documents" from the Task Force Note and to look for an alternative that does not rely on these concepts. Below is an initial proposal:
3.2.4 Replace "a set of Web pages" with "a non-web document" or "software".
A very simple and highly useful SC when applied to all software and documents.
3.2.3 Replace "on multiple Web pages" with "" and “a set of Web pages” with "a non-web document" or "software".
This seems to me to work fine.
2.4.5 Replace "Web page" with "target destination" replace "a set of Web pages" with "a non-web document" or "software".
This needs a definition of "target destination", but this might not be too difficult - it is what is located i.e. the destination that a link, or other control action jumps to.
2.4.1 Replace "on multiple Web pages" with " within a non-web document" or "software".
This might be a little vague in terms of meaning or testability, but this exact scenario is currently addressed by a note in the understanding text for 2.4.1.
The original 2013 WCAG2ICT Abstract was:
This document, “Guidance on Applying WCAG 2.0 to Non-Web Information and Communications Technologies (WCAG2ICT)” describes how the Web Content Accessibility Guidelines (WCAG) 2.0 WCAG20] and its principles, guidelines, and success criteria can be applied to non-web Information and Communications Technologies (ICT), specifically to non-web documents and software. It provides informative guidance (guidance that is not normative and does not set requirements).
This document is a Working Group Note, and is part of a series of technical and educational documents published by the W3C Web Accessibility Initiative (WAI) and available from the WCAG 2.0 Overview.
Updates needed in the Abstract:
From Success Criterion 1.4.12:
In content implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
This applies directly as written and as described in Intent from Understanding Success Criterion 1.4.12 replacing "In content implemented using markup languages that support" with "For non-web documents or software using markup languages that support"
With these substitutions, it would read:
For non-web documents or software implemented using markup languages that support the following text style properties, no loss of content or functionality occurs by setting all of the following and by changing no other style property:
- Line height (line spacing) to at least 1.5 times the font size;
- Spacing following paragraphs to at least 2 times the font size;
- Letter spacing (tracking) to at least 0.12 times the font size;
- Word spacing to at least 0.16 times the font size.
Exception: Human languages and scripts that do not make use of one or more of these text style properties in written text can conform using only the properties that exist for that combination of language and script.
Note: Markup properties are not always exposed to the user to modify. Software sometimes uses markup languages internally for persistence of the software user interface in ways where the markup is never available to the user. In such cases, the user cannot modify the style properties.
Examples of markup that is used internally for persistence of the software user interface and is never exposed to the user to modify include but are not limited to: XAML and XUL.
// Additional notes for further conversation:
Now, as 1.4.12 is not about providing the method for text spacing but rather, if the user can apply text spacing properties then there should be no loss of functionality or content as @mraccess77 mentioned below, this note could be not necessary because to start with, I don't believe there is a way for the user to apply these styling properties in markup used internally
edited after WCAG2ICT TF conversation.
4.1.1 Parsing, from the previous WCAG2ICT, also refers to markup used internally (although in that case its for markup not exposed to assistive technologies)
In w3c/wcag#1307 the user asks whether iOS accommodation features (specifically assistive touch) are sufficient to support users who lack the ability to easily invoke a drag action.
Part of the AGWG's official response is that such accommodations:
are not universally available and would not qualify as Sufficient Technique for a wider accessibility baseline covering different platforms and user agents.
I think this response poses an interesting scenario we need to consider, and also points to a potential logic puzzle in the development of this SC (and arguably in Pointer Gestures as well).
First, we say that Assistive Touch is not an acceptable support because it is not universal. What if it was/is?
I can see the guidance getting in an odd situation where every touch-OS provides affordances for simple-touch drag and drop, and yet we continue to insist author's solve this. The analogy would be making authors responsible for key repetition and other keyboard operation simplifiers even though they are offered at the OS level (and piggy-backed on by any web author).
This new SC grew from a desire to further the guidance introduced in 2.1 for Pointer Gestures, which itself was the result of the Mobile Accessibility Task Force trying to ensure touch was made more accessible.
I understand the value of encouraging authors to offer simple, single pointer actions. But does this SC become redundant when hardware providers are required to provide single-touch mechanisms (through other standards)? Is that already the case with Android, iOS and Windows 10 systems? When are we placing undue burden on an author for a common interaction already solved by an elegant accessibility setting at the OS level? And when will we know this is reality?
Second, I think there is a related logic puzzle to solve. In this hypothetical, we have a user who cannot do complex gestures but wants to use a touch device. How does the user ever get to the web page where we are insisting simple touch interactions are required? They obviously need to first open and operate their device to even reach a web page. It seems to me there are a few possible answers:
In scenario 1, if the system itself supports simple pointer interactions for all functions, then the need to have SCs that require the same on author-controlled web pages seems critical.
However, it is easy to demonstrate that mobile systems do not meet scenario 1. For instance, the only touch way to scroll inside a mobile touch browser is by flicking or dragging up and down. There is no simple touch equivalent that I am aware of. Therefore, the only ways someone can even view a web page on a mobile touch screen (whose content exceeds the viewport) is to do actions the user in our hypothetical cannot achieve -- or to invoke a different modality, like keyboard operation.
For scenario 2, if the system provides accommodations (accessibility features) that allow someone to complete all functions with simple pointer interactions, then as long as authors invoke those same functions in a way that is supported, there is no need to have the SCs for Pointer Gesture and Dragging in their current state. The user is already able to operate the OS with the accommodations. The SC can be restricted to ensuring authors create content that supports the platform affordances.
For scenario 3, if workarounds exists for some interactions that lack accommodations, the user may or may not be able to reach the web pages, where those workarounds may or may not also work for authoring guidance. The SCs would have value. However, without having requirements for the platform and user agent, the SC requirements are unlikely to solve many of the user issues.
For scenario 4, where devices fail to support touch users with reduced ability, creating requirements for web authors to support touch is not going to matter (for those devices).
I'm not sure we have sufficient research to know what blending of the above scenarios most closely reflects reality, nor what the cost/benefit is of trying to have web authors individually solve interaction challenges that are considerations across a touch device's entire capabilities.
My initial feeling is that SC 1.4.10 reflow would be very difficult to measure on native mobile apps like iOS and Android that are not web-based. Does this SC apply to native mobile apps? If so -- without access to the code are there any suggestions for testing?
When FPWD is being done, update the Technical Reports index.
This is to track work items in preparation for the FPWD publication. We can add to this list whatever's needed:
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.
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.
Four sections to update, most of them will have minimal changes. Not sure we need to have the number of glossary terms, number of SC that apply. Just adds more maintenance once the rest of the document is done and for each release of WCAG.
Somewhat related to w3c/wcag#1550 , I have had a question from a developer working on a Windows desktop application about how to test and assess Reflow on non-web materials.
The WCAG2ICT material has not been updated since 2013. On the web, one relies on the user agent to provide the zoom functionality. So it is easy to know how to assess.
What is the equivalent on a desktop?
@bruce-usab this applies in Revised 508 to software. Do you have any insight into how people are reporting against it?
@DavidMacDonald you feel that Reflow applies to non-web ICT in your https://www.davidmacd.com/WCAG/wcag2ict-21-discussion.html
Anyone have any idea how to assess?
From Success Criterion 1.3.5: Identify Input Purpose:
The purpose of each input field collecting information about the user can be programmatically determined when:
- The input field serves a purpose identified in the Input Purposes for user interface components section; and
- The content is implemented using technologies with support for identifying the expected meaning for form input data.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.5 (also provided below).
Note: non-web software and non-web documents that do not provide attributes that support identifying the expected meaning for the form input data, are not in scope for this success criterion.
Note: for non-web software and non-web documents that present input fields, the terms for the input purposes would be the equivalent terms provided by the technology used.
Still need to change the following links in the 1.4.3 Understanding content because neither WCAG 2.1 nor WCAG 2.2 have working reference links for these documents. Opened WCAG issue 2756 to document these missing links from the WCAG understanding documents.
Originally posted by @maryjom in #18 (comment)
From Success Criterion 2.1.4:
If a keyboard shortcut is implemented in content using only letter (including upper- and lower-case letters), punctuation, number, or symbol characters, then at least one of the following is true:
- Turn off: A mechanism is available to turn the shortcut off;
- Remap: A mechanism is available to remap the shortcut to include one or more non-printable keyboard keys (e.g., Ctrl, Alt);
- Active only on focus: The keyboard shortcut for a user interface component is only active when that component has focus.
Note The WCAG2ICT interpretation is that the WCAG definition of a keyboard shortcut does not include a long press of a key (2 seconds or more) or other accessibility features provided by the platform. See the
[keyboard shortcut](https://w3c.github.io/wcag2ict/#dfn-keyboard-shortcuts)definition for more details.
Need to find out how to properly add WCAG 2.2 documents as citable references. Only WCAG 2.0 [WCAG20] shows up in the list of references. Need to be able to use the following 3 citations in the code:
[<cite><a href="https://w3c.github.io/wcag2ict/#REF-WCAG22">WCAG22</a></cite>]
[<cite><a href="https://w3c.github.io/wcag2ict/#REF-UNDERSTANDING-WCAG22">UNDERSTANDING-WCAG22</a></cite>]
[<cite><a href="https://www.github.io/wcag2ict/#REF-WCAG22-TECHS">WCAG22-TECHS</a></cite>]
Originally posted by @maryjom in #18 (comment)
For other documents that get updated, there are sections describing changes between versions, background/history, etc. Not sure if a Working Group Note typically has them, but these are worth considering:
Prior to public draft publication, write the Comparison section's content to indicate the updates that are in the draft.
This issue is related to #20 which established a placeholder section in the document.
I've been trying to find guidance on SC 1.4.4 (Resize Text) and native apps on iOS and Android.
Both Android OS and iOS support font scaling and display scaling to various degrees. iOS calls the display scaling feature "Display Zoom"; Android calls it "Display Size." (Of note -- I'm not referring to magnification functionality. Also, the display zoom functionality, from what I've seen, is not specifically advertised within the OS as being geared toward a specific group of users with disabilities. Both platforms allow access to it from the general Display settings pane.)
When testing against SC 1.4.4 for native apps, should the display size/zoom feature be taken into consideration? For example, if an app's text can only be resized up to 170% using the OS's font resize setting (let's say the app does not support the OS's largest font sizes, like "huge" and "enormous"), but 200% can be reached by also enabling the display zoom/size feature, would this be a failure?
Copying @mraccess77 and @haltersweb here.
This needs to be carefully considered, as the EN 301 549 already applies most of the SC to closed products (or points to replacement requirements to address that user need). We don't want to cause further splintering and potential for non-harmonization, so there may need to be some more clarity on pitfalls for particular classes of closed products that could be incorporated into the standards.
From Success Criterion 1.3.4: Orientation:
Content does not restrict its view and operation to a single display orientation, such as portrait or landscape, unless a specific display orientation is essential.
NOTE
Examples where a particular display orientation may be essential are a bank check, a piano application, slides for a projector or television, or virtual reality content where content is not necessarily restricted to landscape or portrait display orientation.
This applies directly as written, and as described in Intent from Understanding Success Criterion 1.3.4 (also provided below).
Note: Devices that are fixed in place and have no sensor to detect or ability to change the orientation would be covered under the essential exception and not require software support for orientation changes.
Can wcag2ict address including the supplements? Specifically including Making Content Usable for People with Cognitive and Learning Disabilities
If it is not included at all these groups will be sidelined ongoing.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.
