W3C/WAI Comments on JIS Web Accessibility Draft

Comments Submitted in Response to the Japanese Industry Standard DRAFT 
"Guidelines for older persons and persons with disabilities: Information 
communication equipment and services, Part 3: Web contents"

Submitted to the Japanese Industrial Standards Association
November 27, 2003

Comments Submitted by:

Wendy Chisholm
Web Accessibility Specialist
Web Accessibility Initiative
World Wide Web Consortium
+1.206.706.5263
wendy@w3.org

Judy Brewer
Director
Web Accessibility Initiative
World Wide Web Consortium
+1.617.258.9741
jbrewer@w3.org

Matt May
Web Accessibility Specialist
Web Accessibility Initiative
World Wide Web Consortium
+1.206.547.2109
mcmay@w3.org

--------------
CONTENTS:
1. Introduction
2. Background on Commenting Organization
3. General Comments and Suggested Actions
4. Technical Comments and Suggested Actions
5. References
--------------

1. INTRODUCTION

Thank you for the opportunity to comment on the JIS "Guidelines for older 
persons and persons with disabilities: Information communication equipment 
and services, Part 3: Web contents" -- referred to in our comments below as 
"JIS Guidelines."

The following comments are on an English translation of the October 09, 
2003 Draft from JIS Working Group 2. We appreciate that JIS has made this 
English translation available for public comment by international 
organizations.

In addition, we appreciate the additional time to prepare our comments, 
which allowed us to incorporate information from the Web Content 
Accessibility Guidelines Working Group meeting in Shin-Yokohama this past 
weekend. However, despite the additional time, our comments are in places 
still incomplete. We therefore particularly welcome any questions or 
requests for additional clarification on the suggestions that we make in 
our comments. We would warmly welcome the opportunity for further discussion.

The opinions stated herein are those of the authors and do not necessarily 
reflect the views of the funding organizations of the Web Accessibility 
Initiative, nor of its host organizations, nor the WCAG Working Group.

Our comments provide a brief background on W3C/WAI; then address the 
importance of standards harmonization towards achieving the goal of an 
accessible Web; and finally address suggestions for specific changes in the 
JIS draft which might increase harmonization of JIS with existing W3C/WAI 
international standards.


2. BACKGROUND ON COMMENTING ORGANIZATION

The World Wide Web Consortium (W3C) [1] is an international, 
vendor-neutral, primarily industry consortium, hosted by Keio University in 
Japan; Massachusetts Institute of Technology (MIT) in the U.S.; and the 
European Research Consortium for Informatics and Mathematics (ERCIM) in 
France. W3C promotes interoperability and universality of the Web.

Among its other activities, the W3C hosts the Web Accessibility Initiative 
(WAI) [2], which is also international in focus and which develops 
solutions on a number of levels for accessibility of the Web. WAI's work 
includes ensuring accessibility of the core technologies of the Web such as 
HTML, CSS, and XML; developing guidelines for accessibility of Web sites 
and Web applications; developing tools to facilitate Web accessibility; 
conducting education and outreach activities to promote awareness of and 
provide training on Web accessibility; and coordinating with research and 
development which can affect future accessibility of the Web.

As part of its activities over the past six years, WAI has developed a set 
of three complementary guidelines for Web accessibility. The first of 
these, the Web Content Accessibility Guidelines 1.0 (WCAG 1.0) [3] 
addresses accessibility of Web sites. The second, Authoring Tool 
Accessibility Guidelines 1.0 (ATAG 1.0) [4] addresses developers of 
software used to make Web sites, explaining how to develop tools which 
facilitate the production of accessible content, and how to ensure that the 
tools themselves are usable by people with disabilities. The third, the 
User Agent Accessibility Guidelines 1.0 (UAAG 1.0) [5], addresses 
accessibility of browsers, media players, and their interoperability with 
assistive technologies. These three W3C/WAI guidelines form a complementary 
set of solutions for accessibility of the Web.

