Wikipedia talk:Manual of Style/Accessibility/Archive 1

message: I ran the wikipedia main page in [Bobby] which checks web pages for accessiblity issues. 
* It failed!!
I strongly feel that Wikipedia software writers should help make pages more accesibility friendly so that 'challenged people' should not have a problem. What do you think?
Nichalp
:Try the text-only version. Mkweise 20:40, 28 Mar 2004 (UTC)
thread_title:  From the [[Wikipedia:Village Pump|Village Pump]] 

message: Because of internal changes to Wikipedia's template code, some editors are systematically changing the way that a number of reference templates work.  Junk code is being inserted into the text of the page, and then hidden using CSS.  There is an alternative solution, but this method appears to be chosen because it is easier to implement, and accessibility is being ignored.  This is appallingly contrary to the principal that Wikipedia should be accessible to all users.  Please see the discussion at Template talk:Journal reference#Junk code, and make your opinion heard.  —Michael Z. 2006-01-16 17:41 Z
EVERYONE - in order to quash this ForestFire, please follow-up discussion at MediaWiki talk:Common.css#CSS hack reduces accessibility. -- Netoholic @ 19:08, 16 January 2006 (UTC)
thread_title:  Reference templates being made inaccessible 

message: Note the audio versions of some articles. – Quadell (talk) (bounties) 20:16, 18 January 2006 (UTC)
thread_title:  Audio articles 

message: Do Jaws or other screen readers support table summaries?  The summary would be placed in an attribute of the table.  As opposed to a caption, it summarizes the content of the table.  Not just what it is, but what it says.  —Michael Z. 2006-01-24 21:03 Z
Example:

 Economic indicators, 2006

[header]	[table body]

: Yes, it appears they do.  I made a change to the Capacitor page, and the HTML source does show the summary.  Great idea, but a common recommendation is to use both summaries and captions. -- Netoholic @ 21:14, 24 January 2006 (UTC)
thread_title:  Table summary 

message: Netoholic, thanks for adding Pianoman87's recommendations.  It's rare and helpful to have real-world advice, specific to Wikipedia.  Regards.  —Michael Z. 2006-01-24 21:04 Z
: I agree. I just wanted to make sure his comments weren't lost on some talk page. -- Netoholic @ 21:06, 24 January 2006 (UTC)
thread_title:  Thanks 

message: Maybe some existing templates should be encouraged for accesibility reasons, namely Template:lang (and Template:Polytonic) and Template:IPA. Thanks to the metadata added by those templates —XHTML/HTML attributes lang (and xml:lang) by the former, and class="IPA" by the latter— will allow screen readers to interpret foreing words and IPA symbols correctly. --surueña 14:44, 10 March 2006 (UTC)
thread_title:  Metadata templates 

message: I've been thinking about layiut tables, and maybe the summary attribute should be used in infoboxes to say "This is an Infobox with basic data about the country", or something like that. It is forbidden by WCAG 1.0 and 2.0, however 2.0 guidelines are in the Last Call Draft stage, so comments are welcome (only until tomorrow 2006-05-31).
I suppose the summary attribute is forbidden because this type of secondary content should be tagged using the role attribute of the next XHTML 2.0 (role="note"). However, until this better solution is available we should use another technique supported by current browsers. What do you think? PS: Do you know any browser/assistive technology implementing the new features of XHTML 2.0? --surueña 08:02, 30 May 2006 (UTC)
thread_title:  Last Call Working Draft WCAG 2.0 

