(10:46:50)Topic for #wai-wcag is +1 617.761.6200 passcode 92248 ("WCAG-T") rscano (10:47:03): and made <span title="Ascii art description>....... </span> ? wendy (10:47:08): how does code relate to this wendy (10:47:45): hey joe - are you going to join us on the phone? bcaldwell (10:49:05): uvip web test thread on emoticons and screenreaders -- http://groups.yahoo.com/group/uvip/message/96 sh1mmer (10:49:54): I might add that many different places use subtley different emoticons and often the same ascii to denote different things, some of which would be difficult to express as an alt text. (10:50:47)wendy reads sh1mmer's comment wendy (10:51:55): trying to understand the comment, is that like using ) or P to indicate a smile or tongue-sticking out (i.e. the mouth)? bcaldwell (10:52:13): another thread (from IG) on emoticons - http://lists.w3.org/Archives/Public/w3c-wai-ig/1998JulSep/0335.html sh1mmer (10:53:08): An example would be : (colon) - (dash) / (forward slash) could be anger or sarcasm depending on which network it is used on. joeclark (10:54:30): At the level of four- or five-character ASCII smileys, the screen-reader user is just going to have to puzzle it out. Or the screen-reader manufacturer could program an exception dictionary for likely smileys, which have been well documented. WCAG WG should not spend inordinate time discussing the issue. wendy (10:54:33): http://www.freedomscientific.com/fs_products/software_jaws45newfeawotbl. asp rscano (10:54:46): i've try it... good support for change of language :) sh1mmer (10:56:05): I think my point was, how should the working group recommend dealing with issues of mappings which may depend on a context not obvious to the machine processor wendy (10:56:09): two techniques: 1. ascii art 2. emoticons wendy (10:57:27): joe and tom - I'm not voicing your comments on IRC. If you want to participate in the teleconference, please call in. phone details are in the topic. wendy (10:57:33): (voicing your comments on irc to the telecon) wendy (10:57:45): action dave: explore user agent support for emoticons (10:57:45)RRSAgent records action 1 joeclark (10:57:48): That's fine. IRC is a parallel universe. rscano (10:57:55): <spot> discount call by VoiP: www.dialpad.com </spot> joeclark (10:58:24): For large sections of ASCII art, which is exceedingly rare online and does not require extensive discussion by WCAG WG, a simple skip link is sufficient. wendy (11:01:26): @@ in example: no description wendy (11:02:04): next example: is title on pre read? wendy (11:03:12): we title is read sometimes, is it read for all elements? wendy (11:03:20): 3rd example has abbr w/title. joeclark (11:03:25): title on pre will be rendered in typical graphical browsers, as will title on anything, in fact. As for screen-reader rendering, that's beyond the scope of techniques guidelines. title on pre is standards-compliant; adaptive technology must support standards. wendy (11:03:29): no. cases where title read in exclusion of alt. if img is a link. rscano (11:03:42): title is not read for <ul> elements with Jaws... wendy (11:03:54): 1st example, primary one. skip link. wendy (11:04:04): if title not read, get into pre element and no warning about jumble that ensues. wendy (11:04:31): inclined to highlight 1st example, downplay the other examples. wendy (11:04:54): 3rd example part of separate technique (for emoticons) wendy (11:05:17): like idea of including sound file (current @@ for example 2) wendy (11:05:40): action: ben (ala neal) make sound recording for example 2 of ascii art (11:05:40)RRSAgent records action 2 joeclark (11:06:05): For the benefit of the cheap seats, please tell us where in WD-WCAG20-HTML-TECHS-20030807.html we are presently located. wendy (11:06:16): action: michael lots of edits to make on this section. (11:06:17)RRSAgent records action 3 wendy (11:06:18): http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/#ascii_art wendy (11:06:21): but moving on to: wendy (11:06:35): === wendy (11:06:36): http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/#image_maps wendy (11:07:10): 3rd checklist item has the dreaded, "until user agents..." wendy (11:07:15): do we need this one? wendy (11:09:04): why there? screen readers can read the text for each client-side image map, but if need to magnify text, text not shown and thus can't magnify. wendy (11:09:16): user agent issue. wendy (11:09:51): need to be in better touch with magnification issues. wendy (11:10:52): action: wendy create contacts in low vision and magnification. (11:10:52)RRSAgent records action 4 rscano (11:11:58): wendy, I can forward the question to the Italian low vision association if u want... wendy (11:12:00): would be great to invite some people to a call. collect these issues and talk w/them. rscano (11:12:08): *echo* :) wendy (11:12:20): roberto - thanks. please do. rscano (11:12:22): ok rscano (11:12:41): please forward me when u are ready with the question wendy (11:13:51): at what point do people make the switch from using magnification to jaws (i.e., what degree of magnification). joeclark (11:13:52): We need to clarify the user scenarios here. wendy (11:14:00): tools seem to support up to 16x joeclark (11:14:18): 1. Low-vision person surfing without images.A rare case. It's up to the user agent to display the alt text for imagemaps.Authors can add titles that will also display in most browsers. joeclark (11:14:50): 2. Low-vision person surfing with images.Screen magnifiers do no worse a job with e.g. text in bitmaps than they do in other forms of text. No significant hardship. title can still be used. wendy (11:14:55): "Provide redundant text links for each active region of a server-side image map." joeclark (11:15:04): 3. Screen-reader userIf a compliant screen reader, has access to the alt text and, presumably, title. wendy (11:15:18): every pixel potentially has different location, provide text links for all? instead: provide alternative to functionality of the map joeclark (11:15:24): 4. Person with mobility impairmentThen it becomes a question of tabbability and making links easy to click. joeclark (11:15:49): I don't support the requirement to provide an imagemap *and* text links. That's backward and redundant and will never be adopted even by standards-compliant Web authors, let alone anyone else. joeclark (11:16:14): It is not true that "every pixel potentially has different location." joeclark (11:16:29): the spec specifies that the top-left pixel is (0,0), an absolute reference. joeclark (11:16:40): other pixels in the imagemap are located from taht anchor point.there is never any ambiguity. joeclark (11:17:17): I recommend the Working Group look at the existing accessible imagemaps (several cited in my book, plus all the ones I use) and make some themselves on test pages. wendy (11:17:31): proposal: replace this checklist item with something along the lines of "if a server-side image map needs to be used, provide alternative funcationlity" so that list of links no longer required (unless easy to do?) rscano (11:17:51): yep joeclark (11:18:44): Cf. pp. 188-189 in _Building Accessible Websites_http://joeclark.org/book/sashay/serialization/Chapter08.html#h2 -6590 joeclark (11:19:18): Auxiliary proposal: Evaluate current usage levels of server-side imagemaps.I've only encountered one in the last year, and didn't bookmark it. wendy (11:19:26): techniques become: 1. how to make client-side accessible 2. use client-side instead of server-side 3. if have to use server-side... 4. ?? links for client-side?? wendy (11:19:36): isn't 2 part of rationale for 1? wendy (11:19:55): from tool perspective, it's a good check. wendy (11:20:21): few cases where using server-side is justifiable, thus a good separate check. wendy (11:22:08): editorial note: (about printable characters), remove the paragraph? wendy (11:22:43): yes. remove. joeclark (11:23:23): Should also remove "As with other links, the link text should make sense when read out of context." joeclark (11:24:06): If [258]IMG is used to insert the image, provide an alternative list of links after it and indicate the existence and location of the alternative list (e.g., via that "[259]alt" attribute). wendy (11:24:18): image maps as submit buttons in forms: possible to send mouse coordinates instead of submit. but, how often is it used? joeclark (11:24:20): that advice essentially says "place a hyperlink in alt," which is impossible and unwise. wendy (11:24:22): remove it? wendy (11:24:51): so rare, more confusing to attempt to speak to it? joeclark (11:24:59): Yes, much too rare to emphasize. joeclark (11:25:26): Also, the emphasis on use of the object element will be unworkable until whatever replaces IE on Windows comes into being because IE on Windows has unreliable object support. Hence few developers use it. wendy (11:25:28): it's gone! wendy (11:25:53): action: michael to delete server-side as submit button (11:25:53)RRSAgent records action 5 wendy (11:28:07): action: michael add editorial note: whatever we say about link text needs to match (with what we say here - reading text links out of context). (11:28:08)RRSAgent records action 6 wendy (11:28:17): is there a special case for image map links? wendy (11:28:27): strike "as with other links?" wendy (11:28:48): refering to: "Provide text equivalents for image maps since they convey visual information. As with other links, the link text should make sense when read out of context. Refer to the section on Link Text for information on writing good link text. " wendy (11:28:51): back to examples: 2nd joeclark (11:29:02): http://www.htmlhelp.com/reference/html40/special/img.html wendy (11:29:04): uses object - as we've already discussed today, lots of issues with. wendy (11:29:24): example not diff from using img, other than image has longer description joeclark (11:29:43): No, strike the entire sentence "As with other links, the link text should make sense when read out of context." The claim that links, headings, or other structural elements must make sense when robbed of structure is a non-starter. wendy (11:29:45): for now: delete examples w/object joeclark (11:30:07): Not delete example with object, de-emphasize.It will eventually work on most browsers in use. joeclark (11:30:13): The thing to delete is "As with other links, the link text should make sense when read out of context." joeclark (11:30:30): Or at least explain IE/Win's incorrect object implementation. joeclark (11:31:23): Note that "If AREA is used to create the map, use the alt attribute" wendy (11:31:24): at least comment them out. need to collect info. at some point want examples, confusing to keep in for now. joeclark (11:31:27): should also mention use of title. wendy (11:32:24): last example: server-side + text links. move to appropriate technique (once divvied into multiple) wendy (11:32:25): === wendy (11:32:28): 5 minute break rscano (11:32:31): ok wendy (11:32:44): pick up with http://www.w3.org/WAI/GL/WCAG20/WD-WCAG20-HTML-TECHS/#color_contrast (11:33:03)wendy is now known as wendybrb (11:33:08) rscano has left #wai-wcag (11:36:38) rscano has joined #wai-wcag (11:40:50)bcaldwell back bcaldwell (11:43:04): picking up notes until Wendy returns... bcaldwell (11:43:21): color in images - do we want to have a specific tech. for color in images and another for color in general? bcaldwell (11:44:00): some of this belongs in gateway techniques (good contrast, etc.) rscano (11:44:10): http://h10014.www1.hp.com/accessibility/color_contrast.htm#colortool bcaldwell (11:44:18): w/ text color, user can override -- thus color in images may be more important joeclark (11:44:28): WCAG needs much more careful regulation of colour, since the entire guidelines are based on faulty information. joeclark (11:44:36): WCAG should not even consider regulating colour in images. (11:44:52)wendybrb is now known as wendy bcaldwell (11:45:15): is there an algorithm for sufficient contrast? joeclark (11:45:40): Contrast is not the issue for colourblind people. (11:45:43)wendy back, but eating. i'll pick up notes in a couple minutes. thanks ben! (11:46:00)bcaldwell no problem bcaldwell (11:46:29): @@ Chris to look into further work on algorithm for AERT contrast algorithm rscano (11:46:36): i think there is an algorithm: http://aprompt.snow.utoronto.ca/ColorVisibilityProgram.html rscano (11:46:53): we need to ask to: Chris Ridpath :) joeclark (11:46:55): I repeat, contrast is not the central issue in colourblindness. sh1mmer (11:47:11): i believe stanford have an algorithm to correct for 2 type of colour blindness sh1mmer (11:47:33): http://www.vischeck.com/daltonize/ joeclark (11:47:42): There are three significant forms of colourblindness, and in none of them is contrast much of a differentiator. *Brightness* and *hue* are the issues. bcaldwell (11:48:37): not really an HTML technique, would apply to any technology that embeds images joeclark (11:48:41): [waiting for group members to acknowledge that the issue they're concentrating on is incorrect] wendy (11:49:08): joe - if you want to participate in the conversation, please join the call. joeclark (11:49:16): WCAG should not micromanage colour choices in images any more than it should micromanage writing. joeclark (11:49:23): I am participating in the IRC, Wendy. wendy (11:49:31): that is not participating. wendy (11:49:37): this channel is used to take notes. wendy (11:49:43): the primary conversation is on the phone. bcaldwell (11:49:44): 2 issues (one is contrast, another is meaning in color) joeclark (11:50:10): Contrast is not an issue.Hue and brightness are issues. wendy (11:50:10): you are engaging in a separate discussion (primarily with yourself) joeclark (11:50:40): And since Wendy has deemed that I am not participating and am essentially talking to myself, I suppose I'd best be off. Expect to be corrected on the mailing listsa.