Wikipedia talk:Manual of Style/Accessibility/Archive 1

Archive 1

Archive 2

Archive 3

→

Archive 5

From the Village Pump

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)

For the record, I checked our main page for w3c compliance, and it failed. see here →Raul654 19:32, Mar 29, 2004 (UTC)

Reference templates being made inaccessible

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)

Audio articles

Note the audio versions of some articles. – Quadell ^{(talk) (bounties)} 20:16, 18 January 2006 (UTC)

Table summary

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:

{| summary="GNP rose 30%, but unemployment stayed level"
|+ 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)

Thanks

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)

Metadata templates

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)

Images

I think more could be done for people with visual disabilities regarding images. Caption almost never tell what the image contains. It wouldn't be that hard to create a mechanism for image descriptions, perhaps an alternate name space in commons. There could also be a place for visually impaired people to request alternate descriptions for images that they have interest in. At the very least, there could be a standard syntax for an alternate description text on the image's description page so people wouldn't have to wade through all the licensing stuff and some mention of the need for descriptions, with a link to a page with some examples of good practice, on the upload page.--agr 19:32, 31 March 2006 (UTC)

Hello, agr. Some time ago I had the same idea: a mechanism to describe multimedia content is needed. Images are the first target, but we should also aim at the transcription of sound and video files (probably using Timed Text [1] or Ogg Writ). As you say, a new namespace called Description:Handicap.svg is a possible solution. I was thinking also in semantic annotations: Do you know something about the meta:Semantic MediaWiki project? It is a work in progress implementation of semantic relations and attributes in MediaWiki. Maybe we can reuse this framework for that type of descriptions. For example, instead of creating a page in a new namespace, the annotation would be written directly in the page Image:Handicap.svg:

[[Attribute:Description|descriptive text.]]

What do you think? --surueña 12:27, 6 May 2006 (UTC)

UTF-8 vs. Windows-1252

I don't think the advice about using Windows-1252 or Latin-1 characters instead of other Unicode characters is very useful because the HTML pages send by MediaWiki are encoded in UTF-8. This is not a problem about the Windows-1252 or Latin-1 encodings (i.e. not a Windows vs. Linux issue or a Latin-1 vs. other non-Western ISO-8859 encodings). These two encodings are widely used and supported, but even those articles written only with ASCII characters are sent with the "UTF-8" tag.

The first 256 characters of Unicode are identical to the whole Latin-1, however no text encoded in Latin-1 (using any of the upper half) is also a valid UTF-8 string (neither a Windows-1252 text, of course). That's because the first 128 Unicode characters are encoded using 1 byte, but for the next 128 characters 2 bytes are needed. Therefore a pure 7-bit ASCII string is a valid UTF-8, but not a Latin-1 or Windows-1252 text.

This advice will require changes in the MediaWiki software: when submiting an article the server would need to check whether it's only composed by Windows-1252 characters, and later send it to users with special HTTP headers ("charset=windows-1252" instead of "charset=UTF-8"). Of course it could be done, but IMHO it's not a good idea (and probably developers think the same). If screen readers don't support UTF-8/Unicode they should be updated because nowadays the W3 is adopting Unicode.

In summary: That guideline should be removed from the policy. Or am I missing something? Thank you --surueña 15:24, 10 May 2006 (UTC)

All you say is correct, but note that   /   is (fortunately, otherwise I couldn't use Wikipedia) sent as is, not as UTF-8. I can read / write on Meta and the English Wikipedia, but I cannot use the German Wikipedia - too many UTF-8 encodings. Of course it's clear that the number of users without UTF-8 browser is limited, I'd guess one = me.

The software can support to render UTF-8 as hex. NCRs, it does this in edit boxes for browsers known to cause havoc with UTF-8. It could do more for such browsers, the code exists, it's only not enabled here. The real issue is the subset of Unicode: Before HTML 4 Latin-1 was the default, it's still the default for HTTP (the protocol). Even the most limited devices (mobile, old, etc.) should support all glyphs in this subset. No matter how it's sent, as UTF-8, UTF-16LE, Latin-1, or ASCII with NCRs, as long as the final glyph to display belongs to Latin-1 it should work everywhere.

That's not the case for arbitrary Unicode points above u+FF. The glyph lists of various operating systems used to be limited to a few hundred glyphs, also depending on installed fonts. Unicode has several hundred thousands characters. Simple devices just can't support all of them, Korean, Cyril, Greek, Math, Thai, etc. It's impossible to guess which subset is supported. I'd know where to find WGL4 (Win glyph list 4), and then I could say which characters in addition to Latin-1 (or windows-1252, that's Latin-1 plus 27 more printable characters) should work on all popular platforms (= Win PCs + Win CE mobile devices + almost all printers). But that already ignores screen readers on Linux or old browsers (my case) on OS/2, where the supported glyph list can be different.

But I'm 100% sure that it includes Latin-1 (or in fact windows-1252). How that stuff is transported, UTF-8 or otherwise, is a different question. -- Omniplex 19:26, 10 May 2006 (UTC)

I see, your are talking about character sets, not character encodings. Thanks for charifying your point. I like your proposal: to deliver some characters as numeric character references or character entity references (the latter is the preferred option in my POV) to better support old user agents. Of course this is one of the goals of web accessibility, and because this transformation can be done by the MediaWiki software it's transparent to editors. We could even transform not only Latin-1 or Windows-1252 characters, but some other character sets with known support in older platforms (specially those with character entity references). However, developers have the last word: maybe it imposes a high penalty in the server, and can be too disruptive. But all in all, I find this proposal interesting.

However, your reply doesn't ask my question: Why the advice about character sets should be in the Wikipedia:Accessibility policy? Of course changes in MediaWiki are needed to improve the accessibility (in the syntax, in the generation of HTML, etc...), but said changes are "under the hood", and need not (and shouldn't) be written in a policy. If an editor needs to write a character he/she has to write it, regardless of whether it is outside the Latin-1 character set, the BMP or whatever. Can you put an illustrative example? --surueña 18:13, 11 May 2006 (UTC)

PS: There were some versions of Mozilla for OS/2, isn't it?

As the author of that point, I'll explain why I added it. In at least JAWS for windows, all characters which cannot be recognised, which is anything not in the windows-1252 character set, are spoken as question marks. The ability to read and identify characters which are not in the windows-1252 character set was introduced in version 6.1. However, the name of only a few of these characters (the Arabic alphabet, a few special symbols) is stored, and adding them is a fiddly process involving editing the language file for the synthesizer you want to speak the character. The dictionary manager, the normal method for changing the pronunciation of characters or words, still does not support unicode. Therefore, it's easier for JAWS users to read and manipulate windows-1252 characters, no matter their JAWS version. However, the actual non-Latin characters are not garbled in edit forms by JAWS; I've never had complaints about that, and I've edited thousands of pages. However, I need to be especially careful with cutting and pasting.

Therefore, all I'm trying to say is that there is nothing wrong with using UTF-8 characters and non-Latin characters. However, if there is a character in the windows-1252 character set that can replace the non-Latin character, it should be used.

Actually, JAWS seems to support any of the code pages available in windows. See this document from Freedom Scientific. I'm not too familiar with character encoding; I'm more familiar with the practicalities of using it with my English version of JAWS. Graham talk 10:54, 12 May 2006 (UTC)

re: Graham87, funny but true, on my box Lynx has the best Unicode "support" with its 256-33 printable characters in codepage 850 (or 5 less in windows-1252), it uses an old weird scheme to replace many Unicode characters by mnemonics. Something like "->" for "arrow pointing right". The effect with a screen reader on top of Lynx is probably hilarious, but in visual text mode it often works.

re: Suruena, yes something like a "legacy skin" (not the CSS based definition of skin, more like a preference) would be cute. It would have some serious limitations, therefore users won't pick it unless they must or want, and so the additional server load for transformations should be not too high. Hex. / dec. / symbolic entities is less important. The W3C has had enough of odd collections of symbols, they now recommend hex. But Netscape 4 or worse (my case) don't support hex. NCRs, so it's either decimal or symbolic. Unknown decimal NCRs result in a question mark, okay from my POV. Symbolic is also fine if I know what unsupported names mean (e.g. € isn't supported by Netscape navigator, but perfectly clear).