WCAG 1.0 has been directly adopted or referenced in Australia, Canada, the 
European Union, and forms the basis of US Section 508 1194.22.

Currently there is an extensive international effort through W3C/WAI 
Working Groups, including effort from industry, the disability community, 
accessibility researchers and government, on development of a second 
generation of W3C/WAI guidelines, drawing on implementation experience from 
the first generation of W3C/WAI guidelines. Of particular relevance is the 
development of Web Content Accessibility Guidelines 2.0 (WCAG 2.0) [6], and 
we welcome JIS' recent participation in the WCAG Working Group which is 
developing WCAG 2.0.


3. GENERAL COMMENTS AND SUGGESTED ACTIONS

Guidelines for accessibility of Web content are just one part of a broader 
solution for making the Web accessible. Used alone as a reference for Web 
designers and developers, they require significant effort on the part of 
individuals. Web accessibility is ultimately best achieved not through 
page-by-page implementation of guidelines, but rather through widespread 
availability of authoring tools that support production of WCAG-conformant 
content, and through improved browsers, media players, and assistive 
technologies.

Once most authoring tools have implemented the ATAG 1.0 -- thereby making 
the process of creating accessible Web content easier -- then the speed at 
which new or retrofitted Web sites will become accessible for people with 
disabilities will greatly accelerate. Likewise, the availability of better 
evaluation tools, and more accessible browsers, media players, and 
assistive technologies will increase the ability of people with 
disabilities to use new and existing Web sites effectively.

But these improvements in authoring tools and evaluation tools cannot 
happen without the adoption of a consistent set of Web accessibility 
standards internationally. For authoring tool developers, support for 
production of accessible Web content as defined in ATAG 1.0 is just one 
among many competing priorities for implementation of new features. Unless 
there is a unified set of requirements for accessibility of Web content as 
defined in WCAG 1.0, authoring tool developers may not believe that there 
is enough market demand to justify implementing features in their products 
that support production of accessible Web content.

Likewise, evaluation tools are essential to effective assessment and 
monitoring of compliance with guidelines for accessible Web content. But it 
is hard for evaluation tool developers to implement accurate tests for the 
many different requirements of different sets of standards and guidelines; 
for instance, separate tests for WCAG 1.0, tests for U.S. Section 508 
subsection 1194.22, JIS Web Content Guidelines, and various other 
regionally-developed guidelines.

We therefore have six general suggestions for JIS, towards the goal of 
harmonizing the JIS Guidelines with the W3C/WAI Web Content Accessibility 
Guidelines, which are the generally recognized international Web 
accessibility standards.

SUGGESTED ACTION #1: To the extent possible, harmonize JIS DRAFT Web 
Content Guidelines requirements with existing WCAG 1.0 requirements;

SUGGESTED ACTION #2: Continue to contribute to the development of WCAG 2.0, 
through participation in the Web Content Accessibility Guidelines Working 
Group (WCAG WG), in order to promote increased understanding of mutual 
requirements and increased harmonization of the guidelines;

SUGGESTED ACTION #3: Commit to the establishment of a new JIS project on 
Web Content Guidelines as soon as W3C/WAI's WCAG 2.0 is a completed W3C 
Recommendation. The purpose would be to examine the question of whether JIS 
could at that time adopt WCAG 2.0 to supercede the JIS document, thereby 
greatly expanding the adoption of a unified international standard for Web 
accessibility, and helping accelerate the development of supporting 
authoring and evaluation tools;

SUGGESTED ACTION #4: In order to avoid further fragmentation of 
international standards, do not promote adoption of the JIS Web Content 
Guidelines by ISO or other international standards bodies.

SUGGESTED ACTION #5: To the extent that the JIS Guidelines cannot at this 
time be completely harmonized with WCAG 1.0, expand the correspondence 
matrix in the final JIS Guideline to include references to the specific 
WCAG 1.0 Checkpoints (rather than WCAG 1.0 abstract guidelines); and 
coordinate finalization of that matrix with W3C/WAI.

