Skip to content

Ensure "non-web" is used throughout #694

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 7 commits into from
Jun 26, 2025
Merged
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
2 changes: 1 addition & 1 deletion closed-functionality.md
Original file line number Diff line number Diff line change
Expand Up @@ -23,4 +23,4 @@ These examples are explained more fully in the definition of [closed functionali

Some of these technologies, though closed to some external assistive technologies, often have extensive internal accessibility features that serve as assistive technology that can be used by applications on these devices in the same way assistive technology is used on fully open devices, such as desktop computers. Others are open to some types of assistive technology but not others.</div>

There are existing standards that specify accessibility requirements for both hardware and software aspects of ICT with closed functionality. This document does not comment on those standards, but does note that WCAG success criteria should not be applied to hardware aspects of ICT with closed functionality. WCAG2ICT does provide considerations for applying WCAG success criteria to software on ICT with closed functionality. WCAG2ICT also indicates where and why success criteria might be problematic for non-web software due to the underlying assumptions built into the WCAG success criteria. See [Appendix A: Success Criteria Problematic for Closed Functionality](#success-criteria-problematic-for-closed-functionality) for a list of success criteria for which this is relevant.
There are existing standards that specify accessibility requirements for both hardware and software aspects of ICT with closed functionality. This document does not comment on those standards, but does note that WCAG success criteria should not be applied to hardware aspects of ICT with closed functionality. WCAG2ICT does provide considerations for applying WCAG success criteria to non-web software on ICT with closed functionality. WCAG2ICT also indicates where and why success criteria might be problematic for non-web software due to the underlying assumptions built into the WCAG success criteria. See [Appendix A: Success Criteria Problematic for Closed Functionality](#success-criteria-problematic-for-closed-functionality) for a list of success criteria for which this is relevant.
18 changes: 9 additions & 9 deletions comments-by-guideline-and-success-criterion.md
Original file line number Diff line number Diff line change
Expand Up @@ -110,7 +110,7 @@ This applies directly as written, and as described in [Intent from Understanding

<div class="note wcag2ict">

In software, programmatic determinability is best achieved by using the [accessibility services of platform software](#accessibility-services-of-platform-software) to enable interoperability between software and assistive technologies and accessibility features of software.</div>
In non-web software, programmatic determinability is best achieved by using the [accessibility services of platform software](#accessibility-services-of-platform-software) to enable interoperability between the software and assistive technologies and accessibility features of software.</div>
<div class="note wcag2ict">

See also the [Comments on Closed Functionality](#comments-on-closed-functionality).</div>
Expand Down Expand Up @@ -272,7 +272,7 @@ The intent section refers to the ability for content to reflow (for vertical scr
<div class="note wcag2ict">

Non-web software will have more frequent cases where two-dimensional layout is relied upon for usage or meaning than what occurs on the Web. For example:
- When the software has a complex user interface with toolbars that need to be visible while manipulating content, as explained in the Intent from Understanding 1.4.10 Reflow.</div>
- When the non-web software has a complex user interface with toolbars that need to be visible while manipulating content, as explained in the Intent from Understanding 1.4.10 Reflow.</div>

<div class="note wcag2ict">

Expand All @@ -283,7 +283,7 @@ When the underlying user agent or platform does not support these dimensions for
When users modify zoom, scaling, and/or display resolution at the platform software level (e.g. Operating System), it impacts the size of all applications and the [platform software](#platform-software) itself. This can result in improved readability in some applications but unwanted consequences in others.</div>
<div class="note wcag2ict">

Some software applications provide a mode of operation where reflow is possible, while other modes are unable to reflow. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported. Such software would satisfy this success criterion as long as there is no loss of information or functionality in the drafting view.</div>
Some non-web software applications provide a mode of operation where reflow is possible, while other modes are unable to reflow. An example is a document authoring tool, which includes both a "print preview mode" (without reflow, for users to view the spatial formatting) and a "drafting view mode" where reflow is supported. Such software would satisfy this success criterion as long as there is no loss of information or functionality in the drafting view.</div>
<div class="note wcag2ict">

See also the [Comments on Closed Functionality](#comments-on-closed-functionality).</div>
Expand Down Expand Up @@ -601,7 +601,7 @@ This applies directly as written and as described in [Intent from Understanding

<div class="note wcag2ict">

In software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)</div>
In non-web software, a “link” is any text string or image in the user interface outside a user interface control that behaves like a hypertext link. This does not include general user interface controls or buttons. (An OK button, for example, would not be a link.)</div>

<div class="note wcag2ict">

Expand Down Expand Up @@ -650,7 +650,7 @@ This applies directly as written, and as described in [Intent from Understanding

<div class="note wcag2ict">

In [software](#software), headings and labels are used to describe sections of [content](#content-on-and-off-the-web) and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.</div>
In non-web [software](#software), headings and labels are used to describe sections of [content](#content-on-and-off-the-web) and controls respectively. In some cases it may be unclear whether a piece of static text is a heading or a label. But whether treated as a label or a heading, the requirement is the same: that if they are present they describe the topic or purpose of the item(s) they are associated with.</div>

##### focus-visible

Expand Down Expand Up @@ -690,7 +690,7 @@ This requirement applies to <INS>**[content]**</INS> that interprets pointer act

<div class="note wcag2ict">

Multipoint and path-based gestures are less common in documents. An example where a document author could add such gestures is an interactive prototype document created in a software design tool.</div>
Multipoint and path-based gestures are less common in non-web documents. An example where a non-web document author could add such gestures is an interactive prototype document created in a software design tool.</div>

(for non-web software)

Expand Down Expand Up @@ -874,8 +874,8 @@ With this substitution, it would read:
**3.1.2 Language of Parts:** The [human language](https://www.w3.org/TR/WCAG22/#dfn-human-language-s) of each passage or phrase in the <INS>**[[non-web document](#document) or [software](#software)]**</INS> can be [programmatically determined](#dfn-programmatically-determinable) except for proper names, technical terms, words of indeterminate language, and words or phrases that have become part of the vernacular of the immediately surrounding [text](https://www.w3.org/TR/WCAG22/#dfn-text).

<div class="note wcag2ict">
Examples of programmatic identification include language metadata or markup. There are some [software](#software) and [non-web document](#document) technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the non-web document or software, and it would not be possible to satisfy this success criterion with those technologies.</div>

Examples of programmatic identification include language metadata or markup. There are some [non-web software](#software) and [non-web document](#document) technologies where there is no assistive technology supported method for marking the language for the different passages or phrases in the non-web document or software, and it would not be possible to satisfy this success criterion with those technologies.</div>
<div class="note wcag2ict">

See also the [Comments on Closed Functionality](#comments-on-closed-functionality).</div>
Expand Down Expand Up @@ -1162,7 +1162,7 @@ This success criterion is primarily for software developers who develop or use c
For conforming to this success criterion, it is usually best practice for software user interfaces to use the [accessibility services of platform software](#accessibility-services-of-platform-software). These accessibility services enable interoperability between software user interfaces and both assistive technologies and accessibility features of software in standardized ways. Most platform accessibility services go beyond programmatic exposure of name and role, and programmatic setting of states, properties and values (and notification of same), and specify additional information that could be exposed and / or set (for instance, a list of the available actions for a given user interface component, and a means to programmatically execute one of the listed actions).</div>
<div class="note wcag2ict">

For document formats that support interoperability with assistive technology, standard user interface components often satisfy this success criterion when used according to the general design and accessibility guidance for the document format.</div>
For non-web document formats that support interoperability with assistive technology, standard user interface components often satisfy this success criterion when used according to the general design and accessibility guidance for the document format.</div>
<div class="note wcag2ict">

See also the [Comments on Closed Functionality](#comments-on-closed-functionality).</div>
Expand Down
2 changes: 1 addition & 1 deletion introduction.md
Original file line number Diff line number Diff line change
Expand Up @@ -32,7 +32,7 @@ The Task Force found that the majority of success criteria from WCAG 2 can be ap
When certain web-specific terms or phrases like “web page(s)” were used in success criteria, those were replaced with non-web terms or phrases like “non-web document(s) and software”. Additional notes were also provided to explain the terminology replacements.

A small number of success criteria are written to apply to “a set of web pages” or “multiple web pages” and depend upon all pages in the set to share some characteristic or behavior. Since the unit of conformance in WCAG 2 is a single web page, the task force agreed that the equivalent unit of conformance for non-web documents is a single document. It follows that an equivalent unit of evaluation for a “set of web pages” would be a “set of documents”. Since it isn't possible to unambiguously carve up non-web software into discrete pieces, a single “web page” was equated to a “software program” and a “set of web pages” was equated to a “set of software programs”.  Both of these terms are defined in the Key Terms section of this document. See “[set of documents](#set-of-documents)” and “[set of software programs](#set-of-software-programs)” to determine when a group of documents or pieces of software are considered a set.
<div class="note">Sets of software that meet this definition appear to be extremely rare.</div>
<div class="note">Sets of non-web software that meet this definition appear to be extremely rare.</div>

Not all success criteria have been fully adopted in all local regulations and legislation, and may not be applicable to all technologies. WCAG2ICT has been used in some regulations 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 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 do not apply to non-web documents and non-web software. In addition, EN 301 549 also states that 2.4.2 Page Titled and 3.1.2 Language of Parts do not apply to non-web software. In contrast, the U.S. Department of Justice regulation Nondiscrimination on the Basis of Disability; Accessibility of Web Information and Services of State and Local Government Entities (89 FR 31320, 24 April 2024) directs implementers to utilize the guidance in this document to determine the applicability and how to apply the requirements to mobile applications. Since this document does not specifically say which criteria can or should apply, those implementing this document (WCAG2ICT) should consider the applicability of individual success criteria to non-web documents and software.

Expand Down
2 changes: 1 addition & 1 deletion key-terms.md
Original file line number Diff line number Diff line change
Expand Up @@ -56,7 +56,7 @@ information and sensory experience to be communicated to the user by means of **
</DD></DL>
<div class="note">

Non-web content occurs in two places; documents and software. When content occurs in a document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in software, a separate user agent isn't needed &mdash; the software itself performs that function.</div>
Non-web content occurs in two places; documents and software. When content occurs in a non-web document, a user agent is needed in order to communicate the content's information and sensory experience to the user. When content occurs in non-web software, a separate user agent isn't needed &mdash; the software itself performs that function.</div>
<div class="note">

Content from a third party needs special consideration since sometimes it may be under the control of the author (e.g. contracted and therefore may not be considered 3rd party) and sometimes it is completely out of the control of the author (e.g. email in an email client).</div>
Expand Down
Loading