| A | B | C | D | E | F | G | H | I | J | K | L | M | N | O | P | Q | R | S | T | U | V | W | X | Y | Z | AA | AB | AC | AD | |
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
1 | Success Criteria | WCAG2ICT editorial changes needed? | WCAG2ICT notes changes needed? | Normative SC language changes needed in WCAG2ICT and/or in WCAG? | Notes/Comments What language is problematic? What might be the alternate language? | Notes/Comments for the WCAG2Mobile FPWD | MATF GitHub Issue link | EN 301 549 differences from WCAG2ICT Non-web documents | EN 301 549 differences from WCAG2ICT Non-web software | EN 301 549 differences from WCAG2ICT closed functionality software | WCAG2ICT editorial changes needed? (Yes/No) | WCAG2ICT notes changes needed? (Yes/No) | ||||||||||||||||||
2 | 1.1.1 Non-text content | No change | New note | Propose Change | (Mary Jo) After looking at the MATF document, they have this note: "Not all mobile platforms provide a way to programmatically associate a label with non-text content." Possible non-normative change to WCAG2ICT: Add a similar note with a generalized caveat for software: "Where platform software does not always provide a way to programmatically associate a text alternative for non-text content, it may not be possible for software applications to satisfy this success criterion." (similar to other SCs). * (Mitchell): [OtherMeans] like 4.1.2 Possible normative change to SC language: "Where platform software supports programmatic association of text alternatives for non-text content, all non-text content that is presented to...(the rest of the SC language) * (Mitchell): [OtherMeans] like 4.1.2 Possible new requirement for platform software: This opens up the possibility for a requirement to be developed for platform software to support the ability for software applications to provide programmatic text alternatives for non-text content, including images, videos (to provide a brief name/short description), and sounds. | (Mary Jo) Regarding the note: "Not all mobile platforms provide a way to programmatically associate a label with non-text content." Need to add the following, which is consistent with other criteria that require something that may not be supported fully: "In such situations, it may not be possible for the non-web software to meet this success criterion." (Chris L) 1) https://w3c.github.io/matf/#interpretation-of-web-terminology-in-a-mobile-context states set of screens, and calls out WCAG2ICT on set of software phrasing. Wouldn't the app itself be a set of software? I'm not following the logic they are raising here. 2) Overall comment on use of screen/view terminology when this is under development in WCAG3 and not fully developed is concerning, i.e. The glossary terms “document” and “software” in WCAG2ICT are replaced with the defined terms “screen” and “view”. 3) Closed functionality definition should be consistent across W3C, WCAG, WCAG2ICT and Mobile. Another related term should be defined if WCAG2ICT and Mobile2 vary in definition of term. 4) If WCAG2Mobile doesn't differ from WCAG2ICT, it may be better that they just state that there is no difference rather than listing WCAG 2.x and WCAG2ICT in two different detail/collapsible content containers within the SC definition. 5) Add to the note "not all mobile platforms..." Add in When mobile platforms provide a way to programmatically associate a label with non-text content, that the platform provides that ability to the developer/designer of the app (product). | No | Yes, add a note | ||||||||||||||||||||||
3 | 1.2.1 Audio-only and video-only (prerecorded) | No change | Change notes | No Change | (Mary Jo) MATF has this note: "The alternative can be provided directly in the view – or provided in an alternate version that meets the success criteria." This seems like a technique to meet. Not sure I'd recommend modifying the existing WCAG2ICT note, as it replaces "non-web document or software" with "view" - which seems unnecessary. Proposed change to Note 1: Be more specific of what would be the "alternate version" to say "alternate version of the time-based media". Otherwise it's unclear whether it meant an alternate version of the non-web document or software. | (Mary Jo) Not sure why "view" is needed to be used here. The use of "software" as used in WCAG2ICT sufficiently covers this and similar SCs without making modification to WCAG2ICT. (Chris L.) 1) as stated in 1.1.1's comment in this column, very reluctant to reference https://www.w3.org/TR/wcag-3.0/#dfn-view which is "developing" - term definition : Testing scope that includes all content visually and programmatically available without a significant change. Conceptually, views correspond to the definition of a web page as used in WCAG 2, but are not restricted to content meeting that definition. For example, a view could be considered a “screen” in a mobile app or a layer of web content, such as a modal dialog. | No | No | ||||||||||||||||||||||
4 | 1.2.2 Captions (Prerecorded) | Edits needed | No change | No Change | (Mary Jo) Editorial change to WCAG2ICT note: For the note WCAG2ICT added, need to add a link to definition of "content". | (Mary Jo) When WCAG2ICT adds a link to "content", the MATF document doesn't need to add a note. MATF document would need to add a link to "text alternative" in the note (if it is kept). | Yes, note | No | ||||||||||||||||||||||
5 | 1.2.3 Audio Description or Media Alternative (Prerecorded) | No change | No change | No Change | (Mary Jo) MATF has no notes or open issues. No proposed changes. | (Mary Jo) Nothing needed here. (Chris L) https://www.w3.org/TR/wcag2ict-22/#non-text-content has Note 3 added, while https://w3c.github.io/matf/ only has 2. Also, https://w3c.github.io/matf/ does not number the Notes, when WCAG2ICT does number the notes. (Bruce B) Audio Description on the web continues to have some tension. Should MATF recommend that explicit use of platform mechanism is needed? | No | No | ||||||||||||||||||||||
6 | 1.2.4 Captions (Live) | Edits needed | No change | No Change | (Mary Jo) Editorial change to WCAG2ICT Note: Add a link to definition of "content". | (Mary Jo) When WCAG2ICT adds a link to "content", the MATF document doesn't need to add a note. MATF document would need to add a link to "text alternative" in the note (if it is kept). (ChrisL) 1) https://w3c.github.io/matf/ has NOTE, then Note (Added) vs. WCAG2ICT of NOTE (ADDED) thus if aligning with our format, then this should align and not deviate from our formatting on our note. 2) Unclear why note is present underneath the details collapsible content AND the main content section of the MATF document | Yes | No | ||||||||||||||||||||||
7 | 1.2.5 Audio Description (Prerecorded) | No change | No change | No Change | (Mary Jo) MATF has no notes or open issues. | (Mary Jo) Nothing needed here. (Chris L) https://w3c.github.io/matf/ does not number the Notes, when WCAG2ICT does number the notes. | No | No | ||||||||||||||||||||||
8 | 1.3.1 Info and Relationships | Edits needed | New note | No Change | (Mary Jo) Mobile TF is considering notes to point out limitations in the platform software for providing semantics on all components (e.g. headings, images, etc.) Editorial change: Note 1 - Should probably add links to "software" and "assistive technologies" definitions. Proposed New WCAG2ICT Note: May need a note for software applications to provide programmatic structure and relationships to the extent that the semantics are made available by the platform software. (See MATF Issue #1 - https://github.com/w3c/matf/issues/1). Perhaps taking a cue from the EN 301 549 requirements where I think they provide some wiggle room - see 11.8.1 Content Technology (for authoring tools) where it has the phrasing "to the extent that information required for accessibility is supported by the format used for the output of the authoring tool." Some similar language could be introduced that the "software provides programmatic structure and relationships to the extent that the information required for accessibility is supported by the platform software." | (Mary Jo) If WCAG2ICT makes the suggested change, we can check to make sure this language would resolve the MATF issue #1. | Yes | Maybe | ||||||||||||||||||||||
9 | 1.3.2 Meaningful Sequence | No change | New note | No Change | (Mary Jo) MATF has this note: "Grouping related elements using semantic containers helps ensure a meaningful reading sequence." Proposed New WCAG2ICT Note: The MATF note could be added as a generally applicable note for all software, though it veers close to providing a technique. | (Mary Jo) May want to comment whether MATF is given the leeway to provide techniques in their document, as the draft note they added is very technique-centric. (Chris L) The note provided by MATF could also apply to 1.3.1 in terms of grouping. 2) Definition of semantic containers should be added to the definition of terms in MATF's glossary. | No | Maybe a new note | ||||||||||||||||||||||
10 | 1.3.3 Sensory Characteristics | No change | No change | Propose Change | (Mary Jo) MATF is discussing a potential update to WCAG to add "haptics" to the SC language. We might suggest it in a potential update to either the SC language or in a note in WCAG2ICT which would support the conversation in MATF issue #24 https://github.com/w3c/matf/issues/24. Proposed update to normative language: Include "haptics" or "touch" into the list of sensory characteristics. (Mitchell) I can accept the proposed update. But normative does say "such as" — so I would argue that touch is already covered. (@ Mitchell) Would a note be better? We could add a note: "Because the WCAG success criterion language says "such as", sensory characteristics would also include haptics or touch - even though they are not explicitly listed." We could also ask the AG WG to add a clarification in the SC 1.3.3 understanding document that lists haptics and touch. | (Mary Jo) If the WCAG understanding gets updated or a WCAG2ICT note is added, this would resolve MATF issue #24 without them having to add anything specific for mobile. (Chris L) If MATF is intending to add the techniques, that would go against purpose of the MATF document that states it doesn't provide techniques on how to meet. | No | Maybe SC language change | ||||||||||||||||||||||
11 | 1.3.4 Orientation | No change | New note | Propose Change | (Mary Jo) MATF has the note: "It is considered a best practice to support all available orientations, such as as portrait, portrait (reversed), landscape, and landscape (reversed)." However, I'm not sure how the two reversed orientations help accessibility. Why would you want a UI to be reversed? Seems it would make reading content in the UI very difficult and less accessible. Possible new WCAG2ICT note: It is considered a best practice to support all "available" (or use "platform supported") orientations, such as as portrait, portrait (reversed), landscape, and landscape (reversed). Proposed normative language change: May want to preface the SC language with "Where orientation changes are available for the ICT," to scope out products where there is no possibility of changing the orientation (e.g. kiosks, ATMs, etc.) | (Mary Jo) For accessibility, why require support for reverse landscape and reverse portrait orientations? Seems this is only needed where video is normally shown in reverse and you want to show it reversed so that text can be read. I think this needs more verbiage around that. (Chris L) Portrait reversed and Landscape reversed need to be defined vs. how this differs from content not restricting its view and operation due to a single display orientation. Does MATF mean portrait reversed to have the defined glossary definition of landscape and vice versa on the definition of landscape reversed? If so, state that explicility vs. adding another layer of definition to layout terms. | No | Maybe a new note | ||||||||||||||||||||||
12 | 1.3.5 Identify Input Purpose | No change | Change notes | No Change | (Mary Jo) MATF has an open issue # 2 Proposed WCAG2ICT change to Note 1: Word this similar to EN 301 549 pre-condition clauses: Where non-the web software or non-web document technology does not provide attributes that support identifying the expected meaning for the form input data, this success criterion would be satisfied. | (Chris L) 1) Agree with what Mary Jo raised here. 2) https://github.com/w3c/matf/issues/2 talks to tests and techniques to a degree, where that is not the nature of the MATF's work. I.e. does it apply vs. how to test aspects of charter come in to play. | -- | Yes, note 1 | ||||||||||||||||||||||
13 | 1.4.1 Use of Color | No change | New note | No Change | (Mary Jo) MATF has the following added note: "If a mobile platform’s built-in distinction relies only on color, additional visual means must convey the information." Proposed WCAG2ICT new note: If a software platform’s built-in visual distinction relies only on color, additional visual means must convey the information. | |||||||||||||||||||||||||
14 | 1.4.2 Audio Control | No change | Change notes | No Change | (Mary Jo) MATF changed the WCAG note with different word substitutions than WCAG2ICT. Instead of using "non-web software", they changed the word substitution to "view". Their note says, "Since any view that does not meet this success criterion can interfere with a user's ability to use the whole view, all content in the view (whether it is used to meet other success criteria or not) must meet this success criterion." Proposed WCAG2ICT change to Note 1: Remove first word substitution, as it isn't really needed (or we can leave as-is). WCAG uses "content" which is not web-based language, so that term can stay as-is so it reads, "Since any content that does not meet this success criterion can interfere with a user's ability to use the [whole non-web document or software], all content [in the document or software] (whether or not it is used to meet other success criteria) must meet this success criterion." | (Mary Jo) Disagree with using "view" in the MATF document. There is no need to change the application of the SC to a view. (Chris L) +1 to Mary Jo's point. | ||||||||||||||||||||||||
15 | 1.4.3 Contrast (Minimum) | No change | Change notes | No Change | (Mary Jo) MATF has an open issue #28 https://github.com/w3c/matf/issues/28 which wants to give guidance on pt (used by WCAG to define large text as 18 point regular or 14 point bold) and what these measurements should be for mobile. Possible new WCAG2ICT Note: to provide 18 point regular/14 point bold guidance that would be applicable to non-web software. Mobile issue says pt isn't a measurement used. | (Mary Jo) Same as 1.4.2, Audio control is about the content - not the view. Any "content" that does not meet this success criterion can interfere with a user's ability to use the whole software application. Don't think it is necessary to take this to a more granular "view" concept. (Chris L) Reading through https://github.com/w3c/matf/issues/28, the discussion appears to be more related to thresholds for failing per criteria set vs. whether or not the SC applies to mobile. The "work in progress" should make sure that they are separating out these two goals to align with the MATF charter deliverables and possibly explore techniques / failures as a secondary outcome of their analysis. | ||||||||||||||||||||||||
16 | 1.4.4 Resize Text | | | ?? Need discussion | (Mary Jo) Mobile TF has an open issue #3 https://github.com/w3c/matf/issues/3 which has complex discussions regarding - what "without assistive technology" means without using the built-in text scaling of the chrome browser or platform (an accessibility feature of the platform) vs. assistive technology. - for iOS, there is "Larger Accessibility Size" functionality so a longpress on an icon or button shows it larger. - text scaling is nonlinear and large text scales less (may not get up to 200% at maximum zoom) (so can that even be used to meet the requirement?) WCAG2ICT has an open issue #527 https://github.com/w3c/wcag2ict/issues/527 that MATF opened to get us to clarify "assistive technology" for native mobile. | (Mary Jo) No comment for now...We will have to follow the MATF continuing discussions on Issue 3. | ||||||||||||||||||||||||
17 | 1.4.5 Images of Text | No change | No change | No Change | (Mary Jo) MATF says this applies as written, same for WCAG2ICT. No need for change. | (Mary Jo) No need to comment. | ||||||||||||||||||||||||
18 | 1.4.10 Reflow | No change | Change notes | | (Mary Jo) MATF has an open issue #4 https://github.com/w3c/matf/issues/4 Doesn't yet seem that they'll be changing anything. (bruce) May not be applicable for closed. There is an updated Understanding Reflow soon to publish. (chris) I provided some feedback to Chuck within Oracle on the reflow updates. Not sure if we will take that to W3 to edit the updated understanding or not. Could be applicable here, maybe not. | (Mary Jo) No comment for now...We will have to follow the MATF continuing discussions on Issue 4. (Chris L) The details in https://github.com/w3c/matf/issues/4 are showcasing primarily Android and iOS and not all mobile platforms/frameworks, thus this would need further alignement above and beyond the discussion to date, which involves Mitch's points and JJ's response as of Feb 24. | -- | yes | ||||||||||||||||||||||
19 | 1.4.11 Non-text Contrast | | | ?? Need discussion | (Mary Jo) MATF has an open issue #49 https://github.com/w3c/matf/issues/49 Will have to continue watching their issue to see if they develop any notes we might want to apply more generally. Potential for changes to notes: Might consider adding a note that when there are platform settings to increase contrast that it is a requirement to provide a mode of operation that obeys that setting. But...I think that may go beyond what we need to do. The EN 301 549 and 508 both have that as a separate requirement for native software. | (Mary Jo) No comment for now...We will have to follow the MATF continuing discussions on Issue 49. (Chris L) This discussion on issue 49 appears to be more about what the vendors would do and what they would report on as fails vs. how it would apply in terms of user agents discussion. A lot of this discussion leans on pass/fails of evaluating vs. whether or not in applies to native mobile. Discussion on what is native mobile and what is user agent is an ongoing discussion within the discussion thread. Do we as a group want to subscribe to all of these discussions to monitor or rely on WCAG2Mobile to come to WCAG2ICT with clarity per their reviews? | ||||||||||||||||||||||||
20 | 1.4.12 Text Spacing | Edits needed | New note | Propose Change | (Mary Jo) MATF has different word replacement and removes "implemented using markup languages". I don't think we should go exactly that route, but a change to WCAG2ICT could be helpful. They also have a note saying if the platform doesn't support user changes to the named text style properties, then this SC would not apply. Editorial notes change: Include the WCAG notes in our Applying SC 1.4.12 section so the fact that we added and didn't replace any WCAG notes is clearer. Potential new note (Similar to MATF's last note): If the user agent or platform does not provide a way for users to override text style properties, this success criterion is not applicable. Potential change to the SC normative language: To have a substitution similar to what we had worked on before which was a more substantive change- to apply more broadly, not just software implemented in markup languages. Perhaps also to say instead "]Where the user agent or platform supports user modification of the following text style properties, when those properties are changed,] no loss of content..." | (Mary Jo) - MATF removed the phrase "implemented using markup languages" and now it reads incorrectly. It isn't the content that would support those text style properties, it would have to be the platform that supports them as well as user modification of them...and then the content would be required to abide by those settings. Word replacement should instead be something like "content implemented for platforms" - MATF deleted the 3 WCAG2ICT notes (Notes 1 and 2 were about markup languages), so since they removed the markup language content, so those makes sense.) However, MATF didn't include WCAG2ICT Note 3 which I think still makes sense in the mobile space. We should suggest they include it. - Last MATF note does something normative - says the SC wouldn't apply where the platform doesn't include a way for users to override text style properties. Additionally, this could be misinterpreted that if one of the listed properties don't have a way for the user to modify, and does support others to be modified, this SC wouldn't apply. I don't think that was the intent. IMO, an issue should be opened against WCAG on this - they should have a more generic exception for when a user agent doesn't provide this capability. Chris L - If a mobile platform does not include a way for users to override text style properties, this success criterion is not applicable. is introduced on https://www.w3.org/TR/wcag2mobile-22/#success-criterion-1-4-12-text-spacing and is not specificially mentioned on https://www.w3.org/TR/wcag2ict/#text-spacing . If different, this should be highlighted as per what they are stating currently , it applies directly as written, where they are adding a note , so it doesn't necessarily apply as written as they are changing what is written per mobile vs. wcag2ict. | ||||||||||||||||||||||||
21 | 1.4.13 Content on Hover or Focus | No change | New note | No Change | (Mary Jo) MATF has an open issue #6 https://github.com/w3c/matf/issues/6 They have ongoing research on behavior on mobile platform to see if hover content (like a tooltip) would appear with touch, long press, and if it is possible to connect a mouse on mobile (so you could hover). Potential additional note: Depending on outcome of MATF research, there may need to be a note to say this SC isn't applicable when the user agent or platform software does not support hover content that this SC would not be applicable. | (Mary Jo) No comment for now...We will have to follow the MATF continuing discussions on Issue 6. | ||||||||||||||||||||||||
22 | 2.1.1 Keyboard | No change | Change notes | No Change | (Mary Jo) MATF has an open issue #12 https://github.com/w3c/matf/issues/12 where they plan to test the extent to which keyboard is supported on various platforms (if everything interactive is navigable and operable via keyboard). IMO, this goes beyond what needs to be done. I don't see where any exceptions should be carved out if keyboard support. If the platform has some support issue, then this SC would fail for the reason that the platform has an issue. (Gregg) Current wording of 1 sentence in the NOTE is not understandable unless you know in advance what it is trying to say. So suggest changing the sentence (we can include or exclude API from the second sentence. FROM Platform software may provide device independent input services to applications that enable operation via such a keyboard interface. TO Platform software may provide a ‘keyboard interface’ API that software can read instead of reading the keyboard hardware directly. | (Mary Jo) No comment for now...We will have to follow the MATF continuing discussions on Issue 12. | No | no | ||||||||||||||||||||||
23 | 2.1.2 No Keyboard Trap | No change | No change | No Change | (Mary Jo) MATF has an open issue #30 where they have a question, "Check why WCAG2ICT does not have Non-Interference section." because we removed the note point to conformance requirement 5. Sam | (Mary Jo) No comment for now...We will have to follow the MATF continuing discussions on Issue 30. | no | no | ||||||||||||||||||||||
24 | 2.1.4 Character Key Shortcuts | No change | Change notes | No Change | (Mary Jo) MATF added the following note: "The WCAG2Mobile interpretation aligns with WCAG2ICT, emphasizing that long presses and other accessibility features are not addressed by this success criterion." Potential update to WCAG2ICT note: An example is the long character key press feature offered on mobile platforms to provide accented characters. Such a feature is | (Mary Jo) I think mobile took the WCAG2ICT meaning to be all long presses. This SC is only about long presses of keyboard (or virtual keyboard) keys. In mobile, when a keyboard is active, a long press brings up the list of accented characters for the particular letter pressed. So that feature would not be in scope for this success criterion. Chris L: This applies directly as written, and as described in Intent from Understanding Success Criterion 2.1.4. isn't a true 1:1 against https://www.w3.org/TR/wcag2ict/#applying-sc-2-1-4-character-key-shortcuts-to-non-web-documents-and-software in that the notes from https://www.w3.org/TR/wcag2ict/#applying-sc-2-1-4-character-key-shortcuts-to-non-web-documents-and-software aren't referened in full, Note 2 is not represented in https://www.w3.org/TR/wcag2mobile-22/#success-criterion-2-1-4-character-key-shortcuts | ||||||||||||||||||||||||
25 | 2.2.1 Timing Adjustable | No change | | Propose Change | (Mary Jo) MATF changed the WCAG2ICT word replacement to use "view" instead of "non-web document or software". Potential update to WCAG2ICT word replacement in the SC: We had replaced the word "content" with "non-web document or software. Perhaps if we changed back to use "content" the MATF interpretation wouldn't be needed at all. | (Mary Jo) It is confusing using the word "view" here. Since the MATF document is intended to cover both Web and non-web, shouldn't they be keeping the original WCAG verbiage? I think covering both makes this document rather unclear. Chris L : The styling of https://www.w3.org/TR/wcag2mobile-22/#success-criterion-2-2-1-timing-adjustable differs from WCAG2ICT styling even though it references terms used. WCAG2ICT has bolded text then description of what word means, W2Mobile has text then : then description. Also agree with Mary Jo on view term use. | ||||||||||||||||||||||||
26 | 2.2.2 Pause, Stop, Hide | Edits needed | Change notes | No Change | (Mary Jo) MATF again changed WCAG2ICT word replacements to use "view/views" in Note 2. Proposed editorial changes: Change "on the non-web document or software" to "in the non-web document or software" to read better. Proposed change to note 3: Note uses "user agent". Thinking it needs a word replacement for software. | (Mary Jo) Again "view/views" used. This change from WCAG2ICT isn't really necessary. Chris L : Agreed. | ||||||||||||||||||||||||
27 | 2.3.1 Three Flashes or Below Threshold | Edits needed | Change notes | ?? Need discussion | (Mary Jo) MATF changed WCAG2ICT word replacements to use "view" in SC and in the note. (Mitchell) Discussion needed: Discussion probably needed for screen size and viewing angle. (Mary Jo) Proposed editorial change to the note: Remove the word "whole" from the note. It was in the original WCAG language, but isn't really needed after the word replacements. This would help the EN that splits out documents and software - with documents "whole document" makes sense but with software, "whole software" reads awkwardly. Also change "on the non-web document..." to "in the non-web document...". to read better. (Mary Jo) Proposed change to word replacement for this SC: Proposed change to the word replacements to replace "Web pages" with "content". This could potentially prevent MATF from feeling like this should be "views". (Mary Jo) Potential WCAG normative language change: Suggest we open an issue against WCAG to change normative language in WCAG 3 to simply say "Content does not" or "Web content does not" so that no normative language word replacements are necessary at all when applied outside of the web. | (Mary Jo) Again "view/views" used. This change from WCAG2ICT isn't really necessary. Also, formatting of "whole" and "the" show bold text and these are not replacement words - should not be bold. Chris L : Agreed. | ||||||||||||||||||||||||
28 | 2.4.1 Bypass Blocks | No change | Change notes | | (Mary Jo) MATF has an open issue #8 https://github.com/w3c/matf/issues/8 where they're discussing that hamburger menus/collapsed menus at the top would be a typical mobile method to bypass repeated navigation. They're also discussing the problem is different in Mobile where getting to menus at the bottom of the screen may be more difficult because you've got to navigate through the screen to get to the bottom menu. However, the WCAG SC is all about bypassing navigation mechanisms and repeated info at the top of the page so any requirement for mobile to get to the bottom menu would be a new requirement - not something covered by WCAG. (Bruce) needs context for software (Mary Jo) @ Bruce - Are you suggesting that the SC be applied to non-web software? Where are there problems similar to the web where the nature of software applications and the way you can easily switch between menus and the main content are naturally part of the structure of applications. IMO, most would meet this without doing anything more than they currently have. e.g. Mobile apps have expandable menus (which save space), desktop apps have navigation menus and toolbars with keyboard switching between them (Alt key) built into them. | No comment for now, but will need to watch progress on issue #8. | -- | yes | ||||||||||||||||||||||
29 | 2.4.2 Page Titled | Edits needed | Change notes | ?? Need discussion | (Mary Jo) MATF has an open issue #9 https://github.com/w3c/matf/issues/9 where they'd like to apply this SC to "views", while the EN 301 549 is not applying this SC to software but does apply it to documents and Section 508 applies it to software and documents. These three need to be brought into alignment. Additionally in a 6 Aug. 2024 comment an additional note is proposed which I think could be added. (Mitchell) We currently have this note: > As described in the WCAG intent, the name of a non-web software application or non-web document (e.g. document, media file, etc.) is a sufficient title if it describes the topic or purpose. - Issue 1 (editorial): There has been a long-running debate about whether a brand name can describe topic or purpose. I propose we add a Note explaining there is no problem, in line with my 2025-01-10 comment in https://labs.etsi.org/rep/HF/en301549/-/issues/275 - Issue 2 (normative): I speculate that some platforms could be open, yet have no straightforward way of providing a name or title for software, such as on a gaming device or smart TV. (ed.: I changed "programmatic" to "straightforward" as Mary Jo pointed out the SC does not say programmatic.) Consider proposing normative language to exempt platform limitations, and add a requirement for platforms. [OtherMeans] like 4.1.2 (Gregg) The issue: 2.4.2 says that "Web pages have titles that describe topic or purpose." - We say -for software: Software has titles that describe topic or purpose. - This is impossible to meet for most software programs (they will all fail). For example take these programs - whose titles do not describe their topic or purpose. GIMP, Blender, Calibre, HandBrake, Jitsi, Zotero, (see email for more) https://lists.w3.org/Archives/Public/public-wcag2ict-tf/2025Mar/0017.html). Trademark rules in fact does not allow the use of common descriptions as a trademark name. - There is a note essentially creating an exception or interpretation that does not meet 2.4.2. in Understanding WCAG 2 - but that is not allowed. (can't change the meaning of an SC in a note or other document.) - as such we cannot suggest in a note that the meaning be different than what is in the SC. So adding a note is not something any other standards org can do to fix this - and we should not suggest that as a solution - What was reall intended was that WINDOWS or VIEWS have titles that allow them to be identified from each other. - 3 possible solutions to say for software 1) "Applies with 'windows or views' replacing 'web page'. 2) "Applies with '(programmatically determinable) name' replacing Title 3) "Applies with 'windows or views' replacing 'web page' and '(programmatically determinable) name' replacing Title. The latter would work on windowless environments. For most Tvs (that have no screen readers) they would be closed products and handled like all other closed products. (Mary Jo) @ Gregg I'm not sure we can use "views" yet as this definition is in flux and it won't be fully formed /agreed until WCAG 3 publishes it as a normative definition. A "window" is only useful for platforms that have window environments, and would only cover things like the window name in mobile (for the switch applications feature) but doesn't resolve the divergence in guidance from MATF to apply this to views - something beyond what the current WCAG 2 requires. If the EN 301 549 changes to require this SC or a rewritten version of the SC to be more lenient about using application names (whether or not they are descriptive of what the product does), it would also need to have an exception for closed functionality products. The WCAG SC language does not say the title must be programmatic and there's no definition of "title" term in the glossary that says it has to be programmatic (but it probably should). This would be a normative WCAG change that we can suggest for WCAG 3. There should be a note saying that it's a best practice that the titles be unique names (with unique parts of the name listed first), as the title is used to determine which window or view to switch to, making it easer for the user user can tell multiple instances of the same application apart. Proposed WCAG2ICT change to Note 1: Similar to Mike Pluke's comment from 2 months ago in the GitLab Issue #275 https://labs.etsi.org/rep/HF/en301549/-/issues/275#note_14146 to remove "if it describes the topic or purpose" (which WCAG2ICT adopted when the EN previously had this in it's notes but WCAG's understanding 2.4.2 does not include this phrase and change "is a sufficient title" to "can be a sufficient title" per Mike's suggestion in that same comment (the 2nd from the last one in the issue). This way Note 1 would read: "As described in the WCAG intent, the name of a non-web software application or non-web document (e.g. document, media file, etc. ) can be a sufficient title. Proposed new note from MATF: Note: When software content is presented as separate screens that resemble pages, and the technology supports a separate title for each screen, it is a best practice to provide screen titles and ensure that they describe the topic or purpose of each screen. Where screen titles are provided, a title for the overall software program is still necessary. | No comment for now, but will need to watch progress on issue #9. Chris L will change per outcome of WCAG2ICT discussion. They will have to re-align later on to us or deviate from us. | Success Criterion 2.4.2 - Page Titled - Level A · Issue #9 · w3c/matf · GitHub | |||||||||||||||||||||||
30 | 2.4.3 Focus Order | No change | No change | No Change | (Mary Jo) MATF has an open issue #35 https://github.com/w3c/matf/issues/35 There's nothing concrete here yet to comment on. | No comment for now, but will need to watch progress on issue #35. Chris L Per latest on issue, ACTION: If keyboard interface is replaced with accessibility interface, emphasize the focus logic / differences between keyboard/web and app behavior , so they may deviate on recommendations for app specific design vs. non native mobile (web). We may need to monitor accessibility interface vs. keyboard interface discussion | ||||||||||||||||||||||||
31 | 2.4.4 Link Purpose (In Context) | No change | New note | No Change | (Mary Jo) MATF has an open issue #36 where discussion is similar to Mitchell's points below. Their topic similar to Mitch's point 1 goes into the fact that there are other software constructs that operate similar to a link where the interaction goes to another screen in an application (e.g. activating a button or a menu item). Last week there is a proposal to add two notes. MATF doesn't seem to intend use of WCAG2ICT's Note 1. Proposed new notes in MATF are: "Examples of links in mobile applications include, but are not limited to: list items, menu items, navigation bar items, tab bar items and text hyperlinks." and "It is considered a best practice to ensure the purpose of all controls can be determined." (Mitchell) (1) Are there platforms that do not support a 'link' role? If so, consider a language to achieve a similar intent on such a platform. (2) Programmatic context in web content provides only indirect benefit in most screen readers for web — users typically must explore the document to find the link context, and the bright line that Understanding tries to draw between <p> and <div> is arbitrary. In native code, the mechanisms for providing programmatic context are less well established; this is a possible area for [OtherMeans] (see 4.1.2). (Mary Jo) Proposed new note: Consider adding either the example from the first proposed note from MATF. I don't think the second one is currently useful. | No comment for now, but will need to watch progress on issue #36.Chris L The proposal from April second 2025 states example of links include, but not limited to, list items, menu items, navigation bar items, tab bar items and text hyperlinks. I'd counter that and state that not all of those examples are links in that these "items" can have non linked context within them as well. Also not sure what "items" is defined as within this Mobile context. | ||||||||||||||||||||||||
32 | 2.4.5 Multiple Ways | No change | Change notes | No Change | (Mary Jo) MATF has issue #13 https://github.com/w3c/matf/issues/13 where they are discussing applicability of this SC to mobile and what would be considered "more than one way". However, some apps may not need more than one way. Not sure how this will get carved out, but will need to watch its progress. (Bruce) needs context for documents and software (Mary Jo) Not sure how we'd clearly define when multiple ways are really needed vs. not needed. You don't need multiple ways to get to a dialog box or message. Native software typically has a menu to get to everything you need with help documentation to help you learn where things are. | No comment for now, but will need to watch progress on issue #13.Chris L Discussion mentions "set of app screens" that can stand alone from the "set of apps", detail goes into possibly application within a subgroup of set apps screens. Example that may apply per heavy content is a music app. Example was provided on browse in multiple ways, artists, albums, genres. So in this context, multiple ways would apply and should be written to allow for that affordance. Will continue to watch the discussion. | -- | yes | ||||||||||||||||||||||
33 | 2.4.6 Headings and Labels | No change | New note | No Change | (Mary Jo) MATF has issue #50 https://github.com/w3c/matf/issues/50 on this and it looks like the direction is simply to provide examples of headings and labels in the mobile space. These examples could be included in WCAG2ICT with other platform examples (if needed). Propose to add new note (actually examples): Provide examples of headings and labels in native software using MATF proposed content as some of them. | No comment for now, but will need to watch progress on issue #50. Chris L: The discussion as of April 2 2025 was to possibly introduce notes on labels and headings. I personally don't think it is necessary to define these unless they deviate from web. The intent of the SC is that headings and labels describe topic or purpose. | ||||||||||||||||||||||||
34 | 2.4.7 Focus Visible | No change | No change | No Change | (Mary Jo) MATF has an open issue #51 https://github.com/w3c/matf/issues/51 to discuss any possible guidance. So far they're just investigating the various ways keyboard focus is shown in the UI using keyboard or switch interface. They also mention that some platforms do not provide full capability for authors to modify the focus. It remains to be seen if they'll recommend any changes. | No comment for now, but will need to watch progress on issue #51. Chris L: Mary Jo and Mitch both commented on this being something to validate for in mobile. Mary Jo: This isn't about what the focus cursor looks like, but about whether or not it is visible when an interactive component receives keyboard focus. In WCAG, this was trying to solve the problem where the authored content was turning off the keyboard focus indicator or making it match the background so it wouldn't be visible to the user. IMO, the question to answer here is whether that type of capability exists in the mobile space. and Mitch:In Android apps, pressing TAB with an external keyboard, I fairly often see instances of focus not visible. It can occur when focus moves to an outer container. I don't know what's happening in the code; this is just with black box testing on a stock Google Pixel. So the question is back to the discussion for WCAG2Mobile on developing content for their note | ||||||||||||||||||||||||
35 | 2.4.11 Focus Not Obscured (Minimum) | No change | No change | No Change | (Mary Jo) MATF has an open issue #52 https://github.com/w3c/matf/issues/52 Unknown yet if they'll be wanting to add anything. Beyond that I don't think any changes are needed in the existing WCAG2ICT content. | No comment for now, but will need to watch progress on issue #52. Chris L discussion from last month in issue talks to ACTION: Decide what modes of operation (assistive technologies) are part of "keyboard focus". Per my understanding, keyboard focus is separate from AT focus. | ||||||||||||||||||||||||
36 | 2.5.1 Pointer Gestures | No change | No change | No Change | (Mary Jo) MATF has issue #37 https://github.com/w3c/matf/issues/37 Draft 2.5.1, and their current thoughts are to apply mostly as written, consider notes for: "Underlaying layer", "Custom actions", "Native Controls (e.g. Pull to Refresh)" so we'll have to keep track of this. IMO, no other changes are needed. | No comment for now, but will need to watch progress on issue #37. Chris L WCAG2ICT has Note 3 This requirement applies to [software applications that interpret] pointer actions (i.e. this does not apply to actions that are required to operate the [underlying platform software] or assistive technology). Note 4 (Added) This requirement also applies to platform software, such as user agents, assistive technology software, and operating systems. Each layer is responsible for its own pointer actions only, not for those in an underlying layer. WCAG2Mobile is considering extra notes above and beyond that. | ||||||||||||||||||||||||
37 | 2.5.2 Pointer Cancellation | No change | No change | No Change | (Mary Jo) MATF has Issue #38 https://github.com/w3c/matf/issues/38 Not sure where this one is going quite yet. Keep watching... | No comment for now, but will need to watch progress on issue #38. Chris L Discussion talks to events triggered by down event only per the discussion thread, radio buttons and checkboxes. Per analysis of Chris on the intent, they'd meet the criteria by having an ability to undo the function after completion per Abort or Undo Completion of the function is on the up-event, and a mechanism is available to abort the function before completion or to undo the function after completion; The Mobile taskforce is waiting on WCAG/AG to provide additional context of this intent and application on mobile apps. | ||||||||||||||||||||||||
38 | 2.5.3 Label in Name | No change | Change notes | No Change | (Mitchell) consider a langage change to account for platforms supporting multiple alternate labels on a single control, like iOS and macOS. | |||||||||||||||||||||||||
39 | 2.5.4 Motion Actuation | | | | ||||||||||||||||||||||||||
40 | 2.5.7 Dragging Movements | | | | ||||||||||||||||||||||||||
41 | 2.5.8 Target Size (Minimum) | | | | ||||||||||||||||||||||||||
42 | 3.1.1 Language of Page | | | | (Mitchell) Possibly [OtherMeans] like 4.1.2 | |||||||||||||||||||||||||
43 | 3.1.2 Language of Parts | No change | New note | | (Sam) Can note 1 in 3.1.1 be used for note 1 in this SC? (Mary Jo) This suggested change is to add a note I think? That's not editorial so I modified the answers in the changes needed column to reflect that. (Mitchell) Unfortunately no. In web, lang="subtag" is same on the <html> element as on any other element containing human language. But in native apps, the means of setting a whole app language is generally different from the means of setting language of phrase (if any). [OtherMeans] like 4.1.2. | Yes | ||||||||||||||||||||||||
44 | 3.2.1 On Focus | | Change notes | No Change | bruce - I think we need to add something about the WCAG2 "change of context" definition include possibility of disiorientation. (Mary Jo) @bruce I think this is more than just editorial, unless there are other editorial changes needed you didn't specify, so I changed your editorial changes needed to no and notes changes indicate changes are needed. (Mitchell) What is the gap or the proposed change? | Yes | no | |||||||||||||||||||||||
45 | 3.2.2 On Input | | | | ||||||||||||||||||||||||||
46 | 3.2.3 Consistent Navigation | No change | | Propose Change | [Loïc misunderstood this table as column "c" being suggestions for WCAG - we can ignore this - to be considered for WCAG3] (Loïc: should apply inside single webpages). Repetition of navigational mechanisms can happen in a single webpage and the need for consistency is the same. [[Will try to get examples]] Navigational mechanisms that are repeated **on a page or** on multiple web pages within a set of web pages occur in the same relative order each time they are repeated, unless a change is initiated by the user. | -- | Yes | |||||||||||||||||||||||
47 | 3.2.4 Consistent Identification | No change | No change | Propose Change | [Loïc misunderstood this table as column "c" being suggestions for WCAG - we can ignore this - to be considered for WCAG3] (Loïc: should apply inside single webpages). Propose normative change specific to web and to non-web software: A single web page can contain several components with the same functionality. The need for consistent identification is the same. Components that have the same functionality within **a page or** a set of web pages are identified consistently. In the EN latest draft we have: "11.3.2.4 Consistent identification Where ICT is, or includes, non-web software that provides a user interface, components that have the same functionality within a software program shall be identified consistently, except where not doing so is essential to the function of the software." So we generalised this SC to work for a whole software program, but with an exception (Being inconsistent is essential to the function of the software). | -- | Yes | |||||||||||||||||||||||
48 | 3.2.6 Consistent Help | Edits needed | No change | ?? Need discussion | (bruce) Discussion needed: SC mentions web page and set of web pages. We will also want a quick discussion of the four help mechanisms listed (I think those are okay as-is) (Mary Jo) @bruce What editorial changes are needed? "Web" to "web"? | yes | maybe | |||||||||||||||||||||||
49 | 3.3.1 Error Identification | No change | No change | No Change | (bruce - fine as is) | no | no | |||||||||||||||||||||||
50 | 3.3.2 Labels or Instructions | No change | No change | No Change | (bruce - fine as is) | no | no | |||||||||||||||||||||||
51 | 3.3.3 Error Suggestion | No change | No change | No Change | (bruce - fine as is) | no | no | |||||||||||||||||||||||
52 | 3.3.4 Error Prevention (Legal, Financial, Data) | No change | No change | No Change | (bruce - fine as is) | no | no | |||||||||||||||||||||||
53 | 3.3.7 Redundant Entry | No change | No change | No Change | (bruce - fine as is) | no | no | |||||||||||||||||||||||
54 | 3.3.8 Accessible Authentication (Minimum) | Edits needed | No change | No Change | (bruce) Editorial change to WCAG2ICT word substitution: "user provided to [a Web site, non-web document, or software]." (substitution) maybe should be "the web site, then non-web document, or the non-web software" | yes | no | |||||||||||||||||||||||
55 | 4.1.1 Parsing (Obsolete and removed) | No change | No change | No Change | (Mary Jo) | No | No | |||||||||||||||||||||||
56 | 4.1.2 Name, Role, Value | No change | No change | Propose Change | (Mary Jo) Could have a precondition on this "Where the content is implemented on a platform where there are accessibility services that expose user interface component attributes to assistive technology..." (Mitchell) Is this just another way of saying 'closed', or are otherwise open scenarios where attributes are not exposed? Either way: if we propose language that exempts content because of platform limitations, then we should couple that with language that supports user needs by other means. Compare with EN 301 549 clause 5.2 vs. 11.4.1.3. Here and on other SCs I'm flagging this as [OtherMeans] | No | Yes | |||||||||||||||||||||||
57 | 4.1.3 Status Messages | Edits needed | No change | Propose Change | (Mary Jo) Editorial change to WCAG2ICT Note 1: Also, Note 1 should end in "accessibility services of the platform software, including user agents." We had previously defined a user agent as an example of a platform. (Mitchell) Related: https://labs.etsi.org/rep/HF/en301549/-/issues/448 Proposed normative language change (specific to non-web software - not for WCAG): This could potentially be changed to remove "In content implemented using markup languages" and instead have a pre-condition "Where the platform supports status message notifications that are made programmatically available to assistive technology" or something of that nature. | Yes | Yes | |||||||||||||||||||||||
58 | | | | |||||||||||||||||||||||||||
59 | | | | |||||||||||||||||||||||||||
60 | | | | |||||||||||||||||||||||||||
61 | | | | |||||||||||||||||||||||||||
62 | | | | |||||||||||||||||||||||||||
63 | | | | |||||||||||||||||||||||||||
64 | | | | |||||||||||||||||||||||||||
65 | | | | |||||||||||||||||||||||||||
66 | | | | |||||||||||||||||||||||||||
67 | | | | |||||||||||||||||||||||||||
68 | | | | |||||||||||||||||||||||||||
69 | | | | |||||||||||||||||||||||||||
70 | | | | |||||||||||||||||||||||||||
71 | | | | |||||||||||||||||||||||||||
72 | | | | |||||||||||||||||||||||||||
73 | | | | |||||||||||||||||||||||||||
74 | | | | |||||||||||||||||||||||||||
75 | | | | |||||||||||||||||||||||||||
76 | | | | |||||||||||||||||||||||||||
77 | | | | |||||||||||||||||||||||||||
78 | | | | |||||||||||||||||||||||||||
79 | | | | |||||||||||||||||||||||||||
80 | | | | |||||||||||||||||||||||||||
81 | | | | |||||||||||||||||||||||||||
82 | | | | |||||||||||||||||||||||||||
83 | | | | |||||||||||||||||||||||||||
84 | | | | |||||||||||||||||||||||||||
85 | | | | |||||||||||||||||||||||||||
86 | | | | |||||||||||||||||||||||||||
87 | | | | |||||||||||||||||||||||||||
88 | | | | |||||||||||||||||||||||||||
89 | | | | |||||||||||||||||||||||||||
90 | | | | |||||||||||||||||||||||||||
91 | | | | |||||||||||||||||||||||||||
92 | | | | |||||||||||||||||||||||||||
93 | | | | |||||||||||||||||||||||||||
94 | | | | |||||||||||||||||||||||||||
95 | | | | |||||||||||||||||||||||||||
96 | | | | |||||||||||||||||||||||||||
97 | | | | |||||||||||||||||||||||||||
98 | | | | |||||||||||||||||||||||||||
99 | | | | |||||||||||||||||||||||||||
100 | | | |