SUGGESTED ACTION #6: Add a reference to Web Content Accessibility 
Guidelines 1.0 in the normative references section.


4. TECHNICAL COMMENTS AND SUGGESTED ACTIONS

(4A) HARMONIZATION OPPORTUNITIES:

For the following JIS guidelines, which differ only minimally from existing 
WCAG 1.0 checkpoints, we recommend clarifying and harmonizing them by 
re-using existing WCAG 1.0 checkpoints to the extent possible. Re-use of 
existing WCAG 1.0 checkpoints, as described above, provides much greater 
incentive for authoring tool and evaluation tool developers to build 
support for these features into their products, which greatly accelerates 
the process of making an accessible Web. We have primarily focused on 
correspondence with WCAG 1.0 rather than WCAG 2.0, since WCAG 1.0 remains 
the stable and referenceable standard today.


JIS Guideline 6.1.a:
"Web content shall be produced, in principle, based on the related syntax, 
the technical standard and specification." JIS Guideline 6.1.a is most 
closely related to WCAG 1.0 Checkpoints 3.2, 3.5, 3.6, 3.7, and 11.2 and to 
WCAG 2.0 Draft Guidelines 4.1 and 4.3.

SUGGESTED ACTION #7: Re-use WCAG 1.0 Checkpoint 3.2, reworded in the JIS 
format: "Web content must validate to published formal grammars."


JIS Guideline 6.1.b
"For web contents, accessible techniques and objects should be used. If 
that is impossible, an alternative type shall be offered." JIS Guideline 
6.1.b is most closely related to WCAG 1.0 Priority 1 Checkpoints 6.2, 6.3, 
8.1, 11.4, and to WCAG 2.0 Draft Guideline 4.2, with Level 1 success 
criteria. However, the JIS Guideline has only the level of a "should" 
requirement, while the related WCAG 1.0 and WCAG 2.0 checkpoints set 
minimum level "must" requirements that ensure programmatic interfaces are 
accessible, or that they have alternative, accessible versions. As worded, 
the JIS guidelines seem only to address Java. However, there is a variety 
of programmatic technologies, including ECMAScript, ActiveX, and Flash, 
where this issue needs to be addressed.

SUGGESTED ACTION #8: Use a combination of WCAG 1.0 Checkpoints 8.1 and 
11.4: "Web content must use accessible technology and objects. If this is 
not possible, provide an alternative form." Or, preferably, re-use the 
existing WCAG 1.0 Checkpoints.


JIS Guideline 6.2.b:
"For presentation of contents, it is desirable to use a style sheet. In 
addition, when using a style sheet, it shall be possible to use also the 
web browser which is not yet compliant." JIS Guideline 6.2.b is most 
closely related to WCAG 1.0 Priority 2 Checkpoint 3.3 and Priority 1 
Checkpoint 6.1. It is also related to WCAG 2.0 Guidelines 1.3, 1.5, and 4.3.

SUGGESTED ACTION #9: Use a combination of WCAG 1.0 Checkpoints 3.3 and 6.1: 
"Layout and presentation should be controlled by style sheets. When style 
sheets are used, organize documents so they may be read without style 
sheets." Or, preferably, re-use the existing WCAG 1.0 Checkpoints.