message: :Note: Discussion moved from User talk:Graham87#JAWS behavior.
After updating some articles to the accessibility policy I have some doubts regarding JAWS behavior. Some data tables are just after a section header, and therefore adding a caption will be somewhat redundant, I suppose also for users with assistive technologies. See for example 2006 FIFA World Cup#Group F. Are all those structural elements (caption, summary, and row and column headers) needed in JAWS to be read as a data table and not as a layout table? Thanks! --surueña 07:43, 22 June 2006 (UTC)
replies: text: Yes, the caption would be redundant in that case. I think all JAWS needs to recognize a table as a data table is the row and column headers, and that the table has more than one row. I think some restrictions were tightened in JAWS 6.0, but that should be all that is needed. Graham talk 08:37, 22 June 2006 (UTC)
replies: text: OK, I understand. And what about the summary attribute? Are they well supported in JAWS? What do you think is the best way to write it (what should it contain, a listing of the column headers)? Thanks for your fast reply --surueña 08:42, 22 June 2006 (UTC)
replies: text: It should contain more information about the purpose of the table, but not too much to be condescending or chatty. It certainly shouldn't have the column or row headers, but keep in mind that it's always read after the caption. Graham talk 09:04, 22 June 2006 (UTC)
thread_title:  JAWS behavior 

message: Joe Clark, the author of Building Accessible Websites, has written a long article about the problems he finds in both versions of WCAG (specially in the upcoming 2.0) in the webzine A List Apart. Its name says it all: "To Hell with WCAG 2". He also talks about WCAG Samurai, this can be interesting... --surueña 16:18, 22 June 2006 (UTC)
replies: text: More interesting links: Working with Others: Accessibility and User Research and Designing for Dyslexics. --surueña 20:42, 16 October 2006 (UTC)
thread_title:  About WCAG 

message: The comments here seem a little bit like they are encouraging people to use inline colour for decoration. While this is useful in some cases, from the point of view of accessibility (and therefore this guideline), it should be discouraged. To give an example, a user (for whatever reason) changes their browser to use blue text on a yellow background and they then try to read a page which has table with lots of blue section headings. Not Good. ed g2s • talk 00:36, 7 August 2006 (UTC)
thread_title:  Colour 

message: I've proposed a wkipedia wide project to find and eliminate instances within infobox-style templates of the anti-accessible technique of creating multiple visual rows withn a single row by embedding matching HTML breaks in two (or more) adjacent columns in a table, please see Wikipedia talk:WikiProject Usability#Infobox accessibility issue.  This problem has been recently fixed in template:infobox country and template:infobox city.  My fear is that there are hundreds of other templates with references using this formatting technique.  If anyone is interested in helping with such a project please let me know (here, or at Wikipedia talk:WikiProject Usability, or on my talk page, or via email).  Thanks. -- Rick Block (talk) 03:31, 20 September 2006 (UTC)
replies: text: Hello! I'm agree that technique is against accessibility, so I will help in anything  I can. It seems we have a lot of work, I propose to start for example searching inside :Category:Geography infobox templates (e.g. fields "Total" and "Density" in Template:Infobox Mexico City Borough). Do you know more potencially bad infoboxes? But I'm also would like to point to another related problems: in  template:infobox country the flag image and seal image are in one row, but the link to the flag article and seal article are in the next row, so they look alright but when this layout table is read in sequential orden neither the article link to the flag or the seal are next to their respective images (see it for example with Lynx). But I don't enough HTML to make the needed changes (I suppose the best solution is to embed to more tables). In my opinion we should also address that type of problem when fixing the another technique. --surueña 22:30, 20 September 2006 (UTC)
replies: text: Starting with the geography infoboxes seems like a good idea to me.  I'll make a list and we can start checking their uses.  user:Ligulem put together a MWB (descended from AWB) script to help fix references to the city infobox.  I think Wikipedia:WikiProject Usability is the right home for this, but so far no one there has volunteered to help.  At least for the time being, I'll use subpages from the usability project page for coordination.  See Wikipedia:WikiProject Usability/Infobox accessibility.  -- Rick Block (talk) 02:14, 21 September 2006 (UTC)

text: OK. And what about the problem with the flag and seal field within the Template:Infobox_Country? I don't know whether I have explained myself, if it isn't clear enough please tell me. So, do you know how to fix this accessibility problem? Thanks --surueña 20:12, 21 September 2006 (UTC)
replies: text: I believe the flag/seal issue can be fixed by including the caption in the same table cell as the image rather than putting the image and caption in different rows.  I'll bring this up at template talk:Infobox Country and see if there's any objection. -- Rick Block (talk) 04:18, 22 September 2006 (UTC)