The existing symbolic names have an advantage: Somebody went to the trouble to invent and list them in the XHTML standard. Therefore any browser is supposed to support them (Netscape navigator has an excuse, it's too old for some, but knows all symbolic entities defined for HTML 3.2, essentially Latin-1 but still better than UTF-8 limited to ASCII). In other words, that is a richer set than windows-1252 that should be supported by "any" browser including JAWS, unlesss it's simply too old. After that point - identification of a small Unicode subset supposed to work everywhere - I don't care how it's actually sent, symbolic or decimal, both fine.

There was (probably still is, OS/2 is a zombie, not really dead) a Mozilla for OS/2. It was developed and tested for Warp 4 (I have Warp 3, roughly a difference like XP vs. W2K). Its compressed archive was above 40 MB. I don't have the disk space to unpack and test it, and I'm not eager to download 40 MB over a V90 line if the most likely outcome is "won't work". The complete Netscape navigator binary and also the Lynx binary are about 2 MB. Ideal for 64 MB RAM. -- Omniplex 18:33, 12 May 2006 (UTC)

I can think of a few characters where such advice could increase accessibility for screen readers or non-Unicode browsers, but it's an exceedingly thin sliver of cases between ISO Latin and the full breadth of Unicode, and difficult for the average editor to figure out which substitutions would actually be helpful. I would recommend the standard Latin-1 character set over Microsoft's proprietary Windows-1252.

Latin entities might make a bit of sense if they're read out, but on the other hand I recall from my Netscape 4.0 days that a few characters would be rendered correctly if included in the page as decimal entities, but show up as question marks if entered as Latin entities.

Code pages in Jaws hardly sound like they're worth messing around with unless you are interested in a subject where one particular language is used, since you would still have to choose a single one. A single Wikipedia article can easily have characters from several different code pages (e.g. accented Latin, IPA pronunciation, and one or more foreign-language scripts or some technical or mathematics symbols). I wonder if the developers are considering adding real Unicode capability—it sounds like even just reading out a characters' Unicode name would be far superior to the way it works now. Too bad a USD $900 screen reader (Jaws) can't have the same basic text savvy that a free text-only browser (Lynx) does. —Michael Z. 2006-05-12 21:14 Z

Well, we have here more than one topic:

1. I agree with you, Michael Z., although there could be some cases where a few Unicode characters could be replaced by Latin-1 ones, at the end this would be a pain and also it wouldn't be very useful in my POV. For example, Greek has assigned a block of Unicode characters,[2] and some of those glyphs can be found in the Basic Latin[3] and Latin-1[4] blocks, like "Greek small letter mu" and all of those with identical visual appearance like "Greek capital letter alpha" (equal to "Latin capital letter A"), "Greek capital letter beta", "Greek capital letter iota",… But they're only I few, a Greek word composed also for characters not found in the Latin-1 character set will be still not readable. An also, although each glyph has the same visual appearance, the character contains additional semantic information (one character "mu" is used only in mathematical notation while the other is only for Greek texts, the "capital alpha" when transformted to lower case should be converted to "small alpha" and not "latin small a", a spell checker will allow a Greek word with a capital iota, but would reject the same word mixing Latin and Greek letters…), and therefore if editors are encouraged to substitute them with Latin-1 characters that semantic information is lost. Those substitutions should be done by the software when serving the page, and not by the editors (no information lost, and also is easier). However, the policy can be changed to "if you write non-latin text, you must provide next a latin transliteration" or something like that. Therefore, those readers without Unicode support
2. Those users without UTF-8 support could receive some characters using entity references. This is the English version of the Wikipedia, so Latin-1 characters are a good bet. However, other Wikipedias maybe should choose another character set (but we proposal could start with only Latin-1). Omniplex, I was thinking the reverse: this substitution should be always done when sending a page unless the user specifies it in his/her preferences. Otherwise, only those registered users (knowing the existence of that preference) will be able to use that feature. But of course, the performance issues have to be taking into account. And yes, I've also heard that hexadecimal numeric entities are not supported by old browsers, therefore the decimal ones should be employed instead. I don't know whether old browsers have a good support of character entities, I only said that preference because they can be understood by humans. Maybe the character entities defined in the HTML 2.0 or 3.2 specification are widely supported, but those defined in HTML 4.0 should be written with numeric entities (I don't know). Omniplex, do you want to lead the proposal? I will support your enhacement request voting the MediaZilla entry, and giving all the feedback you want.
3. JAWS must support Unicode, that's very important. That's harder to achieve than a change in the MediaWiki software, but maybe if they receive some e-mails from us they will do something. UTF-8 is also very important. Does JAWS have some problems with UTF-8? For example, do it understand all characters of my surname?:
   • Urueña (Unicode character)
   • Urueña (character entity reference)
   • Urueña (decimal numeric entity reference)
   • Urueña (hexadecimal numeric entity reference)

Also, JAWS should understand all ISO 639-1 and ISO 639-2 language codes (see Template:lang).

PS: I've changed my signature replacing the plain 'ñ' character with the ñ entity to improve its accessibility :-) Best regards. --surueña 09:44, 13 May 2006 (UTC)

The "ñ" character is read buy all versions of JAWS , as it appears in the windows-1252 character set (the as character #241, according to the SayAsciiValue function of JAWS). That character is safe, and doesn't need to be changed. How the characters are written in the edit window only affects what is read in the edit window, and does not affect what is displayed or read by any screen reader. I would personally prefer to read question marks than the actual numbers while reading an article, which would seem like random numbers and be confusing to me. I don't support using numeric character references in edit windows either; it might approve accessibility slightly, but make it difficult for those reading non-Latin languages to decipher what character has been typed. That was Graham talk 11:43, 13 May 2006 (UTC)

Sorry for the misconception, I haven't explained myself well… With the above 'ñ' characters I wanted to test the UTF-8 support of JAWS. If it can read OK all of them it seems that JAWS have no problems with UTF-8. (However, is the browser that sends to JAWS the page, probably JAWS only receives Windows-1252 characters and is the browser who decodes the web page, am I right?) The transformation of characters about we were talking are made transparently by the server: i.e. editors don't write character or numeric entity references but the 'plain' character with their keyboards, and is the server who send the final web page to users with those character transformations for those who browsers with no UTF-8 encoding support. But it's only when reading the page, later, when other editor edits the page, he/she will see the 'plain' character again, and not the numeric entity reference. Well, except users like Omniplex, who have more transformations I suppose: because their browsers have problems with UTF-8 characters when editing a page, they see character entity references when editing. However, those numeric or character entity references are transformed to plain characters when they submit their edits, and therefore that transformation is also transparent for the rest of editors.

However, there're some exceptions, and I support that some special characters should be introduced by all editors as character entity references. For example, en and em dashes should always be written using – and &mdash, and the minus sign like −, otherwise they could be easily confused with a normal hyphen. Or non-graphic character, like   for the non-breaking space. Or sometimes a | should be written as | when it must appear in a template call, for example. --surueña 09:24, 14 May 2006 (UTC)

Timelines?

I wonder if there is a way to make the timelines accessible with screen readers? At the moment, when navigating through a timeline, all I get is image map links but no years. It would be nice if I could find out in what years something occurred; for an example see history of computing. Could the years be added to the image description, or would this just make the timeline look ugly? Graham talk 11:58, 13 May 2006 (UTC)

You mean at Timeline of computing#Graphical timeline?

Currently, it appears that timeline text like "Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" is represented by graphical text, but only the links and redundant title attributes present in the code. This fails validation and accessibility, because each area's required alt attribute is missing altogether, and most of the text is not represented in the code at all.

I think it would be better if each link had the full sentence for its alt text, prefixed with the relevant timeline date or range of dates. So the link above would be represented by):

 <area shape="rect" href="/wiki/Moore's_law" coords="x,y,x,y" alt="1965—Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" />
 <area shape="rect" href="/wiki/Gordon_E._Moore" coords="x,y,x,y" alt="1965—Moore's law: processor complexity will double every year, revised in 1975: complexity will double every two years. Gordon E. Moore" />

In this case the text is repeated, but a separate area is required for each link. Perhaps it should be recommended that editors try to include exactly one link in each timeline item. What should be in the title attribute?

And of course the timeline image map entries should be sorted by their date, perhaps grouped by timeline section. Is there a way to add the subheadings? —Michael Z. 2006-05-14 20:22 Z

I posted a note about this at m:Talk:EasyTimeline#Standards and accessibility. —Michael Z. 2006-05-14 20:32 Z

Yes, if the main text could be placed in the alt attribute, this would make it easier to use. I think we should recomend that the text contains exactly one link; because of its behavior in image descriptions with several links, I suspect that it will ignore the second link, but it's hard to tell. Maybe the sections can be noted by subheadings (<h3> and </h3) and the like, or with lists. It would be ideal if a JAWS user could move through the sections of a timeline with the quick navigation keys (which include such elements as headings, lists, ETC). Graham talk 09:54, 15 May 2006 (UTC) sentences revised at 10:24, 15 May 2006 (UTC)

Accessibility problems of Wikipedia

Note: Discussion moved from User talk:Graham87#Accessibility problems of Wikipedia.

Hello Graham, how do you do? As you know, I'm currently working in the Wikipedia:Accessibility project, and there's much work to do… I would like to know what are the biggest accessibility problems of Wikipedia, for working on them first. Image descriptions? Articles' structure? Unicode texts? The opinion of a JAWS user is very valuable, thanks! Best regards --surueña 10:13, 13 May 2006 (UTC)

Thanks for your message; I'm glad you're improving the accessibility page; it hasn't received much heavy editing for a while. The main problems I have at the moment with accessibility are the use of IPA for pronunciation (sound files on pronunciation are especially handy to fix that), and the format of timelines. I'll probably write more on the issue at wikipedia talk:accessibility when I've finished researching the timeline issue. Graham talk 11:49, 13 May 2006 (UTC)

However, the biggest reason wikipedia is difficult to use for blind people is related to problems with JAWS, the most popular screen reader. What is read in JAWS is quite different to what is seen in web browsers; each link is put on its own line, and the format of tables is changed remarkably. Wikipedia isn't an easy site to use for newbies to JAWS, but using the heading and link navigation features, it's possible to use most of the features of the site. Graham talk 12:06, 13 May 2006 (UTC)

Yes, IPA is also a problem for me! I don't know how to pronounce those IPA characters. However, I suppose your problem is that JAWS only gives question marks when reading an IPA pronuntiation, isn't it?

I had also some ideas about the timeline issue. As the WAI says, image maps imposes accessibility problems. Luckily, the only image maps I've found in Wikipedia are timelines, am I right? Probably a simple fix is the EasyTimeline tool writing also the longdesc attribute. However a more elegant solution would be to generate SVG images instead of image maps, but there's not enough support for SVG. Maybe in the future.

Sorry, but I don't have a clear idea of the problems with JAWS. Please, can you put an example? Are they problems of JAWS, or a Wikipedia policy should correct them? --surueña 12:14, 13 May 2006 (UTC)

Yes, my problem is that a lot of the IPA characters are written as question marks. Someone suggested once that there should be a speech synthesizer for IPA, but it was pointed out that even those symbols can be ambiguous. Timelines are the only use of image maps I know of on the wikipedia site. The problems with JAWS could only be fixed if the virtual buffer was made to look more like what the sighted user sees; freedom scientific is making plans for this, which is a good thing. Maybe the only advice I could give is to not overlink words in wikipedia articles, and make tables accessible. . Graham talk 12:26, 13 May 2006 (UTC)

I see: The problem with JAWS you was referring to is that articles have too much wikilinks and the screen reader stops in each one. Yes, this is also a problem for other users because important links are "hidden" among less interesting ones, therefore it should be easier to enforce by editors than other accessibility guidelines. In fact the Wikipedia:Manual of Style (links) and Wikipedia:Only make links that are relevant to the context warn about this, but they aren't well known.

However, probably it could be a good idea a JAWS mode only reading text and not links. Or does it exist but it isn't very useful? (Hey, is that phrase right? Please, feel free to correct any mistake, I'm not a native English speaker and I must learn my faults :-)

One idea I had some time ago is to have a new syntax for dates: You now, currently wikilinking to dates is a usual practice because MediaWiki can make formatting changes. However, some dates aren't relevant, and therefore a wikilink is unneeded. I think that a new syntax should be provided to let MediaWiki make formatting changes, but it should be independent to the wikilink syntax. This should reduce overlinking. But much more can be done, I will think about it… --surueña 08:49, 14 May 2006 (UTC)

Yes, you can get into a mode where links aren't announced by turning off the virtual buffer (known as the virtual cursor in JAWS). In fact before JAWS 3.31 (around September 1999) there was no virtual cursor and that was the only way to navigate through the internet or any help pages. That method has its advantages; it's easier to navigate well-designed forms and the blind user sees websites the same way as sighted users. However it sometimes reports false information in windows xp and it would confuse most recent JAWS users. Regarding date links, there has been a lot of debate regarding the best way to handle them; I don't mind date links, but I do mind links to solitary years. Would you mind if I moved this conversation to wikipedia talk:accessibility, to make it more visible? That's what our conversation seems to be about ... Graham talk 09:13, 14 May 2006 (UTC)

Is there a way to mark a link as less important, so JAWS will skip over it in normal reading, perhaps using a rel attribute? If so, this could be built into the automatic date formatter. —Michael Z. 2006-05-14 20:37 Z

No, not that I know of. The speech and sounds manager can be used to change how a link is spoken, but nothing can be done for one particular link. Graham talk 09:39, 15 May 2006 (UTC)

Infoboxes and data tables

Copied / moved from my user page. -- Omniplex 01:59, 15 May 2006 (UTC)

Hello, how do you do? I saw that you think that not every info or series boxes are layout tables (i.e. some of them are data tables), and that's great because I've thinking about it for some time and I believe the opposite, but because I'm not sure I would like to know more opinions.

From my POV all infoboxes I've seen are no data tables. See for example {{Infobox Country}} or {{Infobox Episode}}. Sometime ago I believed that those infoboxes were data tables, and therefore they should have row & column headers and a caption for accessibility reasons. Row headers were easy to find, but what about column headers? I can't find them in any infobox. And in series boxes I could't find even row headers. And that's because in my opinion they aren't a 2D data table with raw data like {{Most Active Regional blocs}}, but the cells are only used for layout purposes.

But I would like to disscus it while developing the Wikipedia:Accessibility policy (really). Am I missing something? Best regards, surueña 15:59, 10 May 2006 (UTC)

Maybe we should discuss it on the WP:WAI talk page, because I've no clear definition of "infobox" vs. "layout table" / "data table" / "series box" / "sidebar" and what else.

What you or somebody else wrote about "data table" makes sense, if it has caption / summary / row headers / column headers, then it either is or should be a "data table". The opposite should also work, if it merely emulates what <div> with CSS could do on modern browsers, then it's no evil table layout, but only "visible with any browser" for a value of "any = my" browsers without CSS. I don't use Lynx to read Wikipedia, I only use it to test my own pages.

Generally I don like these constructs, see User:Omniplex/ich and IPstack. They start an article with tons of unrelated info crying "don't read what follows, click on of those fine links to other articles". Annoying from my POV, I don't want to wade through dozens of lines before I finally arrive at the real lead section and ToC. But if these obscure boxes work as on Sealand they are fine, with legacy align="right" and a decent legacy width, 20% or at most 300, let them float. For a screen reader it should be exactly the same effect, if it's bad with CSS it will be also bad with align and width. But it's a big difference for me with my old browsers. That's one of the details I care about, if there are two ways to get exactly the same effect, excluding cruft like <font> tags, then I prefer the solution also working with my browsers. -- Omniplex 17:25, 10 May 2006 (UTC)

Yes, the issue of an article not starting with the lead section (from the POV of non-graphics browsers) should also be addressed by the Accessibility policy (I've some ideas, but they still need more work).

But please, do you have an example of a data table used as infobox / navigational box (e.g. {{EU}}) / series box ({{History of Spain}}) / succession box ({{sequence}}). I'm very interested. Thanks --surueña 18:38, 11 May 2006 (UTC)

Revert

As I disagree with all modifications yesterday I've reverted them. -- Omniplex 01:53, 15 May 2006 (UTC)

I've reverted them …because…

Added again those modifications until an explanation is given. Provide good reasons why those changes aren't good, and those modifications will be reverted even by me. Thanks --surueña 16:04, 16 May 2006 (UTC)

Using a wikitable to layout a "Do you have accessibility problems?" notice is wonderfully ironic.... ;P -Quiddity 17:37, 16 May 2006 (UTC)

:-) well, in the first version I employed some <div> tags only, but maybe a simple wikitable is better for old browsers. Best regards --surueña 20:46, 16 May 2006 (UTC)

I'm removing the image because it's indecipherably small and unnecessary, and changing the layout back to css. -Quiddity 22:24, 16 May 2006 (UTC)

articles with a floating TOC

I don't see the point of making the table of contents left or right aligned, nor is it a problem for me. However, I do object to putting the table of contents above the intro, because it breaks the heading structure I (and probably all other users of screen readers) expect. I've made several edits to fix this at prominent articles like Isotope, poker, and most recently nobel peace prize. Is there any reason the intro should ever be below the table of contents - does it look any better visually? If not, I might add some info about this in wikipedia:section. Graham talk 10:36, 15 May 2006 (UTC)

It's rarely a good idea to use the floating TOCs. There were all sorts of problems at the 3 examples you gave (which i've fixed, by removing all TOC-forcing templates, and rearranging a few images). I think people add them without realizing/testing-for side-effects. The only place they're really needed/non-problematic, is in articles with manymanymany headings, and no/few floating images nearby (floats tend to interfere with one another).