JIS Guideline 6.2.c:
"The element for creating a table should not be used for a layout. If the 
element for creating a table is used for a layout, then the reading 
sequence of voice shall be considered and production shall be performed." 
JIS Guideline 6.2.c is most closely related to WCAG 1.0 Priority 2 
Checkpoints 5.3 and 5.4. ("If a table is used for layout, do not use any 
structural markup for the purpose of visual formatting"). This is 
particularly important for authoring and evaluation tool support. If a 
table does not contain a "th" element, then an evaluation tool can guess 
which tables are used for layout and which are used for data. It is also 
important to harmonize on this point so that authoring tools will not use 
"th" and other table structure elements in layout tables.

SUGGESTED ACTION #10: Use a combination of WCAG 1.0 Checkpoints 5.3 and 
5.4: "Table elements should not be used for layout. If tables are used for 
layout, they should make sense when linearized and should not use any 
structural markup for the purpose of visual formatting."  Or, preferably, 
re-use the existing WCAG 1.0 Checkpoints.


JIS Guideline 6.2.d:
"The structure of a table must be easy to understand and it must be clearly 
shown." JIS Guideline 6.2.d is most closely related to WCAG 1.0 Priority 1 
Checkpoints 5.1 and 5.2, WCAG 1.0 Priority 3 Checkpoints 5.5 and 5.6, and 
to Working Draft WCAG 2.0 Guidelines 1.3 and 1.5. The JIS Guidelines state 
that it is a "must" that tables have an "easy to understand structure," but 
it is unclear what makes the structure easy to understand, or what role 
assistive technology should play in making it easy to understand as long as 
appropriate markup is provided to facilitate navigation and reading of the 
table. Also, the JIS Guideline states that it is a "must" that the 
structure of tables is "clearly indicated." This creates some ambiguity 
over whether the markup should contain information needed to navigate the 
table, or whether the structure of the table should be visually obvious.

SUGGESTED ACTION #11: Use a combination of WCAG 1.0 Checkpoints 5.1 and 
5.2: "Data tables must identify row and column headers. Additionally, data 
tables that have two or more logical levels of row or column headers must 
use markup to associate data cells and header cells."  Or, preferably, 
re-use the existing WCAG 1.0 Checkpoints.


JIS Guideline 6.2.f:
"A frame should be used as infrequently as possible. When using it, 
consider giving a title so that a frame can be identified." JIS Guideline 
6.2.f is most closely related to WCAG 1.0 Priority 1 Checkpoint 12.1 and 
WCAG 1.0 Priority 2 Checkpoint 12.2. It is also related to Working Draft 
WCAG 2.0 Guidelines 2.4, 3.3, and 3.4; Guideline 1.1 is also related, if a 
frame is considered a non-text object that should be labeled. In the JIS 
guideline, providing a title for a frame is a "should" compared to 
providing a title for a page (6.2.e) which is a "must." Interestingly, WCAG 
1.0 requires titles on frames but not on pages, however, a frame is made up 
of pages. Therefore, in JIS, since all pages require titles, the frames in 
the frameset should already be titled; however that is not the case in WCAG 
1.0. WCAG 2.0 has no guidelines specific to frames, since it is not 
specific to HTML. The only solution offered to make frames accessible is a 
title, but there are several other related solutions and issues to be aware 
of -- for example, interrupting the behavior of the back button in the 
browser. Additionally, JIS says "it is desirable to limit the use of 
frames" which goes beyond WCAG 1.0.

SUGGESTED ACTION #12: Re-use WCAG 1.0 Checkpoint 12.1, reworded in the JIS 
format: "Frames must be titled to facilitate frame identification and 
navigation."


JIS Guideline 6.2.g:
"In order to indicate where in the site structure the current screen is 
located, information showing the structure such as hierarchy should be 
offered." JIS Guideline 6.2.g is related to WCAG 1.0 Priority 2 Checkpoint 
13.3, and Priority 3 Checkpoint 13.5. It is also related to Working Draft 
WCAG 2.0 Guideline 2.4. It is unclear how the JIS guideline would be 
supported in an authoring tool or tested in an evaluation tool. The WCAG 
2.0 guideline not only applies to site navigation but also within-document 
navigation.

SUGGESTED ACTION #13: Use a combination of WCAG 1.0 Checkpoints 13.3 and 
13.5: "Provide information about the general layout of a site and 
navigation bars to highlight and give access to the hierarchy or other 
structure." Or, preferably, re-use the existing WCAG 1.0 Checkpoints.


JIS Guideline 6.3.f:
"The basic operation portion should be indicated in the same position, 
expression and notation so that it can be found easily." JIS Guideline 
6.3.f is related to WCAG 1.0 Checkpoint 13.4 "Use navigation mechanisms in 
a consistent manner" and to WCAG 1.0 Priority 2 Checkpoint 14.3 "Create a 
style of presentation that is consistent across pages." Additionally, it is 
related to Working Draft WCAG 2.0 Guideline 2.4 "Mechanisms have been added 
to facilitate orientation and movement in content" and "3.4 Layout and 
behavior of content is consistent or predictable, but not identical." In 
the JIS guideline, "basic operation" refers to "assembly of links located 
at the top, left, and right of a page and other elements related mainly to 
navigation."

The JIS guideline further says: "[Example 1] The link to the main contents 
in the site of the top, the left, and the right of a page shall be unified 
in terms of shape, color, and placement." "Return," "Advance," and other 
buttons shall be unified in terms of shape, color, and placement."

It is difficult to determine what is implied in this guideline and how an 
author would determine if they meet it or not. It is not clear if the 
buttons on one page should look similar or if buttons throughout a site 
should look similar. It is not clear what "easy-to-understand way" means; 
or whether this refer to the language that is used to create navigation 
bars and menus or the visual appearance of the button. It is not clear what 
"same expression" refers to - it could mean the same visual appearance, the 
same text selected to appear on the button, the placement on the page, or 
perhaps another indicator.

SUGGESTED ACTION #14: Re-use WCAG 1.0 Checkpoint 13.4, reworded in the JIS 
format: "Navigation mechanisms should be used in a consistent manner." 
Include the additional detail regarding shape, color, and placement as 
supporting techniques or examples.


JIS Guideline 6.4.d:
"The animation information should be accompanied by the synchronized 
alternative information such as subtitles and status explanation. When the 
alternative information cannot be offered synchronously, the explanation 
about contents must be offered in a certain form." JIS Guideline 6.4.d is 
most closely related to WCAG 1.0 Checkpoint 1.4, 1.3, and 1.1; however, it 
does not seem as specific in its requirements as WCAG 1.0 Checkpoint 1.4.

SUGGESTED ACTION #15: Use a combination of Checkpoints 1.4 and 1.1 of WCAG 
1.0:"For any time-based multimedia presentation (e.g., a movie or 
animation), equivalent alternatives (e.g., captions or audio descriptions 
of the visual track) must be synchronized with the presentation.  Provide a 
text equivalent for each time-based multimedia presentation."  Or, 
preferably, re-use the existing WCAG 1.0 Checkpoints.