text: Am I correct in assuming that this only applies to using HTML break tags to create multiple "rows" within a single one rather than merely using them for visual spacing in two side-by-side cells?  (The specific example I'm thinking of is , where the prevailing convention is to use HTML breaks to space out the numbers in the paired cells at the bottom.) Kirill Lokshin 23:23, 20 September 2006 (UTC)
replies: text: Yes, breaks within a single cell for formatting local to a cell is not problem.  This use in the military conflict template looks OK to me. -- Rick Block (talk) 02:14, 21 September 2006 (UTC)
thread_title:  Infobox project 

message: Template:cquote, which formats block quotations as a table with purple quotation marks linked to image pages, has been proposed for deletion.  Please vote or comment at Wikipedia:Templates for deletion/Log/2006 December 12#Template:Cquote. —Michael Z. 2006-12-13 17:20 Z
:Too late, the discussion was closed prematurely (however, we could make some comments in its talk page). --surueña 22:47, 13 December 2006 (UTC)
thread_title:  Template:cquote is up for deletion 

message: :Template:click, which uses a wikitext/HTML/CSS hack to make links unclickable in graphical browsers, but adds confusing links to other browsers, has been proposed for deletion. Poll is at Wikipedia:Templates for deletion/Log/2006 December 17#Template:Click. —Michael Z. 2006-12-17 17:03 Z
:Although there were a clear consent about the problems caused by this template, the result of vote for deletion was "no consensus" because this template is used in thousands of pages. However, great ideas were proposed to fix the accessibility problems, and I've started to replace it. Meanwhile, probably the best solution is to propose in the Wikipedia:Village Pump editing MediaWiki:Monobook.css to use an style sheet for the top icons (featured star, protected lock, and spoken article), and the quotation marks of . Finally, the template should be proposed for deletion again. --surueña 10:50, 25 December 2006 (UTC)
replies: text: I forget something: Template:ClickA is very similar, but it creates an external link instead of an internal one. It is only used as a shut-down button for bots. I think this can be easily fixed creating another template named  or something like that which sole purpose is to create an extremely big "shut-down" red link, and thus accessible. --surueña 11:02, 25 December 2006 (UTC)
thread_title:  Template:click is up for deletion 

message: Template: has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. --surueña 21:09, 27 December 2006 (UTC)
thread_title:  TfD nomination of Template:{{ucfirst:Wikisourcesmall}} 

message: Template: has been nominated for deletion. You are invited to comment on the discussion at the template's entry on the Templates for Deletion page. Thank you. --surueña 21:09, 27 December 2006 (UTC)
thread_title:  TfD nomination of Template:{{ucfirst:Noclick}} 

message: I looked for an article on JAWS and Wikipedia that would list helpful hints for the new Wikipedian using JAWS but I did not find it.  So I guess I am going to go build Wikipedia:Using JAWS, PLEASE (in caps) come help complete this stub. Jeepday 19:09, 24 February 2007 (UTC)
replies: text: Good work. I'll examine it more closely once I've caught up with everything. Graham87 00:16, 13 March 2007 (UTC)
thread_title: Jaws and Wikipedia

message: Participants here may be interested in the following Wikipedia Manual of Style debate: Wikipedia talk:Manual of Style (dates and numbers)#Appending a period.  The gist is that MOSNUM currently says to leave the period off of abbreviations of units of measurement, entirely, when this is really only appropriate for some of them, such as mm, km, dB, etc., and is not appropriate for those that are abbreviations of Imperial/American units such as feet, inches, miles, etc., which have traditionally used periods, and do so with the recommendations of the vast majority of style guides.  The usability issue can be illustrated with an example:  "The rod is 40.6 cm (16 in) in length" (or worse yet, "has 40.6 cm (16 in) sides"; screen readers (at least some of them) are going to say "16 in sides" which will sound like "16 insides".  Some of the MOSNUM regulars are strongly resistant to the idea of restoring periods here, and I suspect that only usability/accessibility concerns are going to make a dent with the entrenched view.  PS: There are several other debates relating to updating this subsection of the dates and numbers section of MoS, at Wikipedia talk:Manual of Style (dates and numbers)#Overhaul "Units of measurement" section which may be of some usability interest. I fear that the main debate I'm mentioning here is rarely raised because it is shouted down with "This is old news! We don't want to talk about it again!" attitudes (a quick review of that talk page shows several blantant examples of this ignoring of WP:CCC already); its going to take more than just me to get this fixed, I believe.  PS: even from a sighted-user usability vs. accessibility issue, the current MoS-recommended practice is terrible, since English speakers parse the string "in" as a preposition not as an abbreviation for "inch(es)". — SMcCandlish [talk] [contrib] ツ 21:11, 16 March 2007 (UTC)
thread_title: MOSNUM and accessibility

message: I would like to suggest that Wikipedia consider ending the practice of using accesskey attributes. Many commentators have suggested that the use of accesskey attributes is beset with problems and actually causes accessibility problems. In my own case, Wikipedia's use of accesskey 'F' prevents me from using the shortcut ALT-F in IE7 to pull down the 'File' menu. Although that problem is arguably caused by a design defect in that particular browser, amongst others, and it has been suggested that the accesskey feature of HTML is inherently problematic as it forces policy onto user agents and is always at risk of denying keyboard users access to certain features of their software, even in the face of attempts by web designers to second-guess UAs and choose key assignments which will cause the fewest conflicts.
On the other hand, since the basic aim behind accesskeys was a worthwhile one even though the HTML accesskey mechanism was poorly designed and over-specified, I would suggest that Wikipedia consider continuing to offer equivalent facilities as a user-selectable option, but just not as the default. Wikipedia already documents various javascript-powered user-customisable usability enhancement mechanisms.
I would also suggest evaluating the use of other navigation-aid techniques, including meta elements such as link rel="", particularly link rel="bookmark".
References:
Article at Mezzoblue where I do not use accesskeys - Mezzoblue. That post references a number of articles written at wats.ca including wats.ca article - Accesskeys - is it worth it?.
Problems with browsers: Problems with Firefox 2.0.
Canadian government now deprecates the use of accesskeys, having previously required their use: Canadian Government now deprecates use of accesskeys. —The preceding unsigned comment was added by CecilWard (talk • contribs) 20:25, 22 March 2007 (UTC)
thread_title: Consider ending the practice of using accesskeys

message: There is a revert war on Template:Access icon between a version that uses a free replacement and a version that requires the reader to download one of the few fonts that contains the ISA. See also Wikipedia:Village pump (policy)/Archive BC#Is it appropriate to make people download a font to see an "unfree" unicode codepoint? --NE2 12:05, 23 May 2007 (UTC)
thread_title: Downloading fonts?

message: If anyone watching this page knows the answer for sure, please comment on the thread at Wikipedia talk:Manual of Style#Curly quotation marks.  Thanks. -- Rick Block (talk) 02:33, 21 June 2007 (UTC)
replies: text: Now at Wikipedia talk:Manual of Style/Archive 83#Curly quotation marks -- John Broughton   (♫♫) 20:49, 6 November 2007 (UTC)
thread_title:  Curly quotes problematic? 

message: It's always been my contention that images that serve no purpose but decoration, and which have no informative value, should not have any "alt=" text, so that they simply do not appear at all for blind users.  Leaving a caption out of the  should have this effect in wikicode.  Is there any problem with this that I'm unaware of?  Like, does an "alt=" or here a "|caption" have to be present, but simply consist of blank content, like a  , or something? — SMcCandlish [talk] [cont]  ‹(-¿-)› 18:20, 7 August 2007 (UTC)
replies: text: In most modern versions of JAWS (from about 2004 or so), this is a problem. In these new versions of JAWS, any link with just a graphic and no caption will be read as the image name. If the image is thumbnailed (which it normally is in templates) something like "/150PX" will be added to the spoken file name because of how image rendering works in MediaWiki. At User:Graham87/sandbox2, the first image is read as "example.png/150PX example". I can easily turn off these announcements but I find them useful on user pages so I can read people's travel templates (like the countries they've visited). In versions of JAWS below 6.1 (I think), images with no captions are ignored in JAWS. Graham87 13:16, 8 August 2007 (UTC)
replies: text: As for the second part of your question, " " is probably the best caption as I've shown by testing in my sandbox. The link will still be read but there's no way to stop that. The non-breaking space is not read by the default speech synthesizer at any punctuation level so it will appear as if there is no caption to the screen reader user. Graham87 13:22, 8 August 2007 (UTC)
thread_title: Image alt text in templates