I'd strongly agree that the guidelines could use clarifying. I'm not sure what we could change in the section at meta:Help:Section#Standard TOC? (it's also mentioned in 1 sentence at The rest of the lead section)

Perhaps most important would be a prominent note at Category:TOC templates, and it's main listing Wikipedia:Template messages/Compact tables of contents, to de-emphasize their use. Sorry to stack the workload up, but that should be everything, and would be most excellent. ;) -Quiddity 18:14, 15 May 2006 (UTC)

OK, I've added this as a guideline to Wikipedia:Accessibility #Article structure. I've also added a note about this to help:Section#Floating the TOC, and I've removed mention of the idea from the guide to writing better articles, as I don't think it really belonged there. I don't feel like shouting or forcing this through, so I haven't added info to Category:TOC templates yet. I could just be bold, but I don't like doing that with major pages. Graham talk 12:10, 16 May 2006 (UTC)

Good stuff. I added a link to the category. -Quiddity 17:34, 16 May 2006 (UTC)

Editing a section

If you browse an aticle in Lynx or other non-graphical browser, the [edit] link is always before the section heading. Maybe it would me more logical for these browser just the reverse: after the heading. I'm not sure it's really an improvement, what do you think? A nice feature is that those edit links have a title attribute like "Edit section: See also".