JIS Guideline 6.5.a:
"The information required to understand and operate the contents shall not 
be offered depending only on color." JIS Guideline 6.5.a is very closely 
related to WCAG 1.0 Checkpoint 2.1. It is unclear what is meant by a color 
scheme being "easy to identify" (should it be named) nor how that would be 
testable.

SUGGESTED ACTION #16: Re-use WCAG 1.0 Checkpoint 2.1, reworded in the JIS 
format: "Information conveyed with color must also be available without color."


JIS Guideline 6.5.c:
"Background color and foreground color of images etc. should have 
sufficient contrast and color scheme which is easy to identify." JIS 
Guideline 6.5.c is very closely related to WCAG 1.0 Checkpoint 2.2.

SUGGESTED ACTION #17: Re-use WCAG 1.0 Checkpoint 2.2 to the extent 
possible, re-worded to meet the JIS format:  "Background and foreground 
color combinations of images should have sufficient contrast when viewed by 
someone with color deficits or when viewed in greyscale."


JIS Guideline 6.6.c:
"The color of a font should be easy to identify in consideration of 
background color etc." JIS Guideline 6.6.c is most closely related to WCAG 
1.0 Checkpoint 2.2: "Ensure that foreground and background color 
combinations provide sufficient contrast when viewed by someone having 
color deficits or when viewed on a black and white screen." However the JIS 
guideline is ambiguous might be interpreted as requiring that the color 
must be named somehow ("identified" -- though this could be an ambiguity 
introduced by translation).