message: Why does the example have  (I presume it means that and not , which goes on talk pages) when Template:Featured article says that the template should be put at the bottom of the article?  17Drew 09:18, 5 September 2007 (UTC)
replies: text: I've removed that example. I see  as the polar opposite to a template like  - stub templates are always placed at the end of articles so I think featured article templates should be too. That doesn't matter much to me though. Graham87 10:01, 5 September 2007 (UTC)
thread_title:  Featured article star 

message: I am a Jaws user and frequent user and occasional contributer to Wikipedia. One element of the site I find difficult to use is the diffs. When major changes are made, its really no problem, however, unless I am mistaken, Wikipedia uses colors to indicate the exact portions of lines that have changed. What is needed is a preference which will enable screen reader users to hear these color changes. For example, deleted portions (which I believe are marked in red) could be surrounded by (-test to be deleted-) or some other similar human readable markup. Likewise for the other color indicators used.
cannona 23:03, 11 September 2007 (UTC)
replies: text:  Diff also only brings up the sections that have changed plus a little above and below.  It does not always color code it and if something is only moved you can get different results on the colors.  The colors are a computer programs best guess at what changed but it is often in complete.  Moral = the color changes are just hints not absolutes, you need to compare the old to the new any how so having an written indicator would just be more clutter.  Jeepday (talk) 02:31, 12 September 2007 (UTC)
replies: text:  The changes in a diff are also bolded so you can use that as an indicator, with the speech and sounds manager. To check diffs I usually do a view source on the diff page (alt+v then c with Internet Explorer), and then search for the text "addedline" or "diffchange". The  is the start of the change and the  is the end of it. Graham87 11:35, 12 September 2007 (UTC)
replies: text: I'm not sure if this is useful or not, but: It's possible to use one's personal css page to change how diffs appear. The discussion at [[MediaWiki talk:Monobook.css/Archive 4#Better rendering for .diffchange in diff's... is about colors, but perhaps there are other options that would help when using JAWS. -- John Broughton   (♫♫) 20:40, 6 November 2007 (UTC)
thread_title: Diffs