Another change related with the edit button has to do with the lead section: it can only be edited editing the full article, and this link in non-graphical browsers is at the bottom of the page. IMHO, the MediaWiki should also provide an [edit] button for the lead section (section 0), as done with the other sections: it will be very useful in non-graphical browsers because it would have more visibility, but also for other users because they will be able to edit only the lead section without editing the full article (very useful for extremely big pages). HTH --surueña 20:48, 18 May 2006 (UTC)

I don't know about the 1st, but i really like the 2nd suggestion. Post it at WP:VPT. -Quiddity 23:54, 18 May 2006 (UTC)

These would have to be changed in the Wikimedia software. Vote for bug 4525 and bug 4741, and add your comments.

Regarding the second issue, see bug 156. FYI: you can edit the first section by using a similar URL with "&section=0" in the arguments. However, this is not helpful to most users. Also note that you can edit the page using the control-E accesskey, but accesskeys only work with Javascript (this is very stupid; see bug 5051). —Michael Z. 2006-05-19 00:24 Z

You may have a look at User Talk:Revolus/de-editsection.js. It is a small interface to insert the content of User:Revolus/de-editsection.js into your monobook.css (works with every skin). The script is long-time tested by the German wikipedians, and no bug has been reported. Even for seeing users with graphical browsers it is an advantage. Just try it out :-) --Revolus 17:24, 7 August 2007 (UTC)

MediaWiki bugs

