Wikipedia talk:Manual of Style/Accessibility/Archive 1

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 &rarr;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, 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. -- 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:
 * 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 &mdash;XHTML/HTML attributes lang (and xml:lang ) by the former, and class="IPA" by the latter&mdash; 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 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 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:

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 &amp;nbsp; / &amp;#160; 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. --&#160;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 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 "-&gt;" 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. &amp;euro; 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. --&#160;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:
 * 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, and some of those glyphs can be found in the Basic Latin and Latin-1 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",&hellip; 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&hellip;), 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
 * 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.
 * 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&ntilde;a (character entity reference)
 * Urue&#241;a (decimal numeric entity reference)
 * Urue&#xF1;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 ' &ntilde; ' character with the &amp;ntilde; entity to improve its accessibility :-) Best regards. --surue&ntilde;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&hellip; 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 &amp;ndash; and &amp;mdash, and the minus sign like &amp;minus; , otherwise they could be easily confused with a normal hyphen. Or non-graphic character, like &amp;nbsp; for the non-breaking space. Or sometimes a | should be written as &amp;#124; when it must appear in a template call, for example. --surue&ntilde;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?


 * 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):


 * 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. —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 ( 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.

Hello Graham, how do you do? As you know, I'm currently working in the Accessibility project, and there's much work to do&hellip; 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&ntilde;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&ntilde;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 Manual of Style (links) and 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&hellip; --surue&ntilde;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. --&#160;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 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, but the cells are only used for layout purposes.

But I would like to disscus it while developing the 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 &lt;div&gt; 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 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 &lt;font&gt; tags, then I prefer the solution also working with my browsers. --&#160;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. ) / series box / succession box . 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. --&#160;Omniplex 01:53, 15 May 2006 (UTC)


 * I've reverted them &hellip;because&hellip;
 * 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&ntilde;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 &lt;div&gt; tags only, but maybe a simple wikitable is better for old browsers. Best regards --surue&ntilde;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 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? (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 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 Accessibility . I've also added a note about this to help:Section, 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&ntilde;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 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.   which uses the title text is specifically recommended by many other authorities, explicitly for accessibility purposes. —[[User talk:Random832|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. Graham 87 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:, ", 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   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   attributes for a long time.
 * Consider the R-phrase example. The  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, 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 &lt;abbr&gt; tag &mdash; a tag which can improve accessibility. My idea was to create these templates so people start using it, and meanwhile submit a bug report. Finally, when MediaWiki supports this HTML tag my plan was to modify these template using the &lt;abbr&gt; tag instead of a tooltip. Hope this helps &mdash;surue&ntilde;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.  --M ASEM  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). --M ASEM  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. Graham 87 03:33, 8 December 2007 (UTC)


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