Wendy Chisholm, Gregg Vanderheiden, Cynthia Shelley, Andi Snow-Weaver, Mike Barta, Kerstin Goldsmith, Matt May, Charles McCathie-Nevile, Masafume Nakane, Bengt Farre, Marc Walraven, @@did not catch names of Japanese colleagues
GV: Not a formal joint session of two committees but with individuals from JIS. Purpose of W3C guidelines it to provide a standard that will work around the world. Not easy. Different issues in different countries. Gives us a chance to understand issues in Japan.
[Meeting being recorded with permission from all attendees.]
GV: Feel free to bring up any problem. Some problems may also apply in other parts of the world but in some countries, they are noticed first.
@@XX ISO setting up a new committee for worldwide web usability Web Inspector web evaluation software History of JIS: have been considering web accessibility guidelines for 2 years - based on ISO Guide 71 and ??. Asking public for comments. Will submit to committee next March. JIS does not mention any specific languages such as Java because technology changes. Requirement levels are "should", "may", "must" - lots of internal discussion. For lots of points, there was opinion that it should be "must" but the industry side wants to keep as "may" or "should" because not always practical with current state of technology. JIS standard is required by law to be reviewed every 2 years.
Overview of Japanese-specific issues (Wendy and Prof. Watanabe)
when typing, you type Katakana and then generate Kanji so generating the Ruby should be relatively easy.
but many words that are written the same in Katakana (sound the same) are written very differently in Kanji
want to identify the differences between WCAG and JIS and understand where WCAG did not address issues for Japan Several of JIS guidelines are very similar to WCAG 1.0 or 2.0. Want to focus discussion on the differences
How do JIS guidelines intend to handle XML and dynamic HTML which rely on style sheets?
How does WCAG 2.0 as currently drafted apply to XML and dynamic HTML (web applications)?
6.5b You must not provide the information necessary to operate contents of a page only depending on the shape/form. neither 1.0 nor 2.0 mention shape but both mention use of content without color
6.6b If you specify fonts, it is desirable to make it an easy to read font considering size and type face. does allowing the user to change the font meet this guideline?
6.9b Don't use a lot of expressions such as abbreviations, field-specific terms, 'new terms', vulgarities/slang, that aren't ???
WCAG 1.0 and 2.0 both have similar requirements
6.9c For words that have a difficult reading, it is desirable to add Hiragana or Katakana to make the reading clear. (This is a "should", not a "must" requirement.)
no equivalent in either 1.0 or 2.0
for hard to pronounce words or words that it is hard to determine what the correct pronunciation should be.
WCAG 2.0 options
But for proper names, isn't the pronunciation the same as the meaning?
example provided of using the same Kanji characters but pronounced differently have different meanings
are there any cases you know the meaning but don't know the pronunciation where it matters?
Pronunciation and meaning can be entirely different issues.
Example of Kerstin's name. Can't tell by looking at it that it is pronounced Shastin for "our" Kerstin. Number of strategies that can be used. Vary from language to language. Can recognize some Kanji characters but don't know how to pronounce. Similar to issue of some with learning disabilities - can understand meaning when "hear" words but can't recognize when see them written.
example of where pronunciation does matter is in poetry words, contractions, and abbreviations are grouped together as things you don't know what they refer to background - in Hebrew and Arabic, all vowels are removed so have to infer meaning from context if we have something like "where meaning or what something refers to is not clear, then additional information should be provided" does this capture the issue. Example, if name is mispronounced, won't understand what it is referring to.
there are many cases where pronunciation is not important - examples of tomato and toMAHto, potato and poTAHto. most of the time pronunciation is not important but there are cases where it does matter. For example, the difference between can and can't is very hard to distinguish in American pronunciation.
difficult to add pronunciation in English using ASCII characters but using Katakana in Japanese it is very easy.
For example, for some difficult characters, publishers will often include both meaning and Katakana characters so that readers will know how to pronounce them.
Need language in WCAG 2.0 that provides guidance on when pronunciation is important vs. those cases where it is not important.
English screen readers have some rules to use to determine how to pronounce words that are spelled the same but have different pronunciations.
Karl Dubost, conformance manager of the W3C, Olivier Thereaux (SP?@@), QA working group contact for WCAG 2.0
Quality Assurance Candidate Recommendation - test their recommendation on WCAG 2.0 promote consistency in format of W3C documents designing to improve readability of W3C specifications - better specs, better interoperability, better translatability (clear language, common concepts, common glossary)
developing tools, have some experience in testing things - can help us
testability must be defined before you can say whether or not something is "testable"
QA framework is a set of three guidelines - techniques documents for
each specification - Operational, specifications, and testing
will review WCAG 2.0 against QA guidelines to see where there are problems with testability
purpose of QAWG is not to figure out how to increase the quality of the WCAG spec but to help WCAG WG figure out how to increase the quality of the WCAG spec
Olivier is QAWG contact for WCAG. Would like WCAG member to be his point of contact to coordinate quality and testability activities for WCAG document. Looking for feedback on QA guidelines - want to know if the QA guidelines are useful.
WCAG WG has had two groups - one working on readability, one working on testability. Do we need a member from both groups? Prefers to have only one point of contact.
Liaison responsibility - coordinate QA activities of the working group, resolve issues - is the problem with WCAG doc or with QA doc?.
Kerstin volunteered to be the liaison. Gregg will discuss with Jason before closing.
WCAG CR target mid-2004
QA CR - not sure when or if it will become a Recommendation - might be folded into W3C process
Olivier will review charter and next WCAG draft available just before Christmas.
"Graphical symbols should not be overused. If they have to be used, attach information of their meaning and their pronunciation" - graphical symbol examples are circles and stars, used for bullets
does WCAG requirement for text equivalents for non-text content cover this?
English fonts don't have these characters so for English, usually use images for these. Japanese fonts have hundreds of these characters in them.
Can be used to add structure to text. e.g. 4 stars = heading.
Don't use enlarged fonts and bold as is typical in English.
Issue is not symbols - it is really an issue of logical structure.
If used in a conventional way, then there is no need for additional information. But if people are encoding information graphically, have to provide more information.
Logical structure is what is needed for screen readers. Visual cue is needed for sighted users.
Gregg submits that this is not an accessibility problem. If symbols each have a name, then the blind user gets the same information as the sighted user. If they don't have a name, then telling the screen reader how to pronounce them doesn't help the blind user who still doesn't know what they mean. If symbols are used to mark structure in an HTML document, then the HTML should provide structure via the markup. If they are used to provide structure to a text document, then the screen reader will read them and the blind user will get the same structure as the sighted user does.
Different screen readers pronounce them differently so, apparently, they don't have standard names. Maybe a Japanese blindness organization should take on the task of naming them.
Have the same problem in English. e.g. # may be pronounced "hash", "pound sign", "number", etc.
Plain text documents cannot be as accessible as a structured marked up document. Plain text document can have "visual" structure that helps sighted users find information quickly. Takes screen reader users much longer to find information in plain text document.
ACTION: Charles will describe how you can specify pronunciation with ruby
ACTION: Max to write up a note for the PF working group.
Until W3C specification clarifies, falls under structure and understandability guidelines
There are a large number of Japanese characters, many of which look similar but have quite different meanings. changing the font can make the visual difference totally disappear.
Japanese Windows OS has characters that are not included in the standard character set which causes problems in e-mail or under another OS. Use of appropriate character set such as Unicode is important.
not an accessibility because the problem is the same for everyone.
WCAG 2.0 has a requirement for text to be in Unicode. Does this cover it? Mike says Unicode is fuzzy in the area of Asian character sets.
Goal is for WCAG 2.0 to cover all issues so that JIS either does not need to have web content guidelines or so that they are consistent with WCAG 2.0.
When WCAG 2.0 is available, W3C will request that JIS roll forward and embrace WCAG 2.0.
JIS has to be finished by the end of 2003. Nothing is decided yet about what JIS will do when WCAG 2.0 is available.
Wanatabe-san is now on the mailing list. All JIS members on Wendy's list will be asked to review WCAG 2.0 drafts.
In some countries, such as Spain, side discussions take place on a separate national language mailing list. If group thinks there is an issue that needs to be raised, someone will raise the issue back to the WAI mailing list.
Gregg demonstrates flicker test tool
Gregg Vanderheiden, Wendy Chisholm, Andi Snow-Weaver, Masafume Nakane, Marc Walraven, Kerstin Goldsmith, Charles McCathie-Nevile, Mike Barta, Cynthia Shelley, Professor Watanabe, June??@@
WCAG 1.0 - came up with collection of things to do for accessibility and then grouped them. In WCAG 2.0 - tried to start with the principles of accessibility without regard to accessibility.
Technology specific requirements are in the techniques documents.
Developers read the guidelines to understand why, but use techniques to understand specifics of what to do.
Level 1 success criteria are only things that are generally applicable to all web sites but that do not require authors to change default presentation of content.
Level 2 success criteria are also generally applicable to all web sites but may require the author to change the default presentation of the content.
Level 3 success criteria are items that are only applicable to certain types of web sites. Unlikely that anyone could ever achieve
Level 3 conformance.
CMN experience with WCAG 1.0 is that lots of people want to and can do AAA conformance.
Some things in WCAG 2.0 Level 3 will be easy to do on some sites, they are just not easy to do on all sites.
U.S. Access Board process for defining Section 508 web standards - used WCAG 1.0 for 2/3 of priority 1 requirements and reworded from "shoulds" to "musts", eliminated all things they thought were untestable, took some items from priority 3 (skip nav), added a requirement that forms should be accessible. First draft was very HTML specific. Got most of that out in final but still doesn't adapt to new technologies very well.
CMN objects to the rationale of no items in Level 1 that require authors to change content.
1.1 Level 3 success criteria reworded as "a text document (for example, a movie script) is provided that includes all important visual information, dialogue, and other important sounds."
Discussion about the need to provide both a text label AND a text description for non-text content that is designed to create a specific sensory experience. CMN thinks a text description is required, otherwise it is not "accessible".
Resolved: in 1, "explicitly associated" must be clarified - does this mean programmatically associated? in 2, text label and text description should be underlined must fully represent the function, must name it, must not allow non-functional non-text content get in the way of other informational content.
1.2 - no discussion
1.3 - suggest "Make information, functionality, and structure separable from presentation by users or user agents." really saying don't communicate information in your default presentation.
Level 1
1. the following can be derived programmatically (for example through a markup or data model that is assistive technology compatible) from the content without requiring user interpretation of presentation
add item d) categorization
JIS has good guidelines in this area
1.4 - guideline doesn't work for all success criteria now
no need for unicode success criteria anymore
action item to reword this guideline
1.5 - Make structure perceivable through presentation
action item (Cynthia) to define "structure" and "structural elements"
Level 3 - small screens should be low resolution displays
Level 3, item 2 is covered in 1.3 - remove
1.6 - move text from 1.3 Level 1 # 3 success criteria to this guideline
Thanks to our scribe: Andi Snow-Weaver