Some accessibility issues must be fixed by changing the MediaWiki software which runs Wikipedia's back end. Please have a look at Bug 367: Markup accessibility issues (tracking), and all of the bugs listed under "Bug 367 depends on". Leave your concise comments, and vote for these bugs to encourage the developers to address them. —Michael Z. 2006-05-19 00:32 Z

Open MediaWiki bugs: please vote for these bugs

• Bug 367: Markup accessibility issues (tracking)
  • Bug 368: Image syntax shouldn't use caption as alt= text
  • Bug 371: Image enlargement icon should have alt="", not alt="Enlarge"
  • Bug 532: Images used in the user interface should have alt text
  • Bug 542: Link text shouldn't be duplicated in title attributes
  • Bug 658: Table of contents shouldn't be a <table>
  • Bug 1037: Language files have inconsistent mark-up
  • Bug 5051: Accesskeys should not require Javascript

Infobox rows

I've noticed a number of infoboxes use a technique creating single HTML rows consisting of a number of lines, separated by newlines or BR tags, where each line has a set of labels in a cell on the left and corresponding values in the adjacent cell on the same "physical" line. I'm imagining that this is a particularly difficult arrangement to understand using a screen reader since the intended organization is line-based rather than HTML cell/row based. For example, the current version of template:Infobox Country which is used for most countries (e.g. Algeria) presents population data in this way. Am I correct that using this technique makes understanding the data in these infoboxes difficult? I have a new version of the country infobox, currently used at User:MJCdetroit/Sandbox, that makes the separate lines individual HTML rows. There are lots and lots of infobox templates that do this. If it makes a signficant accessibility difference I'm willing to fix more of them. -- Rick Block (talk) 18:07, 29 May 2006 (UTC)

Yes, from my POV you're right, this is an accessibility problem because the contents isn't in sequencial order, as can be seen with the http://wave.webaim.org/ tool. I'm sure there're more infoboxes with this problem. Maybe the accessibility policy should warn about this (although this is implicit).

In the {{Infobox Country}} there is a similar problem with the leaders' cell, but the <br> tags are introduced by the editor. However, to solve this new parameters should be created (e.g. leader1_title, leader1_name, leader2_title, …). Rick Block, are you a maintainer of {{Infobox Country}}? Best regards --surueña 07:48, 30 May 2006 (UTC)

I agree about the cells for the leaders. I haven't previously been involved with template:Infobox Country, but I have suggested at its talk page that the current version be replaced with version I've created. I'll bring up adding leader1-n parameters as well. -- Rick Block (talk) 13:20, 30 May 2006 (UTC)

Thanks. The question is how many leaders can have a country. Maximum two? I don't know, but more can be added later if nedeed. --surueña 14:18, 30 May 2006 (UTC)

Last Call Working Draft WCAG 2.0

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)

JAWS behavior

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)

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)

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)

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)

About WCAG

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)

More interesting links: Working with Others: Accessibility and User Research and Designing for Dyslexics. --surueña 20:42, 16 October 2006 (UTC)

Colour

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)

Infobox project

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)

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)

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)

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)

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)

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 {{Infobox Military Conflict}}, 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)

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)

Template:cquote is up for deletion

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)

Template:click is up for deletion

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 {{cquote}}. Finally, the template should be proposed for deletion again. --surueña 10:50, 25 December 2006 (UTC)

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 {{shutdown}} 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)

TODO

• See Wikipedia talk:WikiProject Usability/Clickable images

TfD nomination of Template:Wikisourcesmall

Template:Wikisourcesmall 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)

TfD nomination of Template:Noclick

Template:Noclick 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)

Removing Clickable images

I'm proud to say there are promising advances with respect template {{click}}. As you know, it is an ugly CSS hack with several accessibility, usability, browser-compatibility, and even copyright problems, and it was totally out of control (it was used even in a user signature!). As announced above, the objective of the new project Wikipedia:WikiProject Usability/Clickable images is to remove this template completely, or at least to use it only when "absolutely necessary" (I'm optimistic, I think it can be completely removed). Similar templates were successfully removed, as you know (Template:Wikisourcesmall, Template:Noclick).

The process is pretty smooth, but some wikipedians complained about it (in fact very, very few. Only two so far). As I'm the only contributor listed in this project, they think it isn't legitime, and clickable images aren't bad if only one wikipedian doesn't like it. I know this isn't true because some of you and other wikipedians have helped me in this issue.

I would like to ask you to join to the project, so it has enough consensus. It doesn't matter if you don't have enough time to contribute, but if you list in it as a participant I would feel enough people support me, and stop the complains (but of course contributions are always welcomed, that will be great).

Of course, any objection to this project is also welcomed. I don't want to waste so much time in something seen unimportant. Please, let me know if you think I'm wrong, thanks! Best regards, --surueña 10:07, 13 January 2007 (UTC)

Oh dear lord. When I created the template (yes it was me, please don't kill me!) I considered putting a notice on it saying "Anyone using this in a signature will be hunted down and beaten violently" or words to that effect. But I figured nobody could be that stupid... *sigh*.

Anyway I know that imagemap is a better solution where it works, and am keen to help with the transition where possible. the wub "?!" 17:22, 1 March 2007 (UTC)

Hello, I was shocked too when I noticed that clickable images were used in user signatures, but fortunately there were very few cases and for a very short period of time. We have a lot of work spreading the word about web accessibility...

Thanks for volunteering with the replacement of clickable images, but probably we will have to wait to discuss this issue in the technical villagepump until the imagemap extension's bug with templates is resolved. Best regards, --surueña 15:39, 5 March 2007 (UTC)

Jaws and Wikipedia

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)

Good work. I'll examine it more closely once I've caught up with everything. Graham87 00:16, 13 March 2007 (UTC)

MOSNUM and accessibility

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)

Consider ending the practice of using accesskeys

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).

Animated Picture of the Day

The current Picture of the day, Image:Translational motion.gif is extremely distracting; it may well cause problems for users with cognitive disabilities. It appears to breach WAI-WCAG Web Content Accessibility Guidelines. I've proposed that it be replaced ASAP, and that we have an agreement to only use still images for PotD in future? Thank you. Andy Mabbett 23:22, 14 May 2007 (UTC)

Hello Andy. You are right, WCAG guideline 7.3 states with priority 2 that "Until user agents allow users to freeze moving content, avoid movement in pages." Furthermore, if we identify this as a problem I think we shouldn't restrict only to the Picture of the Day but to all animated images (all articles are also subject to have animated images). But animated images in general are useful, do you know if current browsers can be configured to show a still image of an animated gif? In that case, we should warn to people with cognitive disabilities about the animated images, and how to turn of animation. What do you think? --surueña 09:19, 15 May 2007 (UTC)

Articles should use a still image, or text, to link to the animated version, with a prior warning. Andy Mabbett 13:47, 15 May 2007 (UTC)