SUGGESTED ACTION #18: Re-use WCAG 1.0 Checkpoint 2.2 to the extent 
possible, re-worded to meet the JIS format: "Background and foreground 
color combinations of text should have sufficient contrast when viewed by 
someone with color deficits or when viewed in greyscale." However, note 
that by JIS splitting the original WCAG 1.0 Checkpoint 2.2, the distinction 
of text-on-background as opposed to text-embedded-in-images is lost, and 
this may create confusion as to the appropriate priority level (must, 
should, may).


JIS Guideline 6.6.a:
"A font shall be changeable by a user as necessary." This is most closely 
related to WCAG 1.0 Checkpoint 3.1: "When an appropriate markup language 
exists, use markup rather than images to convey information"; also to WCAG 
1.0 Checkpoint 3.4: "Use relative rather than absolute units in markup 
language attribute values and style sheet property values." JIS Guideline 
6.6.a is not as specific as WCAG 1.0 checkpoints 3.1 and 3.4

SUGGESTED ACTION #19: Re-use WCAG 1.0 Checkpoints 3.1 and 3.4, re-worded to 
meet the JIS format: "When an appropriate markup language exists, markup 
should be used rather than images to convey information;" and "Relative 
rather units should be used instead of absolute units in markup languages 
attributes values and style sheet property values."


JIS Guideline 6.9.a:
"A Japanese page should not overuse foreign languages and should allow more 
people to understand it. When it is unavoidable to overuse foreign 
languages, provide explanation and consider understandability." This is 
closely related to WCAG 1.0 Checkpoint 14.1: "Use the clearest and simplest 
language appropriate for a site's content."

SUGGESTED ACTION #20: Re-use WCAG 1.0 Checkpoint 14.1, "Use the clearest 
and simplest language appropriate for a site's content," and add, as an 
explanatory example or technique, the current language of JIS Guideline 6.9.a.


JIS Guideline 6.3.h:
"A link and menu for the navigation used in common should be designed to 
enable a skip in reading."

SUGGESTED ACTION #21: Use language related to WCAG 1.0 checkpoint 13.6: 
"Related links should be grouped in an identifiable way for user agents and 
a way to bypass the group should be provided."


(4B) CLARIFICATION OR IMPROVED TESTABILITY NEEDED:

In the following section, our comments are incomplete, and mainly focus on 
improving the clarity or testability of the draft JIS Guidelines rather 
than on concerns of standards harmonization.


JIS Guideline 6.2.a:
"Express contents in a logical structure." JIS Guideline 6.2.a is most 
closely related to WCAG 1.0 Priority 2 Checkpoints 3.5 and 5.3, and 
Priority 1 Checkpoint 6.1 as well as WCAG 2.0 Draft Guidelines 1.3, 2.4, 
and 4.1. It is unclear if 6.2.a is a "must" or a "should." Is JIS intended 
to only apply to HTML? How is JIS intending to handle XML applications and 
dynamic HTML that may rely on the use of style sheets?

SUGGESTED ACTION #22: Clarify if this JIS Guideline is a must or a should. 
As written, it appears not to be testable, nor to apply to all types of 
content where the requirement would be relevant for accessibility.


JIS Guideline 6.2.e:
"The title of a page must be named so that a user can identify the content 
of the page." This is most closely related to WCAG 1.0 Priority 2 
Checkpoint 13.2 and Working Draft WCAG 2.0 Guidelines 2.4 and 3.3. WCAG 2.0 
Guideline 1.1 might also apply. This JIS guideline is a "must." Neither 
WCAG 1.0 nor WCAG 2.0 have a minimum level requirement to add a title to a 
page.