message: I've just created a subpage of my user space at User:OwenBlacker/Usability. User:Everyking and I have a disagreement over matters of accessibility and usability that I've just listed on WP:RFC/STYLE; please come and add your views. — OwenBlacker 20:03, 26 September 2007 (UTC)
thread_title:  Disagreement between two editors over a matter of accessibility 

message: Can somebody suggest a better way for dealing with List of Washington Metro stations on its talk page? Thank you. --NE2 14:23, 6 October 2007 (UTC)
replies: text: It looks like the table that was the problem has been modified to address the concerns.  -- John Broughton   (♫♫) 20:20, 6 November 2007 (UTC)
thread_title: Colored boxes

message: I use templates to render data tables (like the one bellow). I've tested it with a voice browser (SpeakIt 0.2.0.2 for Firefox) and I could find any problem (even the hidden text is read). So, why the guideline suggest to create data tables as explained here? Is the guideline outdated? --ClaudioMB 00:28, 8 October 2007 (UTC)
replies: text: SpeakIt can only read basic HTML. Most blind people would use something interactive like JAWS or another screen reader with more extensive browsing capabilities. I don't see a problem with the table guidelines as they are now. Graham87 10:34, 8 October 2007 (UTC)
replies: text: Graham - did you examine the source (separate templates for the header row, data rows and footer)?  I think there are two possibly separate issues here.  One is the accessibility of the resultant HTML, which this template structure doesn't really affect (although in this particular instance I'd expect the explanation of the column headings that's in the footer would be kind of annoying - "M", "Gr", "GD"?  what are these?  only after the data do we find out "M" means "match" and "Gr" means "Ground" and "GD" remains unexplained).  The other potential issue is the accessibility of the multiple template source for editing.  I think the accessibility guidelines are targeted at the first issue (accessibility of the resultant HTML).  I'm not sure, but I don't think using separate templates for the header row, data rows, and footer is an issue.  If this is the case, perhaps this could be clarified in the guidelines.  -- Rick Block (talk) 14:09, 8 October 2007 (UTC)