The Main page PotD did use a static image and warning. Template:POTD protected/2007-05-14. The same can be done in any situation here, though I think calling for animations to be removed everywhere by default is overdoing it. Wikipedia is not censored, is heavily disclaimed, and anyone who has problems with animated images is likely to have disabled them in their browser (which is easy in Opera, and possible in Firefox[5], I don't know about IE.) --Quiddity 19:24, 15 May 2007 (UTC)

Pages which transcluded that picture had the animated version; behaving in a reasonable manner so as not to disadvantage people with disabilities is not censorship. Given that you "don't know about" the most commonly used browser, your preceding statement is without foundation and does not trump the WAI guidelines.. Andy Mabbett 19:43, 15 May 2007 (UTC)

I simply don't have access to the various versions of IE; I was meaning to implicitly invite anyone who does, to contribute a reply.

Could you perhaps clarify the problem with an example or two? What kind of disabilities are affected by animated images? Do the images at Earth#Orbit and rotation and Engine#Modern need to be removed/made-static and have a warning added? Every other animated image on the site?

The only example I can think of that makes obvious sense to make static/warn about, is Strobe light, which is of course linked to from Photosensitive epilepsy. Though possibly its small size makes even that ignorable.

We simply need more to go on, than "is extremely distracting" and "may well cause problems".

Finally, it's the Picture of the Day, it's meant to be distracting! --Quiddity 23:22, 15 May 2007 (UTC)

"We simply need more to go on, than "is extremely distracting" and "may well cause problems". " Indeed, which is why I cited WCAG.

"Do the images at Earth#Orbit and rotation and Engine#Modern need to be removed/made-static and have a warning added?" - Yes.

Andy Mabbett 12:04, 16 May 2007 (UTC)

They make JAWS behave more sluggishly (with all modern versions of JAWS I have including the latest one). This is because when the JAWS rendering engine sees a change in a page, it thinks it is a new page and tries to redraw it. This tech support bulletin is slightly relevant, though things have improved since it was written. For what it's worth, I just turned off animations in Internet Explorer - it can be done easily through the tools menu - and sluggishness at the article Earth disappeared. I had never thought of that before I read this conversation and I haven't found anything in the JAWS documentation about non-flash animations. I like the way the picture of the day section works on the main page and I have no objections to animated images being featured as long as they are not directly displayed there. However, in actual articles, I think only static images should be displayed directly. Graham87 12:43, 16 May 2007 (UTC)

I'm going to copy some of this across to the thread at Wikipedia:Village pump (proposals)#Avoid movement in pages, let's keep further discussion at that more visible location. --Quiddity 17:21, 16 May 2007 (UTC) - archived at Wikipedia:Village pump (proposals)/Archive AK#Avoid movement in pages

Downloading fonts?

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)

Curly quotes problematic?

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)

Now at Wikipedia talk:Manual of Style/Archive 83#Curly quotation marks -- John Broughton (♫♫) 20:49, 6 November 2007 (UTC)

Image alt text in templates

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 [[Image:whatever.jpg|thumb|right]] 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 &nbsp;, or something? — SMcCandlish [talk] [cont] ‹(-¿-)› 18:20, 7 August 2007 (UTC)

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)

As for the second part of your question, "&nbsp;" 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)

JS-hack for section edit links

(copied together from talk pages of Graham87 and Lalue.)

A german user creates a JavaScript-Hack for my Monobook-JS, which put the Editlink behind the heading, so that Jaws-users (and other SR) now simply can navigate with "h" or "Shift+h" from heading to heading and always hear the section-title first. This gives me a very fast navigation and I don't need the content-menue no more.
surueña described this problem with section-editlinks and headings here on this page. You can also use this JS, wehen you go here, type in your username and push the "implement-button". Here you will find the code for that very nice function. Some german admins want to implement this functionality into the MediaWiki-software, so that after this all SR-users simply can jump from heading to heading and hear the section-title first before the editlink, without needing this special JavaScript-hack. What do you think about this? regards from Kassel in Germany. -- Lalue 08:00, 10 August 2007 (UTC)

Cool, thanks for telling me about this script. It certainly makes things easier when going through headings - I've added it except I've commented out the "== Change section heading links ==" part and that made the script work for me. I'm happy to meet another Wikipedian who uses the site with screen readers. I wish you luck for the accessibility project at the German Wikipedia; I only know a bit of German from one of my assistants at school so I can't really participate there. If there's anything you need let me know - I've managed to do just about everything possible on Wikipedia as a normal user, and I have a test copy of MediaWiki where I have experimented with the admin interface. Graham87 09:14, 10 August 2007 (UTC)

Maybe we can find some Wikipedians, which could give me help with translating at important and difficult points. For example, there is a new tool for blind, which schow the recent changes optimized for screenreader without all the ( ) and the links talk and contribs. Its just a fast developed tool from a german user but it schows, what I want to make a lot of special pages look like, while using a special skin for blind people. Unfortunately there is a comma, which appear always in the second line, but it seems difficult to get it away from there.
Nice to hear, that you like the code which changes heading and editlink. :-) -- Lalue 11:08, 10 August 2007 (UTC)

As for the recent changes tool, I like it - it's not as cluttered as normal recent changes in Wikipedia. However the only problem I find is that the user page link is not useful for IP addresses, as IP addresses don't normally have user pages. It'd be better to link to the contributions page.

One big problem with making Wikipedia less cluttered for screen readers is the sheer amount of information present in pages like the history and recent changes. I sometimes find the talk links from recent changes handy when I want to quickly give someone a warning. I have been thinking about how to make the history pages easier to use for the blind and have not thought of a way without losing functionality. Just about everything on the history page is linked and it took me a while to figure out what all of it meant.

Graham87 13:55, 10 August 2007 (UTC)

Yes, you ar right. Loosing functionality is not goog but maybe we could create a skin for blind persons, which allows to activate a simple mode for fast navigating and newbies and a "full version" with the complete functionality. I think, the special pages could be optimized for screenreaders, so that there is a much better usability for the blind. I mean the Tab-Index and a better way to present the informations. I am afraid, that i don't know the right words for what I try to explain but for the beginning of our work its enough. Maybe I could find someone to help me with translation. -- Lalue 15:49, 10 August 2007 (UTC)

Yes, that would be a good idea - a simple skin for the blind would make it easier for newbies to Wikipedia. They could change to the advanced skin later. One of the other problems I see is that many blind people simply don't get enough training on how to use their screen reader with the Internet effectively, and therefore become confused when coming on to Wikipedia. I wish we could also do something about that ... Graham87 03:26, 11 August 2007 (UTC)

I thought about a help page for blind newbies with contents like this:

