https://www.w3.org/WAI/GL/wiki/api.php?action=feedcontributions&feedformat=atom&user=PkornWCAG WG - User contributions [en]2024-03-29T13:19:32ZUser contributionsMediaWiki 1.41.0https://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Lists&diff=2681Using Standard Text Formatting For Lists2013-07-23T23:23:13Z<p>Pkorn: </p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
== Applicability ==<br />
Plain text documents. Not applicable to technologies that contain markup.<br />
<br />
== Description ==<br />
The current [http://www.w3.org/TR/WCAG20-TECHS/T2.html Technique T2] doesn't show in the examples how list items spanning multiple lines in a fixed width document might be rendered. This proposed update to Example 1: Unordered lists shows this, which follows a convention commonly used in UNIX man pages.<br />
<br />
== Examples ==<br />
<br />
===Example 1: Unordered list===<br />
<br />
<pre> <br />
- unordered list item<br />
<br />
- unordered list item that may be quite long and go across multiple<br />
lines of text in a fixed width display, and so appears on <br />
multiple additional lines, each indented the same amount as the<br />
indentation of the first line, after the dash<br />
<br />
- unordered list item<br />
</pre></div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Headings&diff=2680Using Standard Text Formatting For Headings2013-07-23T23:23:05Z<p>Pkorn: </p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
== Applicability ==<br />
Plain text documents. Not applicable to technologies that contain markup.<br />
<br />
== Description ==<br />
The current [http://www.w3.org/TR/WCAG20-TECHS/T3.html Technique T3] doesn't show in the examples a variety of other ways in which headings may be done. This proposed update expands (via replacement) the existing Description text and Tests text, and introduces a new Procedure 2 (along with Example 2 and Test for Procedure 2), which follows a heading convention commonly used in UNIX man pages.<br />
<br />
<br />
== Description ==<br />
<br />
The objective of this technique is to use text formatting conventions to convey the structure of the content. Headings are used to locate and label sections of a text document, showing the organization of the document.<br />
<br />
There are two common ways of indicating headings, described below and also shown in separate examples.<br />
<br />
===Procedure 1: using blank lines===<br />
<br />
The beginning of a heading is indicated by<br />
* two blank lines preceding the heading<br />
<br />
The end of a heading is indicated by<br />
* a blank line following the heading<br />
<br />
A blank line contains any number of non-printing characters, such as space or tab, followed by a new line.<br />
<br />
The programmatic identification of the Heading is the two blank lines preceding it and one blank line succeeding it. Text documents are necessarily void of underlying structure and so structure must be indicated in the programmatic layout for screen readers. This programmatic layout will enable screen readers to voice blank lines twice before the text that will be considered as a heading. A screen magnifier user would decipher headings by visually identifying the space before it (or their technology may have Screen reader capabilities that can identify the spaces).<br />
<br />
<br />
===Procedure 2: ALL CAPS and indentation===<br />
<br />
The beginning of a heading is indicated by<br />
* a blank line preceding the heading<br />
* the heading appearing in ALL CAPS<br />
* the content underneath the heading being uniformly indented<br />
<br />
The end of a heading is indicated by<br />
* a blank line<br />
* the end of the indentation (typically because of the start of another heading)<br />
<br />
A blank line contains any number of non-printing characters, such as space or tab, followed by a new line.<br />
<br />
<br />
== Examples ==<br />
===Example 2: ===<br />
<br />
<pre> <br />
FIRST HEADING<br />
Some content for this first heading.<br />
<br />
SECOND HEADING<br />
Some content for this second heading. This content may span <br />
multiple lines. This content may also be broken up into<br />
multiple paragraphs.<br />
<br />
Content within a heading that spans multiple paragraphs will <br />
follow "T1: Using standard text formatting conventions for<br />
paragraphs" while at the same time also adhering to the <br />
indentation requirement for content within a heading.<br />
<br />
THIRD HEADING<br />
Just as with paragraphs (above), content within a heading<br />
may contain lists. Such lists will likewise follow<br />
"T2: Using standard text formatting conventions for lists"<br />
while at the same time also adhering to the indentation<br />
requirement for content within a heading.<br />
<br />
- First item of an unordered list within a heading<br />
<br />
- Second item of an unordered list within a heading, <br />
which may wrap around to multiple lines or paragraphs.<br />
<br />
</pre><br />
<br />
<br />
== Tests ==<br />
===For Procedure 1===<br />
<br />
For each heading in the content:<br />
<br />
# Check that each heading is preceded by two blank lines<br />
# Check that each heading is followed by a blank line<br />
# Check that no heading contains any blank lines<br />
<br />
===For Procedure 2===<br />
<br />
For each heading in the content:<br />
<br />
# Check that each heading is preceded by one blank line<br />
# Check that each heading is in ALL CAPS<br />
# Check the content within the heading is uniformly indented (except for content that may be also following rules for lists, which also apply the list rules)<br />
<br />
===Expected Results ===<br />
<br />
* All of the checks above are true.<br />
<br />
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.</div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Techniques/Text&diff=2313Techniques/Text2013-04-25T00:02:35Z<p>Pkorn: /* Current Work */</p>
<hr />
<div>[[Category:Techniques]]<br />
<br />
== Current Work ==<br />
<br />
* Proposed update to T2 [[Using Standard Text Formatting For Lists]]<br />
* Proposed update to T3 [[Using Standard Text Formatting For Headings]]<br />
* Proposed new T4 [[Using Standard Text Formatting For Tables]]<br />
<br />
== To Do ==<br />
<br />
* Ensure we are capturing all of the ways to create headings, lists, tables<br />
* Determine whether we need to address pagination (e.g. nroff / troff output for man pages)<br />
* Do we need to include a variant of T4 table formatting for 1.3.2 (columnar output from things like 'ls')?<br />
* Do we need a few Bypass Blocks techniques, covering things like PgDn and searching to skip over repeated headers within a set of man pages?<br />
* Do we need to develop a technique for 3.1.1 language of page? (presumption of same as OS?)<br />
* Do we need techniques for label relationships (e.g. IBM 3270 terminal apps?)<br />
* Do we need techniques that speak to 4.1.2 Name, Role, Value?<br />
<br />
Also see [[:Category:Text Techniques]].</div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Tables&diff=2312Using Standard Text Formatting For Tables2013-04-24T23:56:02Z<p>Pkorn: Created page with "== STATUS == * entered by PeterKorn == Applicability == Plain text documents. Not applicable to technologies that contain markup. This technique relates to: * Success Criterion…"</p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
<br />
== Applicability ==<br />
Plain text documents. Not applicable to technologies that contain markup.<br />
This technique relates to:<br />
* Success Criterion 1.3.1 (Info and Relationships)<br />
** How to Meet 1.3.1 (Info and Relationships)<br />
** Understanding Success Criterion 1.3.1 (Info and Relationships) <br />
<br />
<br />
== Description ==<br />
The objective of this technique is to use text formatting conventions to create tables. Tables are used to display tabular data in columns, so that the contents of a given cell may be clearly associated with other cells sharing the same row or column. Column headers are also clearly discernible. <br />
<br />
There are two procedures for creating tables in plain text documents. Both of these are visually discernible using fixed with characters (these techniques were designed for generation on devices like typewriters, or display on fixed character terminals.<br />
<br />
===Procedure 1: Using character graphics===<br />
<br />
Use character graphics to create the table structure. The underscore character "_" is used for horizontal lines, while the pipe character "|" is used for vertical lines. Column headers are indicated by being centered and in ALL CAPS. If present, row headers are indicated similarly - by being centered an in ALL CAPS. No blank lines are used within each table cell.<br />
<br />
===Procedure 2: Using spacing alignment===<br />
<br />
Use blank space after the contents of each cell such that each column of cells shares the same left alignment within each line of text. If present, column headers are indicated by an initial row, which is then underlined with dash characters "-". This initial row may or may not be similarly aligned; spacing in the dashes is sufficient to demarcate the headers.<br />
<br />
== Examples ==<br />
===Example 1: Using character graphics===<br />
<br />
Example Code:<br />
<pre><br />
<br />
Table with only column headers:<br />
____________________________________________________________<br />
| COL 1 HEADER | COL 2 HEADER |<br />
|_____________________________|_____________________________|<br />
| Contents of first cell | Contents of second cell |<br />
|_____________________________|_____________________________|<br />
| Contents of third cell | Contents of fourth cell |<br />
|_____________________________|_____________________________|<br />
| Contents of fifth cell | Contents of sixth cell |<br />
|_____________________________|_____________________________|<br />
<br />
<br />
Table with column and row headers:<br />
__________________________________________________________________________________________<br />
| | COL 1 HEADER | COL 2 HEADER |<br />
|_____________________________|_____________________________|_____________________________|<br />
| ROW 1 HEADER | Contents of first cell | Contents of second cell |<br />
|_____________________________|_____________________________|_____________________________|<br />
| ROW 2 HEADER | Contents of third cell | Contents of fourth cell |<br />
|_____________________________|_____________________________|_____________________________|<br />
| ROW 3 HEADER | Contents of fifth cell | Contents of sixth cell |<br />
|_____________________________|_____________________________|_____________________________|<br />
</pre><br />
<br />
===Example 2: Using spacing alignment===<br />
<br />
Example Code:<br />
<pre><br />
<br />
Table without column headers (a common UNIX directory listing):<br />
<br />
$ ls<br />
bin etc initrd.img.old lost+found proc selinux usr<br />
boot export lib media RAID-ARRAY srv var<br />
cdrom home lib32 mnt root sys vmlinuz<br />
dev initrd.img lib64 opt sbin tmp vmlinuz.old<br />
<br />
<br />
Table with aligned column headers (a common UNIX filesystem listing):<br />
<br />
$ df -h<br />
Filesystem Size Used Avail Use% Mounted on<br />
/dev/sda2 40G 8.8G 29G 24% /<br />
none 748M 288K 748M 1% /dev<br />
none 752M 916K 751M 1% /dev/shm<br />
none 752M 552K 752M 1% /var/run<br />
none 752M 0 752M 0% /var/lock<br />
none 752M 0 752M 0% /lib/init/rw<br />
none 40G 8.8G 29G 24% /var/lib/ureadahead/debugfs<br />
/dev/md0 466G 396G 71G 85% /RAID-ARRAY<br />
/dev/sda1 962M 81M 832M 9% /boot<br />
/dev/sda4 185G 188M 176G 1% /export<br />
<br />
<br />
Table with underlined column headers (a common network connection listing):<br />
<br />
$ netstat<br />
Active Connections<br />
<br />
Proto Local Address Foreign Address State<br />
------ ---------------------- ---------------------- ----------------<br />
TCP 127.0.0.1:5354 lightnin:49157 ESTABLISHED<br />
TCP 127.0.0.1:5354 lightnin:61839 ESTABLISHED<br />
TCP 127.0.0.1:5354 lightnin:61843 ESTABLISHED<br />
TCP 127.0.0.1:5354 lightnin:61844 ESTABLISHED<br />
TCP 127.0.0.1:27015 lightnin:49165 ESTABLISHED<br />
TCP 127.0.0.1:27015 lightnin:61851 ESTABLISHED<br />
TCP 127.0.0.1:27015 lightnin:61881 ESTABLISHED<br />
TCP 127.0.0.1:49157 lightnin:5354 ESTABLISHED<br />
TCP 127.0.0.1:49165 lightnin:27015 ESTABLISHED<br />
TCP 127.0.0.1:49208 lightnin:49209 ESTABLISHED<br />
TCP 127.0.0.1:49209 lightnin:49208 ESTABLISHED<br />
TCP 127.0.0.1:49343 lightnin:49344 ESTABLISHED<br />
TCP 127.0.0.1:49344 lightnin:49343 ESTABLISHED<br />
</pre><br />
<br />
== Resources ==<br />
<br />
No resources available for this technique.<br />
<br />
== Related Techniques ==<br />
<br />
(none currently listed)<br />
<br />
== Tests ==<br />
===Procedure 1===<br />
<br />
TO BE WRITTEN<br />
<br />
===Procedure 2===<br />
<br />
TO BE WRITTEN<br />
<br />
===Expected Results===<br />
<br />
*All checks above are all true.<br />
<br />
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.</div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Lists&diff=2311Using Standard Text Formatting For Lists2013-04-24T23:22:39Z<p>Pkorn: </p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
== Applicability ==<br />
Plain text documents. Not applicable to technologies that contain markup.<br />
<br />
== Description ==<br />
The current [http://www.w3.org/TR/WCAG20-TECHS/T3.html Technique T3] doesn't show in the examples a variety of other ways in which headings may be done. This proposed update expands (via replacement) the existing Description text and Tests text, and introduces a new Procedure 2 (along with Example 2 and Test for Procedure 2), which follows a heading convention commonly used in UNIX man pages.<br />
<br />
<br />
== Description ==<br />
<br />
The objective of this technique is to use text formatting conventions to convey the structure of the content. Headings are used to locate and label sections of a text document, showing the organization of the document.<br />
<br />
There are two common ways of indicating headings, described below and also shown in separate examples.<br />
<br />
===Procedure 1: using blank lines===<br />
<br />
The beginning of a heading is indicated by<br />
* two blank lines preceding the heading<br />
<br />
The end of a heading is indicated by<br />
* a blank line following the heading<br />
<br />
A blank line contains any number of non-printing characters, such as space or tab, followed by a new line.<br />
<br />
The programmatic identification of the Heading is the two blank lines preceding it and one blank line succeeding it. Text documents are necessarily void of underlying structure and so structure must be indicated in the programmatic layout for screen readers. This programmatic layout will enable screen readers to voice blank lines twice before the text that will be considered as a heading. A screen magnifier user would decipher headings by visually identifying the space before it (or their technology may have Screen reader capabilities that can identify the spaces).<br />
<br />
<br />
===Procedure 2: ALL CAPS and indentation===<br />
<br />
The beginning of a heading is indicated by<br />
* a blank line preceding the heading<br />
* the heading appearing in ALL CAPS<br />
* the content underneath the heading being uniformly indented<br />
<br />
The end of a heading is indicated by<br />
* a blank line<br />
* the end of the indentation (typically because of the start of another heading)<br />
<br />
A blank line contains any number of non-printing characters, such as space or tab, followed by a new line.<br />
<br />
<br />
== Examples ==<br />
===Example 2: ===<br />
<br />
<pre> <br />
FIRST HEADING<br />
Some content for this first heading.<br />
<br />
SECOND HEADING<br />
Some content for this second heading. This content may span <br />
multiple lines. This content may also be broken up into<br />
multiple paragraphs.<br />
<br />
Content within a heading that spans multiple paragraphs will <br />
follow "T1: Using standard text formatting conventions for<br />
paragraphs" while at the same time also adhering to the <br />
indentation requirement for content within a heading.<br />
<br />
THIRD HEADING<br />
Just as with paragraphs (above), content within a heading<br />
may contain lists. Such lists will likewise follow<br />
"T2: Using standard text formatting conventions for lists"<br />
while at the same time also adhering to the indentation<br />
requirement for content within a heading.<br />
<br />
- First item of an unordered list within a heading<br />
<br />
- Second item of an unordered list within a heading, <br />
which may wrap around to multiple lines or paragraphs.<br />
<br />
</pre><br />
<br />
<br />
== Tests ==<br />
===For Procedure 1===<br />
<br />
For each heading in the content:<br />
<br />
# Check that each heading is preceded by two blank lines<br />
# Check that each heading is followed by a blank line<br />
# Check that no heading contains any blank lines<br />
<br />
===For Procedure 2===<br />
<br />
For each heading in the content:<br />
<br />
# Check that each heading is preceded by one blank line<br />
# Check that each heading is in ALL CAPS<br />
# Check the content within the heading is uniformly indented (except for content that may be also following rules for lists, which also apply the list rules)<br />
<br />
===Expected Results ===<br />
<br />
* All of the checks above are true.<br />
<br />
If this is a sufficient technique for a success criterion, failing this test procedure does not necessarily mean that the success criterion has not been satisfied in some other way, only that this technique has not been successfully implemented and can not be used to claim conformance.</div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Headings&diff=2310Using Standard Text Formatting For Headings2013-04-24T23:07:35Z<p>Pkorn: Created page with "== STATUS == * entered by PeterKorn == Applicability == Plain text documents. Not applicable to technologies that contain markup. == Description == The current [http://www.w3.o…"</p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
== Applicability ==<br />
Plain text documents. Not applicable to technologies that contain markup.<br />
<br />
== Description ==<br />
The current [http://www.w3.org/TR/WCAG20-TECHS/T2.html Technique T2] doesn't show in the examples how list items spanning multiple lines in a fixed width document might be rendered. This proposed update to Example 1: Unordered lists shows this, which follows a convention commonly used in UNIX man pages.<br />
<br />
== Examples ==<br />
<br />
===Example 1: Unordered list===<br />
<br />
<pre> <br />
- unordered list item<br />
<br />
- unordered list item that may be quite long and go across multiple<br />
lines of text in a fixed width display, and so appears on <br />
multiple additional lines, each indented the same amount as the<br />
indentation of the first line, after the dash<br />
<br />
- unordered list item<br />
</pre></div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Lists&diff=2309Using Standard Text Formatting For Lists2013-04-24T23:07:24Z<p>Pkorn: </p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
== Applicability ==<br />
Plain text documents. Not applicable to technologies that contain markup.<br />
<br />
== Description ==<br />
The current [http://www.w3.org/TR/WCAG20-TECHS/T3.html Technique T3] doesn't show in the examples a variety of other ways in which headings may be done. This proposed update expands (via replacement) the existing Description text, and introduces a new Example 2, which follows a heading convention commonly used in UNIX man pages.<br />
<br />
<br />
== Description ==<br />
<br />
The objective of this technique is to use text formatting conventions to convey the structure of the content. Headings are used to locate and label sections of a text document, showing the organization of the document.<br />
<br />
There are two common ways of indicating headings, described below and also shown in separate examples.<br />
<br />
===Technique 1: using blank lines===<br />
<br />
The beginning of a heading is indicated by<br />
* two blank lines preceding the heading<br />
<br />
The end of a heading is indicated by<br />
* a blank line following the heading<br />
<br />
A blank line contains any number of non-printing characters, such as space or tab, followed by a new line.<br />
<br />
The programmatic identification of the Heading is the two blank lines preceding it and one blank line succeeding it. Text documents are necessarily void of underlying structure and so structure must be indicated in the programmatic layout for screen readers. This programmatic layout will enable screen readers to voice blank lines twice before the text that will be considered as a heading. A screen magnifier user would decipher headings by visually identifying the space before it (or their technology may have Screen reader capabilities that can identify the spaces).<br />
<br />
<br />
===Technique 2: ALL CAPS and indentation===<br />
<br />
The beginning of a heading is indicated by<br />
* a blank line preceding the heading<br />
* the heading appearing in ALL CAPS<br />
* the content underneath the heading being uniformly indented<br />
<br />
The end of a heading is indicated by<br />
* a blank line<br />
* the end of the indentation (typically because of the start of another heading)<br />
<br />
A blank line contains any number of non-printing characters, such as space or tab, followed by a new line.<br />
<br />
<br />
== Examples ==<br />
===Example 2: ===<br />
<br />
<pre> <br />
FIRST HEADING<br />
Some content for this first heading.<br />
<br />
SECOND HEADING<br />
Some content for this second heading. This content may span <br />
multiple lines. This content may also be broken up into<br />
multiple paragraphs.<br />
<br />
Content within a heading that spans multiple paragraphs will <br />
follow "T1: Using standard text formatting conventions for<br />
paragraphs" while at the same time also adhering to the <br />
indentation requirement for content within a heading.<br />
<br />
THIRD HEADING<br />
Just as with paragraphs (above), content within a heading<br />
may contain lists. Such lists will likewise follow<br />
"T2: Using standard text formatting conventions for lists"<br />
while at the same time also adhering to the indentation<br />
requirement for content within a heading.<br />
<br />
- First item of an unordered list within a heading<br />
<br />
- Second item of an unordered list within a heading, <br />
which may wrap around to multiple lines or paragraphs.<br />
<br />
</pre></div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Lists&diff=2308Using Standard Text Formatting For Lists2013-04-24T22:51:28Z<p>Pkorn: </p>
<hr />
<div>== STATUS ==<br />
* entered by PeterKorn<br />
<br />
== Applicability ==<br />
Standard Text documents, which lack markup<br />
<br />
== Description ==<br />
The current [http://www.w3.org/TR/WCAG20-TECHS/T2.html Technique T2] doesn't show in the examples how list items spanning multiple lines in a fixed width document might be rendered. This proposed update to Example 1: Unordered lists shows this, which follows a convention commonly used in UNIX man pages.<br />
<br />
== Examples ==<br />
<br />
===Example 1: Unordered list===<br />
<br />
<pre> <br />
- unordered list item<br />
<br />
- unordered list item that may be quite long and go across multiple<br />
lines of text in a fixed width display, and so appears on <br />
multiple additional lines, each indented the same amount as the<br />
indentation of the first line, after the dash<br />
<br />
- unordered list item<br />
</pre></div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Using_Standard_Text_Formatting_For_Lists&diff=2307Using Standard Text Formatting For Lists2013-04-24T22:45:58Z<p>Pkorn: Created page with "The current [http://www.w3.org/TR/WCAG20-TECHS/T2.html Technique T2] doesn't show in the examples how list items spanning multiple lines in a fixed width document might be render…"</p>
<hr />
<div>The current [http://www.w3.org/TR/WCAG20-TECHS/T2.html Technique T2] doesn't show in the examples how list items spanning multiple lines in a fixed width document might be rendered. This proposed update to Example 1: Unordered lists shows this, which follows a convention commonly used in UNIX man pages.<br />
<br />
<br />
Example 1: Unordered list<br />
<br />
Example Code:<br />
<br />
<br />
- unordered list item<br />
<br />
- unordered list item that may be quite long and go across multiple<br />
lines of text in a fixed width display, and so appears on <br />
multiple additional lines, each indented the same amount as the<br />
indentation of the first line, after the dash<br />
<br />
- unordered list item</div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Techniques/Text&diff=2306Techniques/Text2013-04-24T22:41:11Z<p>Pkorn: </p>
<hr />
<div>[[Category:Techniques]]<br />
<br />
== Current Work ==<br />
<br />
* Proposed update to T2 [[Using Standard Text Formatting For Lists]]<br />
* Proposed update to T3 [[Using Standard Text Formatting For Headings]]<br />
* Proposed new T4 [[Using Standard Text Formatting For Tables]]<br />
<br />
Also see [[:Category:Text Techniques]].</div>Pkornhttps://www.w3.org/WAI/GL/wiki/index.php?title=Set_of_Documents&diff=1793Set of Documents2012-12-12T22:33:01Z<p>Pkorn: </p>
<hr />
<div>=Definition of "set of documents"=<br />
<br />
In response to the WCAG request to move the definition of “set of documents” out of the notes for 2.4.1, 2.4.5, and 3.2.3, we propose the following change/addition to the section on Key Terms and the three SC that use it.<br />
<br />
(Note: you can see the [https://sites.google.com/site/wcag2ict/home/introduction-to-wcag2ict-application-note proposal with changes marked] as proposal #6.)<br />
<br />
==Key Terms==<br />
<br />
There are several terms used throughout WCAG 2.0 that need to be interpreted differently when applied to non-Web ICT. These include: “content”, and “user agent”. Further, the term “Web page” in WCAG 2.0 is replaced with newly defined terms “document” and “software”, and both "set of web pages" and "multiple web pages" are replaced with the newly defined term "set of documents”.<br />
<br />
Further information on usage of these terms follows.<br />
<br />
[keep existing term explanations with the following new one on "set of non-web documents" at the appropriate place alphabetically]<br />
<br />
set of non-web documents (as used in WCAG2ICT)<br />
<br />
group of documents that are published together, and where the items all refer to each other by name or link.<br />
<br />
Note 1: Republishing or bundling previously published documents as a collection does not constitute a set of documents.<br />
<br />
Note 2: If a set is broken apart, the individual parts are no longer part of a set, and would be evaluated as any other individual documents.<br />
<br />
One example of a set of documents would be a three-part report where each part is a separate file. At the beginning of each file the table of contents for "navigating" to the other parts is repeated.<br />
<br />
==For SC 2.4.1==<br />
Additional guidance when applying Success Criterion 2.4.1 to non-web Documents and Software:<br />
<br />
For Documents:<br />
<br />
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web pages” with “documents within a set of non-web documents”<br />
<br />
With these substitutions, it would read:<br />
<br />
2.4.1 Bypass Blocks: A mechanism is available to bypass blocks of content that are repeated on multiple documents within a set of non-web documents.<br />
<br />
For Software:<br />
<br />
The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 2.4.1.<br />
<br />
==For SC 2.4.5==<br />
<br />
Additional guidance when applying Success Criterion 2.4.5 to non-web Documents and Software:<br />
<br />
For Documents:<br />
<br />
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “Web page” with “document” and "set of Web pages" with "set of non-web documents"<br />
<br />
With these substitutions, it would read:<br />
<br />
2.4.5 Multiple Ways: More than one way is available to locate a document within a set of non-web documents except where the document is the result of, or a step in, a process.<br />
<br />
Note 1: Authors should assume that an infrastructure exists to allow a user to locate documents in the set; for example, by selecting links within a member of the set, browsing through the files that make up the set, or by searching within members of the set for the names of the other members.<br />
<br />
Note 2: A file directory would be the equivalent of a site map for documents in that it provides a link to each of the documents in the set of documents. The directory also acts as the HOME for the set.<br />
<br />
Note 3: A search function in a file system (that finds documents) would be equivalent to a Web search function for Web pages.<br />
<br />
Note 4: Authors can assume that the non-Web documents will be stored and accessed on a major operating system with browse and search abilities unless they have specific information to the contrary.<br />
<br />
For Software:<br />
<br />
The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 2.4.5.<br />
<br />
==For SC 3.2.3==<br />
<br />
Additional guidance when applying Success Criterion 3.2.3 to non-web Documents and Software:<br />
<br />
For Documents:<br />
<br />
This applies as written and described in INTENT of Understanding WCAG 2.0 (above), replacing “multiple Web pages” with “multiple documents” and "set of Web pages" with "set of non-web documents".<br />
<br />
With these substitutions, it would read:<br />
<br />
3.2.3 Consistent Navigation: Navigational mechanisms that are repeated on multiple documents within a set of non-web documents occur in the same relative order each time they are repeated, unless a change is initiated by the user.<br />
<br />
For Software:<br />
<br />
The WCAG2ICT Task Force has not yet produced additional guidance for software for Success Criterion 3.2.3.</div>Pkorn