text: Yes, I find the abbreviations "m", "gr" and "grd" annoying in the table - ideally an explanation of what they mean should come immediately after the abbreviations. I don't see a problem with having separate templates for the header and footer. Graham87 14:58, 8 October 2007 (UTC)
replies: text: I've changed M to Match and Gr to Ground. For GD, maybe will be removed or I could come with an solution latter. Maybe I was not clear about my point. Reading the guideline, seems that data tables must use that code structure, explained in the section, to allow a screen reader read it correctly. If that's not true, maybe should be more clear that is a suggestion not an obligation.--ClaudioMB 17:56, 12 October 2007 (UTC)
thread_title: Data tables

message: ::::::Please see Wikipedia:WikiProject Council/Proposals#Accessibility. I think this page would fit in well with the proposed WikiProject. Graham87 02:50, 12 October 2007 (UTC)
replies: text: Now live at Wikipedia:WikiProject Accessibility. Graham87 11:55, 17 October 2007 (UTC)
thread_title:  WikiProject proposal 

message: There is a discussion about formatting at Talk:Pulp Fiction (film)#RfC: Ellipses which is relevant to this page. Can some sighted folks who know a lot about Wikipedia formatting pitch in? Graham87 13:04, 13 October 2007 (UTC)
thread_title:  Accessibility-related problem at discussion page 

message: If this is to remain part of the MOS, it needs to be copy-edited and reviewed for clarity and structure. There are numerous breaches of MOS. Why is it flagged as a part of MOS here, but does not appear on the style template? Tony (talk) 07:51, 22 October 2007 (UTC)
replies: text: Thanks for improving the wording, it's true that this page needs some care. Can you spot any specific problem, please? I'll post this petition in Wikipedia:WikiProject Accessibility for more help. And of course this should appear in the MoS navigation template too. Cheers —surueña 20:18, 22 October 2007 (UTC)
thread_title:  Overhaul required 

message: I've added the following to the Colors section
* Overriding a link colour, especially to red, is confusing and should be avoided.
* Be aware of the contrast of both plain text and the blue link text with the background colour and avoid clashes where possible (such as blue writing on a red background).
I think that this is quite self-evident but should be mentioned somewhere as part of the MOS.  There have been numerous templates that see red backgrounds with blue links over the top of them (I'm currently arguing at Template talk:Scuderia Ferrari about that one) and, even worse, red links on blue (Template:University of Dayton, for example).  violet/riga (t) 10:39, 22 October 2007 (UTC)
replies: text: I've moved all the section to Wikipedia:Colours - it fits in there more than it does here.  violet/riga (t) 11:08, 22 October 2007 (UTC)
replies: text: That's sound, I think this is a good idea. Cheers —surueña 20:43, 22 October 2007 (UTC)
thread_title:  Colour additions 

message: See Talk:Disability #My irony meter has just exploded for my semi-rant on struck-through text. It's common on Wikipedia discussion pages - I don't particularly mind that because there is no convenient alternative and discussion pages aren't as widely read as articles. But on articles, it shouldn't be there. An obvious exception is the article strikethrough. Graham87 02:22, 25 October 2007 (UTC)
replies: text: Strikethroughs have always annoyed me, now I have good reason. But I've never seen striken text in an article before...  L'Aquatique talktome 05:03, 25 October 2007 (UTC)
replies: text: Yes, strikethrough shouldn't be used in articles. You can post here the names of articles you find where it is used, or let me know personally via my user talk page; I'll be happy to not only fix them, but hunt down whoever thought that strikethroughs were acceptable, and let them know otherwise.  -- John Broughton   (♫♫) 18:37, 6 November 2007 (UTC)
replies: text: Well, this isn't a strikethrough witch-hunt. A kindly note on their talk page would suffice- chances are good they have no idea the problems it could potentially cause. --(L'Aquatique: Bringing chaos & general mayhem to the Wiki for One Year!) 20:46, 6 November 2007 (UTC)
thread_title:  Striking text out 