• creating a new account (CAPTCHA)
• usefull preferences and how to make it
• CAPTCHA wehn inserting extern links (in germany only the first days for new users
• using the common screenreaders with MediaWiki (preferences and navigating, differences between SR-versions)
• behaviour of Jaws while editing in form mode (sometimes parts of content disapear and what to do against that)
• access keys (problems and solutions)
• describing special pages and how to work with them
• how tow to implement the above mentioned JS-hack (until there maybe is a patch for MediaWiki)
• first experiences on the own user page (sandbox is in my opinion not good for that, too much traffic)
• using the Windows Notepad-editor instead of editing directly on pages (writing "outside" and then copy and paste, less risk for editing conflicts)
• describing a typical WP page (memues, structures, infoboxes, pictures, icons, navbars, ...)

I work on such a help page at de.WP but it should been translated into other languages later, depending on the local specials in other Wikipedias. I'll hope, we both (and others?) could find out, whats all necessary for this kind of a help page ...
What version of Jaws are you using now? Which special non standard preferences do you use for Jaws? Have you experience with other screenreader-software like Window Eyes or NVDA? What browsers do you use? I use Jaws 7.1 almost with standard preferences and IE6 with classical support in the Jaws-HTML-options. I don't have a Braillebar and only use the speech synthesizer Eloquence, my best friend. ;-) -- Lalue 08:56, 11 August 2007 (UTC)

Wikipedia:Using JAWS describes the layout of Wikipedia pages - I didn't write it but expanding it to cover the differences between JAWS versions was on my to-do list. JAWS 7.10 and later are the only versions which interpret all CSS on Wikipedia pages properly. How do you solve the problem of disappearing text in MediaWiki? I generally just delete and reinsert text and do a screen refresh until I have the result I want, and afterwards I preview the edit of course! I've gotten used to using MediaWiki's editing interface so I have no need for an external editor unless I'm doing something very complex (I wrote most of the Études page on Chopin using an external editor for example.

I use JAWS 8 with Eloquence and no braille display (though I'd like one). I have experience with NVDA and have dabbled with all the other major screen readers at some point. I have my Monobook.css set not to display the size of the page in the article history because I didn't find the feature useful when it was implemented. I have my maths output set as TeX and read it with JAWS that way. Apart from that, I have no unusual preferences set - though I have played with the classic skin. Graham87 09:30, 11 August 2007 (UTC)

Good to know, that you have experience with other scrrenreader and several Jaws-versions, so that I maybe can ask you about the differences depending on MediaWiki. Sometimes the refresh with Jawskey+Escape don't work and then I jump a little with Ctrl+Home and Ctrl+End and after that the lost textpart is again readable. Does the refresh work for you always at the first time or do you need to repeat it a few times? -- Lalue 06:59, 13 August 2007 (UTC)

I know a lot about the differences between JAWS versions because I've done quite a bit of JAWS scripting in the past. I have never seen insert+escape work to recover lost text in the MediaWiki edit window - I can usually find it again by arrowing around and deleting characters if needed. I always put the text back though. :-) I have never tried jumping between the top and bottom of the edit window - I will try that next time it happens. Graham87 07:11, 13 August 2007 (UTC)

Please have a look at bug 11555. I proposed to exchange the section title and the edit link. --Revolus 00:53, 4 October 2007 (UTC)

Featured article star

Why does the example have {{featured article}} (I presume it means that and not {{featured}}, 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)

I've removed that example. I see {{featured-article}} as the polar opposite to a template like {{stub}} - 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)

Diffs

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)

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)

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 <span> is the start of the change and the </span> is the end of it. Graham87 11:35, 12 September 2007 (UTC)

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)

Disagreement between two editors over a matter of accessibility

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)

Colored boxes

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)

It looks like the table that was the problem has been modified to address the concerns. -- John Broughton (♫♫) 20:20, 6 November 2007 (UTC)

Data tables

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)

Game	Date	Tournament	Round	Ground	Opponent	Score1	Report
1	19 Sep 2007	UEFA Champions League	Group Stage	A	Sporting CP	1 – 0	Attendance: 39,514 Referee: Herbert Fandel 62' Ronaldo

Last updated: 20 Sep 2007
Source: UEFA Champions League 2007-08 and FA Cup 2007-08
¹Manchester United goals come first.
National flags for Ground and Opponent columns are only shown when different from that of Manchester United.
M = Match; Ground: H = Home, A = Away, N = Neutral, HR = Home replacement, AR = Away replacement.

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)

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)

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)

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)

WikiProject proposal

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)

Now live at Wikipedia:WikiProject Accessibility. Graham87 11:55, 17 October 2007 (UTC)

Accessibility-related problem at discussion page

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)

Overhaul required

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)

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)

Colour additions

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)

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)

That's sound, I think this is a good idea. Cheers —surueña 20:43, 22 October 2007 (UTC)

Striking text out

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)

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)

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)

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)

Hide/show buttons?

I'm curious; does Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text apply to hide/show buttons like used in infobox templates and templates displayed at the bottom of articles? (f.e at the bottom of Heavy metal music and the Tom Cruise infobox). Because this hide/show functionality is just a cascading style sheet trick I always thought content hidden this way is still picked up by screen readers etc.. (and when copy-pasting hidden text the hidden text is put on the "clipboard"). In other words, is this hide/show functionality an accessibility issue? Cheers Kameejl ^(Talk) 10:33, 29 October 2007 (UTC)

Well, it is for screen readers which don't understand any CSS at all - not even the CSS imbedded in the page. I never had a problem with them on JAWS 5.1 because it could read CSS that was directly in the HTML source. It is an accessibility problem for people using legacy browsers or technology (like a lot of blind Linux users who still have to use text-based browsers), but it doesn't produce junk on a non-JavaScript/CSS browser so it's nowhere near as bad as HiddenStructure. Graham87 12:55, 29 October 2007 (UTC)

What would be the worst case scenario? CSS incompatible browsers will display the (hidden) content by default, will they? Only the hide/show functionality won't be available as far as I know. I don't think it is a big accessibility issue. I will test it on Lynx any time soon to see if the information is displayed correctly.

I'd like to add an hide/show button to an infobox (similar to the actor infobox) but there is a user that won't accept it due to accessibility reasons. I feel a hide/show button is an acceptable functionality, since it is being used by other wiki elements. I don't feel this functionality is an accessibility hazard. Am I wrong? Kameejl ^(Talk) 14:44, 29 October 2007 (UTC)

However, even if screen readers don't have problems with hide/show buttons, other wikipedians with different disabilities can face more difficulties with this kind of links (e.g. motor dysfunctions). —surueña 20:22, 30 October 2007 (UTC)

Blinking text

There has been some discussion on Talk:Blink element about whether there should be a working example (as opposed to just showing the source code for an example). I've argued that if there needs to be an example of what blinking text looks like then it should be done with an image rather than the blink element so as to ensure maximum support (similar to how the examples in the SVG article are actually all PNG files generated from the original uploaded SVG). However, in an article with several paragraphs about the accessibility concerns arising from having any blinking content, it would be rather ironic to include such an image. As the issues of blinking text doesn't seem to be covered in any Wikipedia guidelines, I thought I'd ask here for advice. —Safalra (talk) 14:04, 17 November 2007 (UTC)

I'd be more concerned with the sensory overload that blinking text might cause for some users. Blinking text, especially if it's rapid, could cause anything from minor headaches to seizures. I would only advocate including the image under two conditions:

1. It is far enough down the page that a user would have to scroll to see it, using any browser.
2. A warning (one that resembles the normal disambig notices (This page is about blank, for other uses see blank, etc etc) would probably be fine) stating very explicitly that there is an image that blinks in the page.

It might not be a bad idea to compile of a list of articles that have moving images or illustrations and/or place them in a category.

Just my two cents. l'aqúatique ^talktome 02:44, 18 November 2007 (UTC)

I've responded with a suggestion to link an example at the article's talk page. Further discussion would be more appropriate there. Graham87 04:16, 18 November 2007 (UTC)

The page might be too small to make sure the blinking is off the screen. Also, Photosensitive epilepsy isn't really an issue. We're not talking about flashing the entire content of the article, it would be flashing one word, possibly even just a single character as an example. If a blinking asterisk could cause a seizure, than so could the blinking cursor in the edit window of Wikipedia. Vicarious (talk) 18:37, 19 November 2007 (UTC)