SUGGESTED ACTION #23: Clarify how this applies to database-driven content.


JIS Guideline 6.7.b:
"It is desirable that a user can control the output of sound." JIS 
Guideline 6.7.b is addressed by W3C/WAI through the User Agent 
Accessibility Guidelines 1.0, not WCAG 1.0, so that the output of sound 
should be controlled by the browser or media player for the most accessible 
experience.

SUGGESTED ACTION #24: Reconsider whether this requirement is appropriate in 
content-level guidelines.


JIS Guideline 6.8.a:
"The image and text which change or move should be produced with attention 
being paid to its speed." It is unclear how JIS Guideline 6.8.a could be 
made testable. JIS Guideline 6.1.a already says to use technologies 
according to specification, in which case the blink and marquee elements 
should not be used.

SUGGESTED ACTION #25: Reconsider whether this guideline should be included; 
or, if included, ensure that it is clear and testable.


(4C) ENSURE DISCUSSION IN WCAG WORKING GROUP OF W3C/WAI:

JIS Guideline 6.9.b:
"Abbreviation, technical term, vogue word, slang and other words which are 
not familiar to the intended users should not be overused. If they are 
used, they shall accompany definition when they appear for the first time." 
This is most closely related to WCAG 1.0 Checkpoint 4.2 and WCAG 1.0 
Checkpoint 14.1.

SUGGESTED ACTION #26: Ensure that this is included by W3C/WAI in the WCAG 
2.0 Working Draft issues list, and continue dialog with W3C/WAI on a way to 
reflect this in WCAG 2.0.


JIS Guideline 6.9.c:
"It is desirable to attach HIRAGANA or KATAKANA to the words which are 
difficult to read aloud."

SUGGESTED ACTION #27: Ensure that this is included by W3C/WAI in the WCAG 
2.0 Working Draft issues list, as an issue which may apply in various ways 
to several different languages (including languages such as Arabic and 
Hebrew where the vowels are often not written, and which therefore produce 
similar problems for screen readers, and for people with difficulty 
reading), and continue dialog with W3C/WAI on a way to reflect this 
requirement in WCAG 2.0.


(4D) WCAG 1.0 PRIORITY ONE CHECKPOINT NOT COVERED BY JIS GUIDELINES

WCAG 1.0 Checkpoint 4.1:
"Clearly identify changes in the natural language of a document's text and 
any text equivalents (e.g., captions)." While the JIS Guidelines 
discouraging mixing of other languages with Japanese, when language mixing 
does happen, it is useful to identify the language change.

SUGGESTED ACTION #28: Consider adopting this in the JIS Guidelines.


5. REFERENCES

[1] World Wide Web Consortium (W3C)
         http://www.w3.org/
[2] Web Accessibility Initiative (WAI)
         http://www.w3.org/WAI
[3] Web Content Accessibility Guidelines 1.0 (WCAG 1.0)
         http://www.w3.org/TR/WCAG10
[4] Authoring Tool Accessibility Guidelines (ATAG 1.0)
         http://www.w3.org/TR/ATAG10
[5] User Agent Accessibility Guidelines (UAAG 1.0)
         http://www.w3.org/TR/UAAG10
[6] Web Content Accessibility Guidelines 2.0 (WCAG 2.0)
         http://www.w3.org/TR/WCAG20




-- 
Judy Brewer    +1.617.258.9741    http://www.w3.org/WAI
Director, Web Accessibility Initiative (WAI), World Wide Web Consortium (W3C)
MIT/LCS Room NE43-355, 200 Technology Square, Cambridge, MA,  02139,  USA


-- 
wendy a chisholm
world wide web consortium
web accessibility initiative
http://www.w3.org/WAI/
/--

Received on Thursday, 27 November 2003 15:37:46 UTC