message: I've added two suggestions from the WP:MOS about image placement, and sizing. Forcing sizing (which over-rides user's set preferences) is not advised without a good reason, because for readers who use a large font, and low resolution, it can cause display issues. Additionally, placing images underneath second level headers (===) causes display issues as well. I added those two things, and placed a link to the Images section of the manual of style. (I've verified both issues with both Firefox, and IE7, using a low resolution and oversized font, and confirm there are problems with forcing sizing for those with vision problems). Hope that's helpful! Ariel♥Gold 10:26, 18 November 2007 (UTC)
thread_title:  Image issues 

message: I have marked the Wikiproject Directory as having an accessibility problem because the tables use color as the only means of conveying whether or not a project is active. To join the discussion, see Wikipedia talk:WikiProject Council/Directory#Accessibility Problem. Thanks, L'Aquatique talk 21:26, 24 November 2007 (UTC)
replies: text: The problem has been resolved, thanks to the efforts of Kirill Lokshin. I am awarding him (her?) the Random Acts of Kindness for going out of his way to fix it for us, without being asked. If you would like to sign it, add your signature (three tildes, preferably, so that there is no timestamp) to the template below. Thanks! l'Aquatique talk 03:01, 1 December 2007 (UTC)
thread_title:  [[Wikipedia:WikiProject Council/Directory]] 

message: Over on the various Amazing Race season pages (such as The Amazing Race 12), we have a series of icons that reflect tasks that are done on the show.  The images (from Commons, and placed through templates) have alt text to describe the icon, and just recently we are adding a key to what the images are for those completely unfamiliar with the show (as see at the start of this section.  One editor suggested that via accessibility, this may not be strictly appropriate since we're using images to convey information.  I would like to check if there's any problems with this approach and if we need to consider something else.  --MASEM 00:07, 8 December 2007 (UTC)
replies: text: There is technically a problem with the table at the beginning of the article. You must find a way to differentiate between yields and u-turns in some way other than brown and yellow. See WP:COLOUR.  l'Aquatique talk 01:53, 8 December 2007 (UTC)
replies: text: I'll keep it in mind but it may be a non-issue (with this version, we *believe* that one is replacing the other that has existed in previous versions.  But if both exist, we'll get a better color choice). --MASEM 01:54, 8 December 2007 (UTC)
replies: text: Okay, well I've never watched Amazing race so I don't understand per se what you are talking about, but I would suggest you change it anyway. It isn't, by the way, a question of color choice. You have to find an indicator beyond color... How symbols like brackets and these thingies: "<" (not sure what they're called) are read or if they aren't at all in screen readers, I don't know. That would be a question for Graham, I'm sure he'll be along soon enough. l'Aquatique talk 02:33, 8 December 2007 (UTC)
replies: text: Yes that'd be fine, as long as it's clear what the symbols mean. You can even add attributes (bold, italic, etc.) if that'd look better. Just use some indication besides colour to convey the same information - some screen readers automatically disable colour because it makes certain pages take too long to process - for example see this tech support notice about JAWS. Graham87 03:33, 8 December 2007 (UTC)
replies: text: Great, thanks - we'll make sure to correct the tables. --MASEM 04:25, 8 December 2007 (UTC)
thread_title:  Use of image (with alts) as indicators?