Hello, Vicarious. As you probably know the Web Content Accessibility Guidelines say that blinking should be avoided, without exceptions (e.g. full paragraphs or single word).[6] Are you sure that even a small animation in a illustrative image can't be problematic? I prefer the solution proposed by Graham, which is also used for the animations featured in the main page. Best regards —surueña 12:53, 20 November 2007 (UTC)

The link you provided states first that the entire screen shouldn't flicker because it could cause a seizure, and secondly that blinking content should be avoided because it would be unreadable to some people. Content meaning the person is trying to read the thing that's blinking and can't. As for Graham's suggestion, I mildly prefer a hide/show button but am ok with that solution. Vicarious (talk) 17:59, 20 November 2007 (UTC)

The irony here, is that the page itself states that blinking text should be avoided because it can cause seizures. It can also be incredibly distracting for those with processing disorders. Even mildly autistic people can be sent into sensory overload by blinking text. I believe that Graham's idea so far is the best. l'aqúatique ^talktome 18:08, 20 November 2007 (UTC)

Image issues

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)

Wikipedia:WikiProject Council/Directory

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)

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)

		The Random Acts of Kindness Barnstar
		To Kirill for going out of your way to fix the accessibility problem at Wikipedia:WikiProject Council/Directory. Your efforts have helped to make Wikipedia more accessible for all. Many thanks! l'Aquatique talk, Jeepday (talk)

"tooltips"

What we call tooltips is in fact the standard title attribute of an element. Is it actually known that a physical action is required to show these in all browsers? Or could some user-agents e.g. speak them along with the rest of the text. Use of e.g. <abbr> which uses the title text is specifically recommended by many other authorities, explicitly for accessibility purposes. —Random832 18:16, 3 December 2007 (UTC)

With for example Template:R-phrase, I know that the screen reader JAWS won't speak the tooltips or the abbreviation expansions by default but it can be instructed to do that. I don't know much about the accessibility for other screen readers, however. Graham87 23:18, 3 December 2007 (UTC)

For information, Template:R-phrase is based on Template:Abbr, and further down the line on a class or element which, frankly, I don't know what it is yet! Tooltips are also used on wikilinks and images… Physchim62 (talk) 18:11, 6 December 2007 (UTC)

But what is the status of such tooltips. Screenreaders may not read them out loud, but then, if there is a link to a more explanatory document closeby, it should be fine. In the case of the template R-phrase, these links are almost exclusively used next to a wikilink (like: "R-phrases: {{R1}},{{R2}}", see e.g. Methanol, in the box on the right hand of the page, hazards section). For the majority of people the tooltips are an easy way of getting more information, though for people who have access to the tooltips, as well as those that use a screen-reader, the wikilink to what R-phrases are is next to it. In the post by Graham87 is a link to JAWS. I don't know what JAWS is, so I have to actually click the link, so that is not different from the situation as it is for people using a screen reader. Tooltips just provide a bit more on-hands information, though they should/must be used on elements where an explanatory wikilink is nearby. --Dirk Beetstra ^{T C} 18:41, 6 December 2007 (UTC)

Expanding on this, making things more accessible would be that all wikilinks in a document would support the element of a one-liner tooltip which quickly gives more information on what lies behind it (e.g. first sentence of the document linked to), not in discouraging or forbidding the use of tooltips altogether. --Dirk Beetstra ^{T C} 18:50, 6 December 2007 (UTC)

Relevant article from a well-known author on web usability: Using Link Titles to Help Users Predict Where They Are Going. --Itub (talk) 19:48, 6 December 2007 (UTC)

Dirk, the suggestions about tooltips on all links has lots of usability benefits, but I think you are not seeing the point of the accessibility issue. The information in the tooltips is, as Random points out, actually stored in the title atrribute. As far as I know, in most browsers the only way to access this is by mouse hovering, but Random is right to ask that we find out exactly how screen readers do deal with them. In contrast, to follow a link you do not have to click on it. In most browsers, you can use the keyboard to tab through the links, without using the mouse (which requires much better motor control) at all. We can also assume that screen readers and so on have appropriate methods for following links, as following links is/has been a more fundamental aspect of web browsing than viewing title attributes for a long time.

Consider the R-phrase example. The title attribute was used explicity to produce tooltips because "it would be nice to have the textual descriptions of these as well" but "I suppose that would take too much space". If this is the addition of something "nice" which not everyone can access, but doesn't really need to, it is not such a big deal. If it is a solution to a real problem concerning how to fit in necessary information, then there is something wrong, as the problem is still present for some users, but the partial solution means few people are aware of it. (In this particular case, the use of the templates in the context of a wikilink is relevant to this distinction, but I am not trying to make an argument for or against these templates, rather trying to use them as an example to explain the issue.)

My opinion is that it is most unfortunate that the software does not yet support <abbr>, as this would allow the use of tooltip while at the same time using the recommended HTML for abbreviations, which should be utilised by more and more accessbility software. JPD (talk) 12:17, 7 December 2007 (UTC)

I think indeed that it should be in such a way that "If this is the addition of something "nice" which not everyone can access, but doesn't really need to, it is not such a big deal." In the R/S-phrase case in a way it is a problem there, the full sentence does not fit in the box .. but then, if you take out a catalogue where they sell chemicals, they only show 'R 1,5,7,9' as well and you have to browse to the index to find what is what. But since Wikipedia is not a paper encyclopedia, we can use features which are not possible on paper, as long as we make sure that anyone can access the information. And I believe that is the case in the R/S-phrase case. Maybe in the guideline here it should say, that tooltips/hover-texts are discouraged, but if they provide easier, hands-on information that they can be used when they do also provide a link (closeby) to more information so everyone can get to the information.

The rest would be an extended function of the mediawiki software, which would be a nice gadget. We don't have that, so that part of the question is more for Village pump, or bugzilla. --Dirk Beetstra ^{T C} 12:44, 7 December 2007 (UTC)

I see this exactly as a case of the "nice addition for those who can use it, but not required to get access to the information", which means that there is no reason not to use the tooltips. I think this use of the tooltips is precisely analogous to the use of color--we are not going to forbid the use of color to make things clearer or nicer just because some people are colorblind. But we need to make sure that colorblind can still use the site. For example, a plot where the only way of telling the difference between two lines is the color should be discouraged, but a plot where, in addition to the color difference, one line is solid and the other is dotted is fine. Similarly here, anyone can follow the link to get the information, so there is no accessibility problem. The tooltip is merely a helpful extension for those who can use it. --Itub (talk) 13:28, 7 December 2007 (UTC)

I've used sometimes and contributed to/created the templates {{abbr}} and {{abbrlink}} (but they are somewhat experimental) as a way to fix the lack of the HTML <abbr> tag — a tag which can improve accessibility.[7] My idea was to create these templates so people start using it, and meanwhile submit a bug report.[8] Finally, when MediaWiki supports this HTML tag my plan was to modify these template using the <abbr> tag instead of a tooltip. Hope this helps —surueña 22:00, 9 December 2007 (UTC)

Use of image (with alts) as indicators?

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)

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)

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)

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)

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)

Great, thanks - we'll make sure to correct the tables. --MASEM 04:25, 8 December 2007 (UTC)