Wikipedia talk:Manual of Style/Accessibility

Text size

As a person with good corrected vision, I find the {{Reflist}} text too small for comfortable reading, this must be worse for those with more serious visual problems. The accessibility guidelines have nothing to say on type size, perhaps something should be added? Rich Farmbrough, 10:07 18 February 2008 (GMT).

Just my thoughts here. The difference between the main text and text in {{Reflist}} looks like about two points. On my computer the text in the references of Road appears to me the same size as text on the front page of the Seattle Times, so I don't see a problem. I think most people expect to see references supplied in font size that is smaller then the main text, it is what we usually see in print and bound books. I should also add that I have played with just about all my computer and browser settings for font size, so what I am seeing may not be the same as what a user on a virgin system is seeing. Jeepday (talk) 15:03, 18 February 2008 (UTC)

Currently, mediawiki:common.css is defining .references-small { font-size: 90%;}

I'd thought there was some agreement somewhere that 92% was the smallest we should use anywhere, but I can't find the discussion I'm looking for currently. (See Template:FootnotesSmall and its talkpage for a bit of discussion about 92%)

However, as long as we're allowing text to be resized by the user manually, such that they can increase fonts with their browser whenever needed (ctrl-+ and ctrl-− in firefox), I don't think we need to change anything drastically. Because user defaults (browser program/settings, OS font settings, monitor size/screen resolution) vary so drastically, we can't be perfect for everyone. -- Quiddity (talk) 18:59, 18 February 2008 (UTC)

Rich just added the issue that I wanted to add. The Wikipedia is the only web site I regularly visit which has routine and ubiquitous use of small font sizes for matter that I want to read. I'm not going even attempt to reverse the decisions to use small fonts, but could there been a global setting in user preferences for minimum font size displayed (i.e. the floor of the font size). This would enable a person with a slight impairment such as myself to set it to 10 points, while people with greater impairment could set it to 12 or 14 points.

To points raised above: The problem really isn't in the browser but in the Wikipedia renderer (or any web page with combining extra large and extra small fonts). The comparison to printed media is not accurate: the printed page is analog, and monitor legibility of smaller fonts to the visually impaired doesn't scale in the same way. patsw (talk) 20:18, 18 February 2008 (UTC)

Note: I was comparing display font on the web pages Road and Seattle Times, Not print to web Jeepday (talk) 20:29, 18 February 2008 (UTC)

It seems to me that the only reason we use small fonts is to look like traditional designed-for-paper scholarly works. Rich Farmbrough, 20:42 18 February 2008 (GMT).

And to reduce the size of massive refs sections, eg William Gibson#References, which seem to bug some people. Personally, I'm often tempted to replace {{Reflist}} with <references/>, but don't simply to avoid low-priority arguments/reversions. -- Quiddity (talk) 21:37, 18 February 2008 (UTC)

Rather than switch conventions (a very low-priority, but very argumentative argument waiting to happen), it may be useful to know that an individual can fix this easily (just for them). One just adds

 .references-small { font-size: 100%; }

to your Special:Mypage/monobook.css.

Perhaps it might be worth gathering some similar options and including them in the preferences as a simple "visually impaired" setting. Personally, I've always used Firefox's minimum font size to globally fix this problem. It makes some sites look ugly, but honestly, they looked uglier before. JackSchmidt (talk) 22:25, 18 February 2008 (UTC)

Small text addition to guideline?

Can we add a line to this page about using small size text? It's a hindrance to people with poor eyesight, and even those with good eyesight (read me) find it a turn-off. Matthewedwards (talk • contribs • email) 06:45, 26 August 2008 (UTC)

Yes please. I've been asking for the same thing everywhere for ages. (Lots of relevant discussions at MediaWiki_talk:Common.css/Archive_4#Font_size_reduction and Template_talk:Reflist#Font_size and Template_talk:Reflist/Archive_2008#Font_size and somewhere:infobox and further up this very page at Wikipedia_talk:Accessibility#Text_size and probably lots elsewhere.) -- Quiddity (talk) 07:27, 26 August 2008 (UTC)

Infobox size doesn't bother me. Everything that is an infobox should be in the main prose of the article as well. References.. meh.. <references/> doesn't make them small, and should be used for articles where there's fewer than 20 references, I think. {{Reflist}} I suppose makes them smaller so the page doesn't take too long to load when there is a lot of references. Matthewedwards (talk • contribs • email) 07:59, 26 August 2008 (UTC)

Font size has no effect on page loading time. Using many citation templates will make the page slower to load; for a dramatic example of this, see United States. Graham87 11:16, 26 August 2008 (UTC)

Oh. OK. And since posting that I looked at those links, and I agree - reflist should either be made 100% or 95%. Matthewedwards (talk • contribs • email) 16:27, 26 August 2008 (UTC)

Is your complaint about the default font size (which is something you can easily change on your own computer), or about using different font sizes? WhatamIdoing (talk) 19:58, 26 August 2008 (UTC)

My complaint is about articles where the font size has been forced to be smaller. It often appears in lists and tables, such as at All-NBA Team. I haven't actually seen it used in prose. When I read the discussions provided by Quiddity, I am even more convinced that we need a line to say "no small fonts". And I shouldn't have to change my default font settings or add a script to my monobook, or anything else. The majority of our readers are not logged in, and they don't get to do that. Matthewedwards (talk • contribs • email) 03:41, 27 August 2008 (UTC)

Our implementation of <blockquote></blockquote> makes everything 85% too. Damned hard to read. (I'm making a note at MediaWiki talk:Common.css#Font sizes) -- Quiddity (talk) 04:26, 27 August 2008 (UTC)

Might you, however, encounter this problem on other websites occasionally? And might you be inclined to solve all your problems at once, in about ten seconds, instead of trying to reform each webpage one by one?

In Safari (browser), you go to Preferences>Advanced>Universal Access and tick the "Never use font sizes smaller than (fill in the box)" button. In Firefox (browser), you go to Preferences>Content>Font & Colors>Advanced and set the "Minimum font size" in the menu. I don't run the Microsoft browser, but I assume that similar features exist there, too. WhatamIdoing (talk) 05:30, 27 August 2008 (UTC)

Only on badly designed websites ;) Rather than just fixing things for myself, I'd rather help everyone else who is having problems, but who don't even know where to complain. You might like to read about Web accessibility, and contemplate all those barely-computer-literate users who access the web through library terminals. Think outside your own box of experience. -- Quiddity (talk) 05:50, 27 August 2008 (UTC)

Actually, I know several people with significantly impaired vision, and I haven't found any that don't know how to fix this for themselves. The issue here is that we can't predict what size font is going to work for all computers. If we declare that my default typeface (Times 16) is the minimum, then that's going to prove to be disruptively large for other people. This is a user-fixable situation, not a one-size-fits-all situation. And certainly if you have a problem with your computer's default setting, then you should fix your computer's default. WhatamIdoing (talk) 07:33, 27 August 2008 (UTC)

Disagree. Um, some of us have preference for non-essential text to be in a smaller size, in terms of choice. That is an aesthetic preference, not an accessibility issue. And in my browser, at least, if I find the text too small - and sometimes I do! - I utilize the Ctrl-Scrollwheel function (or Ctrl+Plus or Minus), to up the size of all text until I can read the smallest. I can't say I have any accessibility issue with small text. I find it hard to understand how anybody could have an insurmountable accessibility issue here, with dynamic resizing and/or the Magnifier function of Windows. That's my .02, YMMV. LaughingVulcan 00:23, 11 September 2008 (UTC)

I also disagree. I've expounded at the broader forum at MediaWiki talk:Common.css#Font sizes. For the purposes of the discussion here, the gist is that none of the accessibility guidelines seem to recommend minimum or larger font sizes.  —Michael Z. 2008-09-11 04:28 z

Gadget proposal

Can I have some more opinions about adding a gadget to move the section edit links so that they are easier to use with screen readers? Graham87 14:00, 1 June 2008 (UTC)

I've just voted for the bug that fixed this in the software, don't forget to vote also for this one! BTW, also just noticed that there is a specific category for accessibility MediaWiki bugs, which is a good thing (and very encouraging, indeed). It's important to tag new accessibility related bugs with this tag, and add old bugs to this category (if all of us vote for them, they will be fixed in less time). I've just tagged a couple of old bugs. Cheers, —surueña 11:25, 3 June 2008 (UTC)

I read in some bug report that developers ignore votes. I can't remember where I read it, but I've seen many bugs which caused a lot of distress bug 9213 being an example, not being acted on for months. The accessibility keyword gives the bug a high priority, and I think adding that to all accessibility-related bugs is more importannt. Graham87 12:00, 3 June 2008 (UTC)

OK, understood. I searched and tagged more accessibility-related bugs, but there are surely more. Cheers —surueña 13:40, 3 June 2008 (UTC)

Navboxes need more flexibility

As currently written, WP:ACCESS demands that all navigation boxes be placed after the lead and before the table of contents. While I think this is fine for some navboxes, I can't support this approach for all navboxes in all articles, because of the three problems it causes:

• Implying an inappropriate level of importance. {{Cardiac glycosides}}, like hundreds of similar medicine-related navigation boxes is intended as a convenient alternative to manually adding long, identical lists of medication-related articles to See also in dozens of articles such as Digoxin. Putting it at the end of the lead is essentially putting See also at the end of the lead. It's obvious from the visual layout that this template was intended to be placed at the very end of the article: it runs full-width across the screen. Also, can you imagine anyone starting at Digoxin for the purpose of finding Proscillaridin?
• Screwing up the formatting. Look at what happens to the formatting at Phylogenetics if you move {{Evolution3}} after the text of the lead. The navbox runs down into the text of the next section. On older browsers, this could result in covering up text. (And on not-so-old browsers, either: In my entirely up-to-date browser (and given my font settings), the taxobox very slightly displaces an image so that it covers up the first four words at Plumeria#Etymology and common names.)
• Overloading the lead. A huge number of science and medicine articles have large infoboxes (sometimes called taxoboxes) -- particularly if you look at articles on medications or living organisms. Consider what happens when you have both an infobox and a navbox in the lead. Think about what Digoxin would look like if the navboxes were added to the lead. You'd have rather more screens of 'sidebar' navboxes than you would of text.

I think that we need to clarify in this guideline that not all articles should have all navigation boxes at the top. Navboxes in the lead should probably be restricted to shorter navboxes that are believed to be of immediate interest to the general reader, and even then only added to the lead in the absence of a large infobox (i.e., when it won't make subsequent sections illegible).

Furthermore, if the information in the navbox is essentially See also material, then it should be placed at the end of the article. Portals, for example, should probably be placed in the See also section in most articles. After all, if you're already at Plumeria, you probably want to read about these flowers instead of taking an immediate trip to Portal:Plants.

Does anyone object to clarifying these points? WhatamIdoing (talk) 18:54, 24 August 2008 (UTC)

I don't believe this guideline intends to demand that navboxes be placed in the lead, rather to state that when they are placed in the lead, they should follow the text. SandyGeorgia (Talk) 19:14, 24 August 2008 (UTC)

I'm all for clarification. So I don't mind. Butwhatdoiknow (talk) 20:27, 24 August 2008 (UTC)

I agree with SandyGeorgia, it doesn't try to enforce that all navboxes should be placed in the lead, but because the current practice is to put some (vertical) navboxes at the top of the article it is more accessible to move them below the lead than above it. Of course it doesn't suggest that those (horizontal) navboxes usually put at the bottom of the article should be moved to the top (is that your point?). But adding a clarification in the text can avoid any misunderstanding, so feel free to add it to that guideline. With respect screwing up the formatting and overloading the lead, this guideline doesn't create those problems because there are a lot of navboxes so long that will reach the first section even if it is placed above the lead. Maybe that's an issue with the CSS or browsers, I don't know, but IMO we shouldn't discuss that here. BTW, thanks for your interest in improving the guidelines, WhatamIdoing, and for all your updates, Butwhatdoiknow. Cheers, —surueña 20:54, 24 August 2008 (UTC)

I imagine that WP:ACCESS doesn't intend to demand that all navboxes appear in the lead, but it fails to provide for any alternatives. Compliance with this guideline is mandatory at FAC, so we really need it to authorize all of the possibilities (or to explicitly limit itself to the specific instances that it means to control). WhatamIdoing (talk) 22:11, 24 August 2008 (UTC)

I think this is the part that is missed:

• When the optional elements are used they should be in the following order:

It doesn't demand those items be in the lead; it says when they are in the lead, they should be in that order. That doesn't contradict, in my mind, the navbox guideline at WP:LAYOUT (which has navboxes at the end of the article), but I agree that we need more clarity here. SandyGeorgia (Talk) 22:25, 24 August 2008 (UTC)

Yes, a clarification can improve the wording here. Please, note that when I wrote that guideline what I had in mind was articles with up to 1 infobox, and one vertical navbox (both usually at the top) —and zero, one or several horizontal navboxes at the bottom— which was the common practice. But now it is very common to have more than one vertical navbox in an article, so this guideline should also recommend what to do with vertical navboxes placed outside the lead section (as Graham says below, they should be placed at the end of any section, just before another heading to be able to skip the navbox quickly to that heading). —surueña 09:14, 25 August 2008 (UTC)

White space

This is coming up more often now that I'm watching for it at WP:FAC, so I could use more guidance. When an infobox is very very very long, placing a vertical navigational box below the text in the lead results in an extreme amount of white space. So, editors have been placing the navbox under the infobox. This is a no-no per the guideline and for screenreaders. But I can't move it to the end of the text in the lead because it creates massive white space. And I can't move them to the end of the article because they are vertical templates and don't work well at the bottom of the article, where they belong according to WP:LAYOUT. Does ACCESSIBILITY on screen readers have any opinion on placing a vertical templates somewhere in a section in the middle of the article, below the lead? See the issues in my recent edits, trying to fix AMX-30E. I don't know how to solve that navbox, and the article nominator is questioning on my talk page what to do. This is the version before I moved the navbox down. SandyGeorgia (Talk) 21:04, 24 August 2008 (UTC)

The main problem I have with navboxes is moving past them to the rest of the article. I prefer them at the very end of the article for that reason, but before the TOC or at the end of a section is fine, because I can navigate past them by navigating to the next heading. Graham87 00:57, 25 August 2008 (UTC)

Is it just as easy to skip over the infoboxes? Why should an infobox go first, but a "sidebar" navbox be last in the lead? WhatamIdoing (talk) 07:14, 25 August 2008 (UTC)

Well, the idea is that whereas a navbox is a very long collection of links to related articles, and therefore many people are not interested at first in them, in theory an infobox is a brief summary of the article so you are interested in reading it before the lead. But maybe that assumption is wrong. What do you think, Graham? Do you usually read whole infoboxes, or do you skip them often? Can you skip to the lead section easily? In that case, maybe the infobox should be placed below the lead and the vertical navboxes below other sections. Cheers, —surueña 09:14, 25 August 2008 (UTC)

I just experimented with placing an infobox below the lead text, and I don't think that is something that the community would accept. It's unsightly. SandyGeorgia (Talk) 16:13, 25 August 2008 (UTC)

I agree. Infoboxes are very useful, and they should be at the beginning of the article, if not at the top at least just after the lead section. But I prefer to put them at the very top, as done now. —surueña 21:09, 25 August 2008 (UTC)

SandyGeorgia, after seeing your fixes to AMX-30E I understand your point now. It's true, that special kind of navboxes relying in the {{FixBunching}} template are an accessibility problem: they are designed to be placed just below infoboxes, and if you try to move them below the lead section the whole (graphic) layout will be broken (see [1]). I think that your decision of moving that navbox to the bottom of the article was the correct one, but those navboxes are designed to be placed below the infobox so we must find a solution and inform the authors of those infoboxes about the accessibility problems. Anyone with enough CSS knowledge to avoid breaking the layout when placing the infobox above the lead and those navboxes below the lead section? I will ask in Template talk:FixBunching... —surueña 09:59, 25 August 2008 (UTC)

Thanks ! But if I understand correctly, you're saying it's also possible to place a vertical navbox below the text in any other section in the middle of the article? SandyGeorgia (Talk) 16:13, 25 August 2008 (UTC)

Yes, from my POV that's accessible. However, I think that should be avoided for one reason: wikipedians actually don't read the guidelines / policies, they just repeat the conventions seen in other articles. And therefore, the rules must be very, very simple to be able to remember them. Initially it was very common to put the infobox above the dablink to "save space", but thankfully nowadays people have accustomed to put them at the very top (after several months seeing that articles were changed). That rule is easy to remember. We are also changing the images in the middle of articles, so people get used to see them just below headings or inside a section, but never just above a heading (when a level 2 heading is just before a level 3 heading, for example, I always put the image below the level 3 heading even if the image can also logically belong to the level 2 heading, to avoid seeing images just above any heading. See [2]). And it would also be easy to remember to put vertical navboxes just below the lead section, i.e. in front of the table of contents. If we also allow that vertical navboxes can be placed in the middle of articles, I think it would be harder to remember that images should be just below a heading and vertical navboxes just above. IMO that would lead to confusion (i.e. wikipedians would probably think that there is no rule so they put images and navboxes in any position). Maybe this is just non-sense, but I've been working with these rationale (please guys, let me know your opinion about this!). So IMHO I would say: the vertical navbox must be placed just above the TOC (but we must also decide what to do when there are more than one navbox within an article). What do you think? —surueña 21:09, 25 August 2008 (UTC)

Also (more navbox)

The text currently says: "Navigational boxes should be just after the lead section so a Wikipedian using a screen reader can jump to the table of contents without reading the whole navigational text."

What does this mean? "Please put a long list of articles before the table of contents, so we can find the table of contents more easily"? I thought that the entire point was to put the long list of articles before the TOC so that the reader could conveniently skip the rest of the article and go to a more interesting one, without having to skip to See also or end-of-article templates first.

If someone can explain to me the actual goal here, then I'll happily help wordsmith the rule. WhatamIdoing (talk) 22:19, 24 August 2008 (UTC)

I don't know, but it's easy to get to the table of contents because it's a second-level heading. Graham87 00:59, 25 August 2008 (UTC)

Graham, is a navbox at the end of a section in the middle of an article a problem? Some vertical navboxes don't lend themselves well to being placed at the bottom of an article. SandyGeorgia (Talk) 01:26, 25 August 2008 (UTC)

No, it's not. The idea is that an screen reader or a text browser a web page is serialized, so the goal is to be able to read in a logical order the article. Many articles have a dadlink and an illustrative image and caption at the top, for example. If the article has first the image and then the dablink, in a graphic browser it doesn't care much, but a screen reader would read first the image's caption, which is part of the article's contents, and after that will "jump" outside the article to read the dablink (and after that the lead section again). That's illogical, and can be a big problem to wikipedians with learning disabilities (well, that was I think, I haven't performed any experiment). The good organization is to first hear the dablink, then the image caption, and finally the lead (if after hearing the caption or the lead you realize that's not the article you are looking for, you can just jump to the top of the article again and click on the dablink). In the case of a navbox, the idea is that probably you don't want to hear the complete list of related articles, so you can just jump to the next heading (including the table of contents, which have an h2 header). If there is text between the navbox and the next heading (e.g. the whole lead section), you would miss that part of the article. But it doesn't matter if the navbox is just before the TOC or another heading, but the usual practice is to put them at the top of the article. I hope this can clarify the goals :-) Cheers, —surueña 09:32, 25 August 2008 (UTC)

Special cases

Some short articles have a very long vertical navbox, but they have so few sections that they don't even have a TOC. Therefore, the navbox cannot be place below the lead section (see for example [3], and [4]). So either we have to make here an exception, allowing the navbox above the lead section, or either disallow completely the long navbox (just a link to the main article in the see also section). Opinions? —surueña 10:24, 25 August 2008 (UTC)

I personally dislike vertical navboxes (see the next section) and wouldn't mind if they were banished from existence and all navboxes were standardized to horizontal boxes at the bottom of the article. But I have zero expectation that will ever happen, so ... SandyGeorgia (Talk) 16:18, 25 August 2008 (UTC)

I don't dislike them, IMO they are useful and provide uniformity to Wikipedia. Well, I like articles with just one vertical navbox, more than one is somewhat confusing. And I agree that it's very unlikely that people stop using vertical navboxes, even if a policy or guideline mandates that. In any case, we can just try to enforce a correct use from the point of view of accessibility, vertical navboxes aren't inherently inaccessible when correctly used. In this case, I don't really know if we can suggest that stubs shouldn't have those navboxes. —surueña 20:25, 25 August 2008 (UTC)

How I navigate pages with JAWS and my thoughts on navboxes

I can't find a good place to fit this reply, so I've created a new section for it. My screen reader JAWS uses quick navigation keys that can jump to the next HTML element of a specific type, get out of the current HTML element or go to the next different HTML element. Other modern Windows screen readers, including the free NonVisual Desktop Access, use a similar scheme. In JAWS, to get out of infoboxes, I press the ">" key to move to the end of the table, and to move to the TOC from the lead section, I press "H" to move to the next heading (as the TOC is a level 2 heading). My problem with navboxes is that there's no way to reliably get out of them by jumping past HTML elements. I usually use the "n" key (move to the next non-linked text block), but that usually gets me to the wrong place. Otherwise, it helps if navboxes are either at the end of an article or close to another HTML element (a heading, a table, etc). Here's a full list of JAWS keystrokes including Internet keystrokes. —Preceding unsigned comment added by Graham87 (talk • contribs) 14:38, 25 August 2008 (UTC)

And what about infoboxes? Do you usally skip them, or are a good summary of the article? —surueña 14:51, 25 August 2008 (UTC)

I think we're trying to solve a non-existent problem. Graham, could you take a look at Suicide note and tell me whether you can skip the first template there? WhatamIdoing (talk) 21:44, 25 August 2008 (UTC)

I can get close to the end of it with one keystroke. Moving to the first non-linked text moves me to the last item which happens to be a self-link for "suicide note", and moving to the next div tag moves me to the text "This box:", which is close enough to the end of the navbox. I can't move past the navbox with the table navigation keys because it seems to be a one-column table which JAWS considers to be a layout table, and by default, JAWS does not count those. As for Suruena's question, I use infoboxes to get a piece of information quickly, but otherwise I just skip past them. Graham87 06:09, 26 August 2008 (UTC)

All the navboxes I found today (well, yesterday) are fundamentally tables. Can you give me an example of a page that you can't get past (or at least very close to the end of) the navbox? WhatamIdoing (talk) 06:31, 26 August 2008 (UTC)

No, not the ones I've checked through. It seems that hitting "z" to go to the next division gets me out of the navbox most of the time, and if not, hitting "n" to get to the next non-link text will also work. I didn't think of moving to the next division to get out of navboxes before ... I'll keep it in mind. Graham87 11:16, 26 August 2008 (UTC)

So it shouldn't actually matter where the navboxes are placed then?

Placing a vertical navbox at the end of the lead is a layout problem. It looks a bit strange to have the navbox start at the top of the table of contents instead of at the top of the page (when there are no other images and no other infoboxes present), and a long navbox (longer than the table of contents) can interfere with the text of the next section. If it really didn't cause any more trouble for you than the typical infobox, then I'd rather put the navboxes at the top of a section instead of the end. WhatamIdoing (talk) 19:56, 26 August 2008 (UTC)

No it doesn't really matter where navboxes are placed. The trick for mooving past them I found isn't intuitive, but it works. Graham87 00:49, 27 August 2008 (UTC)

Thanks for your response. Since it doesn't actually matter for accessibility, and it does matter for visual layout, then I'll change the guideline to list them after the infoboxes instead of after the lead's text. WhatamIdoing (talk) 02:58, 30 August 2008 (UTC)

To make sure I follow. Vertical navboxes are now are OK after the infobox in the lead (although still preferred at the bottom of the article)? And if a vertical navbox is placed within another section, does it still need to be at the bottom of the section? Also, on updating this, the text is also at WP:LEAD and WP:LAYOUT, I think. SandyGeorgia (Talk) 03:05, 30 August 2008 (UTC)

Also, WhatamIdoing, I'm going to be traveling, so if this changes, if you don't mind, please make sure Tony1 (talk · contribs) knows so he can add it to the August monthly updates for the WP:SIGNPOST. SandyGeorgia (Talk) 03:07, 30 August 2008 (UTC)

eeek, a third question. WhatamIdoing, you put navboxes *before* images; are you sure about that? SandyGeorgia (Talk) 03:09, 30 August 2008 (UTC)

Sandy, I'd rather have your questions now, no matter how many, than a mess later. My intention was to put navboxes after infoboxes, because when both are present, the infobox is more important by far -- being, as it were, an actual part of the article instead of merely part of the navigation infrastructure -- and should appear at the top of the article (instead of much further down the page or in a later section).

However, since the infobox is actually part of the article, then (per other comments on general principles on this page) we should probably not have first some article (infobox) — then some not-article (navbox) — and then go back for the rest of the article. But I'm (a) open to other arrangements and (b) no longer certain that it makes sense to have infoboxes listed separately from navboxes at all. I invite other opinions. WhatamIdoing (talk) 04:53, 30 August 2008 (UTC)

The problem is many articles have all three: an infobox (with an image), followed by a separate image, followed by yet another navbox. We used to have them in that order. I no longer know what matters; would need to hear from Graham, but I'll be traveling and will probably lose track of this. And I can't think of a sample off the top of my head, but I've seen all three crammed into one lead. SandyGeorgia (Talk) 04:59, 30 August 2008 (UTC)

I don't thinkthis is as big a deal as spelling errors, broken tables, or things like that. I'd slighgtly prefer the image being before the navbox because a well-written image description will give important information for the article and I think the image is more important than a navbox. But this shouldn't be a hard and fast rule ... if it looks better for the image to be below the navbox, then put it there. Graham87 10:27, 30 August 2008 (UTC)

Update, navboxes before text

OK, so the preferred (not required) order is images before navboxes, and navboxes are now before the text, not after. I've updated this page as well as WP:LEAD and WP:LAYOUT; if anything changes, please sync those pages as well. SandyGeorgia (Talk) 13:11, 30 August 2008 (UTC)

Sidebars

Sandy,

Can you give me an example of a horizontal {{navbox}} used in the lead? I've never encountered it, and I have looked at some thousands of articles. (Many of which, I admit, display properly standardized navboxes created by Arcadian.) WhatamIdoing (talk) 22:48, 25 August 2008 (UTC)

The AMX-30E article raised earlier in this discussion (the nominator has now moved that to the bottom, but lots of editors do what he had done.) I can't think of any others right now, but I come across exactly that a lot. When the infofox isn't so long, or when there isn't an infobox, the horizontal nav works in the lead. The problem at AMX-30E was that, because of the long infobox, moving the horizontal navbox to after the text left a huge white space. SandyGeorgia (Talk) 22:53, 25 August 2008 (UTC)

Ah, I see. So it's not so much that it's a horizontal navbox as it's a tiny navbox. WhatamIdoing (talk) 00:41, 26 August 2008 (UTC)

By complete coincidence I saw the bit where it says navboxes in the lead and came to question it here. I've never come across this. Sandy, are there any current FAs where it can be seen? Matthewedwards (talk • contribs • email) 06:44, 26 August 2008 (UTC)

Family of Barack Obama family tree

What do people think of Family of Barack Obama ? Andy Mabbett | Talk to Andy Mabbett 22:43, 26 August 2008 (UTC)

You mean the family tree in Template:Obama family? That's impossible to read here - reading it with table navigation commands doesn't work. I prefer to read through the text to be honest. Graham87 01:08, 27 August 2008 (UTC)

Frankly, it's distracting, and I just don't think it adds all that much to the article. Plus, it's sort of difficult to read and actually glean information from. L'Aquatique[talk] 01:27, 27 August 2008 (UTC)

I've tried to cleanup the article itself (linked headers, self-redirects in the template, etc).

The tree-chart itself is using Template:Chart, which doesn't appear to be very widely used currently. It should possibly be using Template:Familytree (which is widely used) instead? I haven't time to investigate the differences between the 2 templates currently. Perhaps feedback/concerns would be best directed to their talkpages (or at least mention there, that we're discussing them here).

IMHO: Yes, bad accessibility. Would an imagemap would be a better way to handle these? -- Quiddity (talk) 01:29, 27 August 2008 (UTC)

Yeah, it'd probably be better with the image description like "John Doe (1800-2000"). Graham87 01:55, 27 August 2008 (UTC)

Familytree

{{Familytree}} still looks inaccessible to me - where are the table headers, the scope attributes, etc? How does it linearise? It's not tabular data, is it? Andy Mabbett | Talk to Andy Mabbett 19:36, 27 August 2008 (UTC)

I don't disagree with the fact that {{Familytree}} is inaccessible (or, as I prefer - one helluva convoluted template). But, in its defense, even when drawing family trees on a sheet of paper, they quickly become ridiculously complicated. I'm willing to take a shot on working on some code improvements if someone has a particular recommendation/suggestion. JPG-GR (talk) 19:45, 27 August 2008 (UTC)

[outdent] Accessibility isn't (at least not in this case) about complexity; this is the equivalent of drawing the family tree on paper, then placing it face-down and expecting someone to read it. If you can (and are sighted), view an instance of the template, in Firefox, using the "web Developer" toolbar with "miscellaneous - linerarize page" activated. Even after teh removal of huge anmuonts of white space, it looks like:

	Elimelech 	
 
	Naomi 	
 
 	Boaz 	
 
	Ruth 	
 
	Mahlon 	
 
	Orpah 	
 
	Chilion 	
  
	Obed 	
 
	Jesse 	
 
	David 	

See also Wikipedia:Accessibility#Layout tables

Andy Mabbett | Talk to Andy Mabbett 20:16, 27 August 2008 (UTC)

Firstly, thanks for showing me what another thing on Web Developer does (as a web developer, that toolbar is incredibly useful). As for this template, I see what you mean, but I'm not quite sure how to adapt the template. Short of having a prose explanation accompanying it, that is. JPG-GR (talk) 16:54, 28 August 2008 (UTC)

My pleasure; I love the WD toolbar! As for improving the template I think the first thing is to find good examples of accessible family tree mark-up elsewhere on the web. Andy Mabbett | Talk to Andy Mabbett 19:06, 28 August 2008 (UTC)

See also teh FT on Charlotte Brabantina of Nassau. Andy Mabbett | Talk to Andy Mabbett 22:43, 28 August 2008 (UTC)

That family tree is easy to read, but it's not a complex one. As far as accessible family tree solutions, Family Tree Maker is (or was) accessible with JAWS - see this mailing list thread among others for proof. Graham87 02:19, 29 August 2008 (UTC)

Tournament bracket templates

Please see {{16TeamBracket-Compact-Tennis5}} and other members of Category:Tournament bracket templates which contain tables which seem to me to be very inaccessible. Thank you. Andy Mabbett | Talk to Andy Mabbett 19:30, 27 August 2008 (UTC)

Like at 2005 U.S. Open - Men's Singles ... those tables are very hard for me to read, and I can only make some sense out of them because I know a bit about tennis and the fact that a set usually has six games. At the very least they need to have column and row headers. Am I right in my reading that Roger Federer beat David Nalbandian in straight sets 6-2, 6-4, 6-1, in the first quarter-final? I'm not even going to try to read the rest of the table. Graham87 03:09, 28 August 2008 (UTC)

Yes, you are correct. It seems to me that it might be better to flip the chart so the winners in the final round would appear/be read first? Of course, that would be counterintuitive for the average English reader who is used to reading left to right... L'Aquatique[talk] 03:10, 29 August 2008 (UTC)

I'd expect the quarter-finals to be listed first in a chart like that. It's best to have them in chronological order. It's sort of interesting to find out if any of the top contenders were eliminated, or if there were any surprises. Graham87 05:50, 29 August 2008 (UTC)

"best" in what way? It's not accessible to display them as the are at present. Andy Mabbett | Talk to Andy Mabbett 08:17, 29 August 2008 (UTC)

The current ordering is the best way because it's how people would expect to find the results. The way they are displayed, however, is hideous for accessibility. Maybe it'd be better to have one table for the quarter-finals, another table for the semi-finals and so on. Either that or the table rows and columns need captions, and there needs to be a uniform number of rows and columns. How I imagine it is a row containing something like "first quarter-final | Roger Federer v. David Nalbandian | 6-2, 6-1, 6-4|Roger Federer" with column headings of "match title | players | score | winner", where vertical bars separate the elements in my examples. Note that there is no problem with large tables if they're needed: this list of Sydney weather observations from the Bureau of Meteorology is completely accessible. Graham87 03:47, 30 August 2008 (UTC)

Military history campaignboxes

The Military History Wikiproject has been using navigation campaignboxes placed under the infobox of articles, for a long time. They are often used singly, as in Battle of Moscow, and sometimes in multiples, for example, there are three in Operation Barbarossa.

Are these an accessibility problem? Can they be improved by providing an anchor and/or skip link in the box, or by including it within the infobox table? Or is there a problem simply with having navigation near the beginning of an article?

We're currently discussing refurbishing a body of navigation templates for tanks and armoured fighting vehicles at WT:AFV#Navigation templates, and I'd like to incorporate input from here.

Thanks. —Michael Z. 2008-08-28 15:38 z

They're not much of a problem, because as discussed above, they're easily skippable. They would e even easier to skip past if they were part of the infobox table. However the fact that they're collapsed by default makes them fairly easy to skip past with the arrow keys in screen readers that support these hide/show buttons (and most modern ones do). . Graham87 01:49, 29 August 2008 (UTC)

Horizontal lists

the template {{flatlist}} and its partner {{endflatlist}} are available, to improve accessibility and semantic meaningfulness by marking up what is clearly a list, as such, rather than characters which are read out ("one dot two dot three dot...") by the kind of assistive software used by, for example, people who are blind. Example Andy Mabbett | Talk to Andy Mabbett 20:43, 28 August 2008 (UTC)

I support this idea. Since they are lists, they should have list markup. Graham87 02:19, 29 August 2008 (UTC)

Thank you. Unfortunately, the above ("Bach cantatas") edit was reverted, without any discussion with this project. (I've restored it) Andy Mabbett | Talk to Andy Mabbett 08:19, 29 August 2008 (UTC)

It was reverted again, with a false accusation of "spamming". The earlier version can still be viewed. Andy Mabbett | Talk to Andy Mabbett 17:25, 29 August 2008 (UTC)

I'll add the above wording to Wikipedia:Accessibility#Lists Andy Mabbett | Talk to Andy Mabbett 08:22, 29 August 2008 (UTC)

I also support this idea. However, the implementation details could use a few tweaks. E.g. The Bach example had a lot of white space compared to the previous diff (I've fixed that easily enough).

More critically, using a bar | (not a pipe, but actually a css border-right according to MediaWiki:Common.css) to separate list items has been disputed previously in navbox discussions: hence {{navbox}} and similar, use bullets and middots (see also the 1st item in Wikipedia:LIST#See also). Is it possible to change this flatlist code to use middots or bullets or similar (or html <li> discs, so that they're not read aloud?)?

Any idea where else class=horizontal is used currently, that changing it would effect? A google search isn't bringing up anything useful (just the initial discussions/additions in 2007). -- Quiddity (talk) 17:09, 29 August 2008 (UTC)

The dots and bullets to which you refer are characters (easily checked by copying and pasting into notepad); so are pronounced by assistive tools (and are decorations, not content, so should be in CSS, not HTML, anyway!). Using some form of CSS bullet or image-as-bullet on LI elements might work; but you'd have to take care of first-child, and pay due regard to resizing issues. I can't help, on the issue of other uses of class="horizontal"; sorry; but I'd guess "few". Andy Mabbett | Talk to Andy Mabbett 17:20, 29 August 2008 (UTC)

Labeling bullets and numbers on lists "decorations, not content" would be disputed by a great many, and (as has been noted for years off-WP) are themselves a completely different form of accessibility problem (not for disabled users, but all users trying to repurpose content) when done in a way (as ul/ol/li and CSS do them) such that they cannot be copy-pasted. The pasted version is essentially gibberish. It's a thorny conundrum. They can be used as simple decoration (as when a list is created for one item, simply to give it a cute, emphasizing bullet), but most often are used to indicate (and with ol/li, to number) a list, in a specific order, as distinct from run-on content. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:08, 1 September 2008 (UTC)

I did not label "bullets and numbers on lists" as "decorations, not content"; I was referring specifically to dots (e.g. that in {{•}}, used as separators (as in "cat • dog • mouse"), in otherwise unstructured text, when some form of bullet, on a properly marked-up list, would be more semantically correct. Andy Mabbett | Talk to Andy Mabbett 01:09, 1 September 2008 (UTC)

Further thoughts: Replacing templates like {{•}} with proper, CSS list styling will also vastly reduce the number of template calls, helping server performance and improving page-load times. That said, a short term fix might be to replace those templates with something using a non-breaking space (&nbsp;), styled to have a background image like a dot or whatever. Again, care would be needed to check resizing issues. Andy Mabbett | Talk to Andy Mabbett 18:52, 29 August 2008 (UTC)

The use of a vertical bar character (or CSS equivalent) in place of the bullet character is not acceptable as the bar produced is not perfectly vertical and causes problems reading the lists as you go cross-eyed when there are short entries between the bars. The CSS mark-up needs to produce an unobtrusive character similar to the bullet when applied to lists. Keith D (talk) 22:49, 5 September 2008 (UTC)

There is no "vertical bar type character"; it's a border and is indeed "perfectly vertical". Perhaps you setup is broken? Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:57, 5 September 2008 (UTC)

What ever it is it needs to be something that is small and unobtrusive which is not what the boarder is. The boarder causes problems with viewing of the items and to me I go cross-eyed viewing it. Keith D (talk) 00:06, 6 September 2008 (UTC)

Andy Mabbett: First of all, there is a long standing consensus here at Wikipedia that horizontal lists should not be separated by vertical bars, but by dots. The reason is that vertical bars are pretty unreadable if the words between the bars happen to contain characters like "LlIi!", thus dots are much more readable for the majority of users. Thus dots versus vertical bars is an accessibility issue for seeing users.

And remember, accessibility is not just about blind users, there is also the much larger group of users with poor but still usable eyesight. Such users set their web browsers to show the text in much larger font. Then things like background image bullets are a problem, since they do not become larger when you set your browser to show larger text. Thus for those users image based bullets are not visible. Thus using actual bullet characters are much more accessible for those users.

Also, as SMcCandlish pointed out, using actual bullet characters means that the content is still readable when it is copied for instance into emails or text files.

And some blind users us a Braille display. I bet they don't feel the vertical bars at all, since they are just CSS decoration. And I don't think that those displays show bullet background images either. For those users actual character dots must be much better.

While for the blind users that listens to the text it can't be that bad to hear "item dot item dot item". After all the word "dot" is a very short word and actually works as a pretty nice separator even when hearing it.

So using the dot characters is the option that means that all users can read/hear/feel the lists. That is, the dot character is the most accessible option.

--David Göthberg (talk) 12:23, 6 September 2008 (UTC)

← "Long-standing consensus" can - and where it is harmful, should - be challenged. That said, I'm not insisting on the use of vertical-bar separators, and I don't know anyone else who is. I have already proposed two methods of using dot-shaped separators via CSS, and I've invited others to contribute alternatives. I am fully aware that accessibility is not just about blind users, or have I ever said or suggested such. Users using Braille display might not feel CSS separators; but who to they feel dot characters? How are lists rendered to them overall? Have you asked blind users whether they want to hear the word "dot" fifty or more tines as a separator? I have, and those users of audio browsers I have discussed the matter with most certainly do not. WCAG 1.0 tells us:

3.6 Mark up lists and list items properly. [Priority 2]
For example, in HTML, nest OL, UL, and DL lists properly. [5]

If you have evidence that WCAG is wrong, please cite it. The fact remains that - despite your unsupported assertion to the contrary - using in-line graphical characters as separators presents an accessibility barrier to some users and that marking up lists using in-line graphical characters, without using UL or OL and LI elements, is semantic nonsense. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 13:02, 6 September 2008 (UTC)

Andy Mabbett: Hearing the word "dot" is not a barrier, it is just a word that you hear. And perhaps a slight annoyance to some of the blind users. While not seeing the separator is a big problem (an actual barrier) to the much larger group of users with poor eyesight. Remember, not all Wikipedia readers are 18 years old with 20/20 eyesight.

And regarding my expertise in the matter, let's see:

• I have been programming computers since 1982, used the Internet since 1990, and been making web pages since 1995.
• I have been working at our central hospital adapting computers for the handicapped and teaching them to use the different input and output interfaces that we buy/adapt/build for them, since 1992. Did you know that we now even can connect totally lame people? (Yes, we have thought controlled input interfaces now! They are really slow...) At the hospital we don't follow theoretical guides like the WCAG, instead we use what actually works.
• I have computer geek friends who are blind, deaf, have poor eyesight, use Braille displays and so on. I myself have had eye problems when working with computers since 1988.

(And in case I am not using the most politically correct terms when talking about these things: English is just my third language.)

So Andy, can you point me to where you explain how to insert an actual dot character (not a fixed size dot shaped background image) in horizontal dotted lists using CSS in a way that works for all those user groups? It is probably possible to do that, and might be nice. I have not experimented with it yet.

--David Göthberg (talk) 13:55, 6 September 2008 (UTC)

Hearing the word "dot" is not a barrier - Indeed not. Hearing it over and over again is. Since I'm neither 18 nor in possession of 20/20 eyesight, kindly refrain from attempting to patronise me. I have not questioned your supposed "expertise", nor attempted to use mine a claim to authority (but, if you insist on a dick-waving war: I have been programming computers since 1975; and making web pages since 1994); I have asked you for cited evidence that WCAG is wrong in regard to the issues being debated, not least that lists should be marked up as such. I have yet to find any computer-related technique for any aspect of computing which works for "all user groups", so no, I cannot meet your impossible and red-herring request. Note, though that I have asked others to contribute suggestions for a solution which works for as many people as possible. I note that your comment makes no reference to the fact that the templates, at present, use semantically-bogus mark-up instead of the proper list elements. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 14:07, 6 September 2008 (UTC)

I don't have much time here so I may not have read or understood everything. However, I'll point out that JAWS puts each link on its own line, and all text between two links will be on it's own line. So when I read through Template:Bach cantatas, I hear this, where the commas are a new line: "1, dot, 2, dot, 3, dot, 4" and so on. Graham87 05:10, 7 September 2008 (UTC)

Heading structures

While I'm here...Pigonthewing's edits don't look right. "=" headings are not used, and WP:MOS already has guidance on how to nest subheadings; it's probably best not to do that in two places. Unless someone knows different, I'll revert. - Dan Dank55 (send/receive) 20:53, 30 August 2008 (UTC)

If you disagree with part of my edit, please improve it, rather than reverting. AS to WP:MOS; that deals with stylistic preferences; this page deals with accessibility issues. The correct heading structure is an accessibility issue. Andy Mabbett | Talk to Andy Mabbett 21:43, 30 August 2008 (UTC)

Reverted as WP:CREEP. Pigs, if you can point me to a single article that has actually used random heading levels, I'll reconsider. WhatamIdoing (talk) 01:04, 31 August 2008 (UTC)

Another issue is that there was discussion at WT:MOS (although I'm not sure if we've been explicit in any of the guidelines) that a "=====" may be used sometimes in guidelines in place of the semicolon at the start of a line for bolding; the bolding looks the same, but it lets you link to that subsection. - Dan Dank55 (send/receive) 01:40, 31 August 2008 (UTC)

That's an abuse of semantic HTML, and should be resisted; heading mark-up is for section headings; other mark-up exists for identifying anchor-link targets. Andy Mabbett | Talk to Andy Mabbett 09:15, 31 August 2008 (UTC)

I'll point you to one as soon as I can; but I regularly fix them when patrolling at random. Andy Mabbett | Talk to Andy Mabbett 09:15, 31 August 2008 (UTC)

WhatamIdoing, actually I run into bogus heading levels all the time while tooling around and doing cleanup. The template space is chock full of them, and I encounter it in stubs and Start-class articles frequently. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)

Headings in page template

A quick check shows the heading structure on every page to be broken, in the Wikipedia template (and thus outside the control of ordinary editors) - there is an H1 (the page title) immediately followed by an H3 ("From Wikipedia, the free encyclopedia"); and the page ends with a bunch of H5s ("Views", "Personal tools", "Navigation", "Search", "Interaction", "Toolbox") with no parent other than H1 (and the last headings in the article, which are not meant to apply to it). I raise this elsewhere, as soon as I have time. Andy Mabbett | Talk to Andy Mabbett 09:24, 31 August 2008 (UTC)

You might have good ideas, I'm not the person to say, but there's a steady stream of people who show up on the talk pages of for instance WT:EL, WT:Layout and WT:CITE who claim that we've been doing everything wrong all along and imply that all 2.5M pages need to be changed. This never succeeds. - Dan Dank55 (send/receive) 13:36, 31 August 2008 (UTC)

You may be right; but I'm not sure why that's relevant to this discussion. Andy Mabbett | Talk to Andy Mabbett 14:27, 31 August 2008 (UTC)

I may have misunderstood; I was responding to "A quick check shows the heading structure on every page to be broken". - Dan Dank55 (send/receive) 16:06, 31 August 2008 (UTC)

Indeed - and I don't see the relevance of your comment, to that fact. Andy Mabbett | Talk to Andy Mabbett 16:11, 31 August 2008 (UTC)

←How would you like to fix the heading structure on every page, and will the reader notice any difference? - Dan Dank55 (send/receive) 16:18, 31 August 2008 (UTC)

I'd love to, if I had the relevant access. I doubt it would take more than a few minutes to fix the issue discussed in this section; and yes, they would - especially if using assistive technology to navigate a page. Andy Mabbett | Talk to Andy Mabbett 16:39, 31 August 2008 (UTC)

Further info: WCAG says:

3.5 Use header elements to convey document structure and use them according to specification. [Priority 2]
For example, in HTML, use H2 to indicate a subsection of H1. Do not use headers for font effects. ([6])

and:

Since some users skim through a document by navigating its headings, it is important to use them appropriately to convey document structure. Users should order heading elements properly. For example, in HTML, H2 elements should follow H1 elements, H3 elements should follow H2 elements, etc. Content developers should not "skip" levels (e.g., H1 directly to H3). Do not use headings to create font effects; use style sheets to change font styles for example. ([7])

On further reflection, "From Wikipedia, the free encyclopedia" isn't even a heading, and should probably be parked up as a paragraph. Andy Mabbett | Talk to Andy Mabbett 16:50, 31 August 2008 (UTC)

Concur with both Andy Mabbett/Pigsonthewing and with Dank55. It is an abuse of semantic HTML, especially the "from Wikipedia" tagline being done as a heading (I wonder who on earth thought that was a good idea? That's like 1995-style Web markup!) But it's also another of those issues where if you just show up and say "all of WP is messed up and we have to fix it immediately!" everyone's going to ignore you. I strongly recommend a piecemeal approach, fixing one problem at a time. First off, I would look at all of the Wikimedia projects - do all of them consistently abuse h3 for tagline purposes? If so, figure out where the developers and CSS geeks and so forth hang out at meta and try to get a system-wide change made. It probably would be quite trivial to fix - just create a new class with font-sizes and bolding and so forth that is applied to a paragraph or div or whatever the consensus says is most appropriate, then swap out the new code for the old around the taglines' content. This could probably be done in a single afternoon, with almost no system impact, since these things are a matter of include-file templates, not content on every page. Next pick another aspect of the entire overall problem and work on fixing that. Maybe MOS (if any of it addresses headings in a way that conflicts with accessibility) and WP:Layout need adjustment to make it clearer that heading levels are semantic, not just visual, and should be done in a specific order. Next look for specific cases of outright heading level abuse; a very clear target of that would be the preload default page created by the "create" button inside {{Documentation}} when taht page is added to a template for which no /doc file yet exists (it creates the subheadings as h3 instead of h2, which is semantically invalid). And so on. Make it a process of incremental progress instead of a campaign of revolution. :-) — SMcCandlish [talk] [cont] ‹(-¿-)› 18:05, 31 August 2008 (UTC)

←

1. if you just show up and say "all of WP is messed up and we have to fix it immediately!"... - who did that?
2. figure out where the developers and CSS geeks and so forth hang out - already in hand.
3. {{Documentation}} - that was next on my list!
4. Make it a process of incremental progress - I tried that, by adding a note to WP:Accessibility (which is the first place you'd expect such issues to be understood). It was reverted.

Andy Mabbett | Talk to Andy Mabbett 18:14, 31 August 2008 (UTC)

1. I was responding to the same phrasing Dank55 was. Yes, I'm exaggerating it, but if that is bothering you, you may have missed my point in the exaggeration, which is that the perception of the message is likely to be this way when it is phrased like that, regardless of the intent. Many editors are alarmist by nature, especially if they focus on guideline pages, and especially-especially if it's a guideline about something some people feel is a touchy subject. :-)
2. Cool.
3. As you noted over there, I've already filed an editprotected about it. I thought about that quite a long time ago, but did not get around to viewing the source of a rendered Template:-namespace page that used {{Documentation}} to see if (after all the subtemplates and other transclusions render) the final result is actually semantically valid. I just did that, and it isn't, so it has to be fixed.
4. WP:BRD. Just because it was reflexively reverted doesn't mean it won't get back in there after further discussion. What's the link to the specific edit history change? Maybe someone just had a problem with the phrasing, or didn't understand the purpose of the edit. Given the depth of the discussion here and now, a reflexive revert is much less likely. — SMcCandlish [talk] [cont] ‹(-¿-)› 19:57, 31 August 2008 (UTC)

1. That the heading structure on every page is broken (i.e. fails to comply with the published specifications which Wikipedia claims to meet) is irrefutable and measurable; it is a binary condition - pass or fail.

4. It's already back. The reason given for its removal was WP:CREEP, even after I had posted justification for its inclusion.

(other points noted). Andy Mabbett | Talk to Andy Mabbett 20:03, 31 August 2008 (UTC)

1. Oh, I agree. The h4 on the "From Wikipedia..." tagline has to go. Getting it to go is going to be a matter of approach (probably both tactics - how you/we/whoever asks - and strategy - who/where is asked).

4. I table-ized the examples, for increased clarity, easy of comparison (just look left and right, no scrolling) and to obviate any concern about it being too long.

— SMcCandlish [talk] [cont] ‹(-¿-)› 21:03, 31 August 2008 (UTC)

Thanks. As a spectacle wearer I find the vibrant red/ green backgrounds make the text dance. Could we use pastel shades, please? Andy Mabbett | Talk to Andy Mabbett 21:08, 31 August 2008 (UTC)

Sure, though these seemed kind of pastel to me to begin with (and I wear glasses); probably just a monitor contrast difference. — SMcCandlish [talk] [cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)

Pigs, I see that you've cited a non-Wikipedia source as your authority. The Wikimedia software apparently doesn't comply with this outside group's rules. What I want to know is what practical difference does it make for a disabled person? Imagine a page skips from Level 1 to Level 3 with no intervening Level 2 header. What problem does this create? Do the screen readers quit reading? WhatamIdoing (talk) 21:23, 31 August 2008 (UTC)

My name is not "Pigs". I've a non-Wikipedia source as my authority because it - the W3C - is, er, more authoritative than Wikipedia, on both matters of HTML standards and web accessibility. Your other questions are also answered on line: a Google search for accessibility + html + heading + levels finds [ this video and a page saying "Without third level headings, the expectation is that there will be no fourth, fifth or sixth level headings there either". So those headings will typically not be found by a screenreader user as the first three results, after the WCAG page I have already cited. Andy Mabbett | Talk to Andy Mabbett 21:45, 31 August 2008 (UTC)

True, your name is Pigsonthewing, which is charming but longer than I feel like typing sometimes.

So the practical issue is that if I'm using a screen reader, and I ask for an outline of what's on the page, I'll probably start with level 1 or level 2 headers. If something in level 2 sounds about right, then I'll ask it whether there's any further information in level 3 headers -- and if there isn't, I'll assume that there are no level 4, 5, or 6 headers (because why would anyone skip a level?) and perhaps have to listen to a long section before getting to the specific part that I actually wanted. Thanks for providing the explanatory link. WhatamIdoing (talk) 23:09, 31 August 2008 (UTC)

My name is Andy Mabbett, which is what appears directly above your statement to the contrary. Andy Mabbett | Talk to Andy Mabbett 00:03, 1 September 2008 (UTC)

Welcome, Andy. - Dan Dank55 (send/receive) 02:42, 1 September 2008 (UTC)

Go to Bugzilla to report bugs with the MediaWiki software. The heading level skipping occurs in the default MediaWiki style sheet and can be changed there. Personally I run JAWS with heading announcements off because I find them distracting, and only try to find out the heading structure of a page when I need to learn how to navigate it. I have other bizarre JAWS settings because I've been using it for ten years now, and I'm very particular about how it should speak. I use the level 5 headings (navigation, interaction, etc.) in Wikipedia for quick navigation, and I wouldn't like to see them disappear, but I suppose I could use the lists for the same function. Graham87 02:49, 1 September 2008 (UTC)

Graham is quite the expert in navigating WP with screen readers, guys, so I'm really interested in that last comment. Can you point me to one or two pages where you use the 5-headings where you don't want to give those up, Graham? - Dan Dank55 (send/receive) 02:53, 1 September 2008 (UTC)

I use them for general navigation when I can't remember the access key for something, or there is no access key. For example I use the toolbox heading to quickly get to a user's contributions page from their user or talk page. Navigating by lists would still work, but "Toolbox" is a much more descriptive indicator of where I am than "list of 4 items". Graham87 03:00, 1 September 2008 (UTC)

Thanks, Graham. I'll pursue the MediaWiki approach later, when I have a few minutes. I'm not suggesting that the level 5 headings be done away with; but that they should be at level 2 or 3 (depending on the their parent header's level). Perhaps they could have an additional, intermediate-level, header, hidden by CSS? Andy Mabbett | Talk to Andy Mabbett 08:15, 1 September 2008 (UTC)

Already there: Template:Bug, raised on 12 September 2004 - just short of four years ago! Andy Mabbett | Talk to Andy Mabbett 22:03, 1 September 2008 (UTC)

Where to put this

Okay, so, aside from WhatamIdoing simply not believing what he's being told, that this addresses well-known and well-understood accessibility issues, the real question is where to put this? I'd be somewhat in favor of moving it to a more general guideline (WP:LAYOUT seems like a likely target) and referencing that from here. By having it in the more general guideline, both the accessibility and semantic web issues can be mentioned without either sounding out-of-place — SMcCandlish [talk] [cont] ‹(-¿-)› 00:16, 1 September 2008 (UTC)

I'm happy for it to live somewhere else (your suggestion seems reasonable; you know these pages better than I do), so long as that page mentions accessibility explicitly; and this one links to it. We seem to have similar issue on {{documentation}} :-( Andy Mabbett | Talk to Andy Mabbett 00:32, 1 September 2008 (UTC)

I have never seen a page with random heading levels (although I've seen several that skipped ==Normal== headings in favor of ===Subsections===), and no example has been produced. You may recall that the original version specified that header levels should not be random.

I refuse to believe that every issue of elegant and ideal HTML coding is automatically an issue of access for disabled users. Thus I asked what actual impact this had on disabled users, since that matters much more for the purpose of this guideline than perfect compliance with some outside organization's definition of the ideal website design standards.

I think this information should remain in this guideline. It can also be added elsewhere -- WP:LAYOUT will likely accept it, and Help:Section might -- but a person specifically looking for accessibility information should be able to find it all here. WhatamIdoing (talk) 01:17, 1 September 2008 (UTC)

This isn't a guideline yet...it claims to be, but the only cat it's ever been in AFAIK is the accessibility cat, and that's not a subcat of Category:Wikipedia policies and guidelines. I think, a lot of people think, this should be a guideline, but let's keep checking around and make sure it doesn't conflict with guidelines first. - Dan Dank55 (send/receive) 02:30, 1 September 2008 (UTC)

Template Documentation headings

Please see Template talk:Documentation#Heading fix. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:27, 8 September 2008 (UTC)

Relevance (lists)

We state here a requirement that unordered lists (those beginning with a bullet instead of a number) not have blank lines between them. There are good reasons for this that have absolutely nothing to do with access for disabled readers, and it's mentioned in other guidelines.

But is this actually an issue of accessibility? Does a screen reader signal the beginning of a list? For example, does this:

• First item
• Second item

get read differently from this:

• First item

• Second item

If there's no actual difference for disabled users, this should not be mentioned in this guideline. WhatamIdoing (talk) 22:47, 31 August 2008 (UTC)

Agree. - Dan Dank55 (send/receive) 02:25, 1 September 2008 (UTC)

Yes, by default, JAWS and other screen readers signal the beginning and end of each list with "list of x items" and "list end". Therefore the lists in this version of Antonio Vivaldi sound horrible. Graham87 02:33, 1 September 2008 (UTC)

Thanks, Graham. Then we should definitely keep this. However, the current text is not IMO ideal. It says, Do not separate list items by more than one line-break. If list items are separated by more than one line break, the HTML list tags will be ended.

This is presumably just fine if you know exactly what a line-break is and believe that invisible HTML list tags are important. However, "no more than one line-break" may be misinterpreted as "no more than one blank line" by some readers, and the relevance of HTML list tags is non-obvious.

Could we rephrase this to something like what WP:MOS says, which is "Do not leave blank lines between items in a bulleted or numbered list unless there is a reason to do so, since this causes the Wiki software to interpret each list item as an individual list." -- except perhaps adding that it causes screen readers to announce each item as belonging to a separate, one-item list? WhatamIdoing (talk) 06:22, 1 September 2008 (UTC)

Agreed with all of that. - Dan Dank55 (send/receive) 13:30, 1 September 2008 (UTC)

P.S. But let's make it clear we're talking about article-space. On talk pages, it's common for people to leave a blank line between someone else's bullet point and their bullet point to enhance readability. If screen readers do a bad job reading this, then we should complain to the people who make the screen readers. - Dan Dank55 (send/receive) 14:04, 1 September 2008 (UTC)

It's not the case that screen readers do a bad job of reading such things; they read what they're given, and if we give them garbage, that's what they'll read. Why should talk pages be any less accessible to people who cannot see, than article pages? In fact, I see that the use of colon characters to indent discussions like this one actually generates definition list mark-up. I wonder if that's a good habit to perpetuate? Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:41, 6 September 2008 (UTC)

Sounds good. I didn't realise that separating lists was mentioned in the Manual of Style when I wrote that section, but it needs to be mentioned in the accessibility guidelines as well. Graham87 14:05, 1 September 2008 (UTC)

Note: <tt> is not <code>

Someone or other seems to be confused about the meanings of some [X]HTML entities. To give examples of source code snippets (like wiki markup, template code, etc.), use <code>...</code>. The <tt> element is nothing but a font-styling tag and has no semantic function at all. I just checked the current version of the W3C HTML specs, and for some reason it has not been deprecated according to the Index of Elements, but this is surely either a typographical error or other oversight, as all other purely-presentational markup has been deprecated in favor of CSS since 1998.

A lot of other semantic (or "logical" as someone wrote in the guideline page – where'd that come from?) elements get confused with <code>, as well, including <kbd>, <samp> and <var> (documentation). These all have distinguishable semantic purposes.

Presently, MediaWiki (or at least Wikipedia's installation of it) actually does not accept <kbd> or <samp>, only <code> and <var> (and <tt>, which we should ignore as being no different from deprecated obsolete junk like <font>, <b>, etc.). This should probably be undone by the developers, as there are often good semantic reasons to use these elements, especially in technical articles and in template documentation. Something for WP:VPT. I have [[WP:VPT#Enable & |proposed this already]], actually.

That fact that most browsers (we cannot be certain that it is all of them, since I doubt anyone, including me, has possibly ever used every browser in existence, and I'm a professional web developer) display <code> and <tt> visually as monospaced, non-proportional text, at the same size and otherwise styled identically, is irrelevant. They have different meanings (or rather one has a meaning and the other does not), and it is likely that some screen readers and other software (XML applications, and such) are already distinguishing between them, and have for some time. Inline microformats like hCard also sometimes depend heavily on the semantics of HTML elements not being violated. (I doubt that hCard in particular makes any use of these specific elements, but that's beside the point; who knows how many microformats their are or will be?)

If for some reason monospaced type is needed but it is not code, it is really more appropriate to use {{Mono|text here}} (a template for <span style="font-family: monospace;">text here</span>) instead of the <tt> version, just to better keep the content and the presentation separate.

PS: We should not use quotation marks with <code>, etc. (other than for purposes of actual quotations, of course), since "scare-quoting" them is simply redundant; the markup itself already sets them apart as non-regular segment of the running prose. I.e., write "use <code>reason=<code> to provide a reason for applying this template", not "use '<code>reason=<code>' to provide a reason for applying this template" (and note that "use <code>'reason='<code> to provide a reason for applying this template" would be severely wrong unless the single-quotes were part of the actual literal string required in the source code!).

— SMcCandlish [talk] [cont] ‹(-¿-)› 23:25, 31 August 2008 (UTC)

I've been guilty of misusing TT; and you're right, so I'll try not to do so again. But microformats do not make use of HTML elements, other than generically, with a few specific exceptions (A, ABBR) and none do or are likely to make use of CODE or TT other than as interchangeable elements. Andy Mabbett | Talk to Andy Mabbett 00:28, 1 September 2008 (UTC)

Moving images

I'm no expert, but I think that moving images like a recent "picture of the day": Image:Tablet press animation.gif and especially flashing images like Image:Strobe.gif could cause problems for people with some photo-sensitive conditions like epilepsy - I don't have that, but I find them distracting. My preference would be to use a static version, and link to the moving image, with a caution in the link in place. Andy Mabbett | Talk to Andy Mabbett 00:54, 1 September 2008 (UTC)

I'd have no objection to tagging moving images as moving and letting users set a preference that they only want to see the first frames of animation; that might have value to people sensitive in one way or another, and it would also help people who prefer to avoid animation because of bandwidth. (I don't keep up with image issues; maybe this is possible already?) Tagging would be much preferable to discarding; animations are very important in sci/tech articles. - Dan Dank55 (send/receive) 02:24, 1 September 2008 (UTC)

Tagging would be a good idea ... complex animations make JAWS unresponsive. I have images turned off in my web browser to save bandwidth, but I realise that isn't an option for everyone using shared computers. I always thought that only still images were displayed on the Main Page with a link to the animation, but that might have changed. Graham87 03:06, 1 September 2008 (UTC)

Notes: This was last discussed at length at Wikipedia:Village pump (proposals)/Archive#Avoid movement in pages (May 2007 archived diff). I won't attempt to summarize it all (though I do apologize to Andy for my tone and goodfaith in some of the comments there), but there are numerous pros and cons to both displaying or not-displaying animations directly within articles. And numerous editors/admins supporting each position, hence no consensus for a change seems to have been reached there.

The relevant policy section is at Wikipedia:Image use policy#Displayed image size, which has stated since late 2005 that "Inline animations should be used sparingly; a static image with a link to the animation is preferred unless the animation has a very small file size." (Though I haven't seen any articles that actually use this idea...)

Discussing this at Wikipedia:Village pump (technical) and/or Wikipedia talk:Image use policy might be preferable(?), but it'd be good to have accessibility experts in on the discussion wherever it is. Hope that helps. -- Quiddity (talk) 19:48, 1 September 2008 (UTC)

It helps quite a lot. I didn't know that policy prefers static images with links to animations in most cases; I'll mention that in my reviews when it comes up. - Dan Dank55 (send/receive) 03:54, 2 September 2008 (UTC)

Or, Tell us if you ever see an article that is already using the static-link method! (I've never seen one.) Perhaps the policy should rather be changed to reflect actual practices/usage...

Personally, I strongly support including the majority of animations directly within the article. The animation at Engine#Modern, or the three used in Horse gait, for example, are immensely informative/educational, and I'd be sorry to see them get removed by one level - where many readers will never discover them. -- Quiddity (talk) 03:51, 6 September 2008 (UTC)

Scope

A lot of people browse Wikipedia on cellphones and PDAs these days. Some browse on Kindle, which has gray-scale only, no color. I imagine some people like to listen to articles from Wikipedia while they're driving. People who use small screens and screen readers would agree with the main thrust of this page, which seems to me to be, put things where people are expecting them to be, to aid navigation. Should we mention that the issues on this page have wide applicability? I think some people think of this page as having more limited scope. - Dan Dank55 (send/receive) 02:41, 1 September 2008 (UTC)

Agreed. The more accessible a page is to "the disabled" (™), the more accessible it is to everyone, not least the people you list - and search engines. Andy Mabbett | Talk to Andy Mabbett 08:22, 1 September 2008 (UTC)

And a large number of people over 40 have a larger default font size on their computers. - Dan Dank55 (send/receive) 13:58, 1 September 2008 (UTC)

Template: Geographic Location

How does {{Geographic Location}} render in assistive browsers? Could it be improved? (For an example, see Bergman, Edmonton#Surrounding_Neighborhoods). Andy Mabbett | Talk to Andy Mabbett 19:01, 1 September 2008 (UTC)

See also {{GeoCompass}} (used on Chelmsford#Nearest places); and {{Compass-table}} (used on Marylebone#Location in Context). It is proposed that these two should be merged into the above. To my mind, the latter looks the most accessible, in that it includes compass-directions as text, and linearises properly. Andy Mabbett | Talk to Andy Mabbett 19:12, 1 September 2008 (UTC)

{{Geographic Location}} doesn't render well with JAWS. The images with no captions sound like "link graphic Compass_rose_pale.svg/50px-Compass_rose_pale.svg", the links for viewing, discussing, and editing the template get in the way, and it's hard to tell what direction you're reading about. {{GeoCompass}} reads OK linearly but it is still hard to figure out what direction everything is. {{Compass-table}} is the most accessible, but the table would be easier to use with row and column titles. When I navigate from east to southeast, I also hear the "southwest" part because JAWS thinks that's the title of the row. Speaking of directional templates, the {{Infobox Australian Place}} shows the suburbs or towns surrounding a certain place, but it's hard to tell the directions of the towns with a screen reader. An example is at Nollamara, Western Australia. Graham87 01:18, 2 September 2008 (UTC)

Use of colour to convey information

WCAG 1.0 says:

2.1 Ensure that all information conveyed with color is also available without color, for example from context or markup. - http://www.w3.org/TR/WCAG10/wai-pageauth.html#tech-color-convey

We should therefore discourage the use of colour (or shading-pattern) alone to convey information, as seen in List of Oasis band members#Timeline. Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 21:48, 2 September 2008 (UTC)

Succession boxes

Simple succession boxes (like the second one here), seem OK, though they do lack headers, but complex cases, like this hypothetical example on the template documentation page, seem less so. Thoughts? Andy Mabbett (aka Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 22:54, 2 September 2008 (UTC)

Link fixed. The second template you mention should be separated out into columns for the title and year. As it is now, it still reads OK linearly. Graham87 04:19, 3 September 2008 (UTC)

If you think the hypothetical situation is a bit much, check out Winston Churchhill's page, it is atrocious. However, there is a reason to all the chaos. In some rare circumstances, an individual will have many more succession titles than most and those need to be documented in the best means available. Currently, those means are succession boxes. They convey the titles and dates, note the predecessor and successor, and show what kind of title it is/was. True, they can take over pages sometimes, but those situations are rare and often the lists are appreciated for their thoroughness. In regards to accessibility, since that is what this talk page is all about, I would say that the information in a succession box is far more accessible sometimes than searching through the article to find it. Sure it is not always the best method, but often (and unfortunately), all the information in a succession box cannot be found in the article itself, either because the information is deemed too irrelevant for the body of the article (but could be important in a larger continuity) or because its entry was overlooked. If you have suggestions for change of the format, by all means suggest it at WT:SBS. We are constantly looking to make our succession boxes cleaner and more accessible. Thank you for your feedback and I hope I provided at least somewhat of a satisfactory reply.
–Darius von Whaleyland, Great Khan of the Barbarian Horde 08:13, 6 September 2008 (UTC)

←Thank you for a detailed response. Please bear in mind that the accessibility discussed here is specifically for people with a disability or other condition which can mean that their use of Wikipedia is not conducted in the same way, or using the same tools, as most of us use. That can include people who cannot see, and who have the pages read out loud to them by their computer. For such users, tables (which is how succession boxes are rendered), when used for layout rather than for tabular data, can be very problematic, because the software reads across rows; and because there is no header row or column to label the others. If you have Firefox, this effect can be simulated by using the "web Developer" extension, then selecting "Miscellaneous" then "Linearize Page". The table on Winston Churchill, while not perfect, and very long, is better than many, because it consists of simple rows. When, like in the hypothetical example discussed above, the first cell in a row covers multiple cells in the remaining columns, its accessibility is reduced. In that case, it can be read, in part, in the order:

• Preceded by Elizabeth
• Lady Supreme of Oceana 1975 – 1983
• Vacant
• Title next held by Jilian
• Empress of Arabia 1975 – 1993
• Title merged with Great Khanna of Asia
• Grand Duchess of Europa 1975 – 1999
• Succeeded by Felicia
• Vacant Title last held by Karl von Igorstein
• Chief Sultana of Africa 1993 – 1999

and so on.

Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:18, 6 September 2008 (UTC)

Let me just throw a suggestion out

I haven't thought this through, and I'm sleepy, so this may suck. Except for a little overlapping at WP:MOS, don't we usually operate under the principle that it's best if guidelines are on the page you expect them to be? When people look at all, they look for information on embedded lists at WP:Embedded lists, guidance on layout at WP:Layout, etc. Since we want to recommend here that people not put blank lines between bullet items in article space, wouldn't it make more sense to have this advice in WP:Embedded list, and to point there from here? We could give more details on the "accessibility" perspective here than at WP:EMBED if we think that's helpful. - Dan Dank55 (send/receive) 02:44, 3 September 2008 (UTC)

Well, Wikipedia:Embedded list breaks the rule about separating list items by blank lines in the section 'However, it can be appropriate to use a list style when the items in list are "children" of the paragraphs that precede them. ' I've been removing line breaks from such lists when I've found them, but I'm not sure that making fake bulleted lists is the best way to indent paragraphs. In short, Wikipedia:Embedded list needs some cleanup as well. Graham87 04:34, 3 September 2008 (UTC)

At the moment, the "no blank lines between items" is going into several guidelines. In general, duplication is bad (because then it has to be kept synchronized), but I think this particular issue now makes an appearance at MOS, EL, LIST, ACCESS, and maybe CITE. WhatamIdoing (talk) 05:07, 3 September 2008 (UTC)

I want to echo WhatamI's comment that duplication is bad. If there is a well developed discussion of a topic in the "wrong" article then the "right" article should link to that discussion. (Alternatively, you can do something like this: http://en.wikipedia.org/wiki/Wikipedia:Lead_section_TT_text .) Butwhatdoiknow (talk) 15:10, 3 September 2008 (UTC)

2008 main page redesign

Copied from WP:VPT:

Discussion is still ongoing in the proposed redesign of the main page. A brief survey was conducted to get a sense of community opinion, and most designs have been modified to reflect the bulk of community desires. The number of proposed designs has also been reduced, and each design is now accompanied with a screen shot. Please help establish consensus, and move this proposal to the next stage of voting.

Someone might want to look at that, from an accessibility PoV. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 21:24, 6 September 2008 (UTC)

IPA in Jaws

Found a possibly useful link, with advice on reading IPA or other Unicode characters in Jaws, by editing an .sbl file. —Michael Z. 2008-09-07 20:55 z

• Getting JAWS 6.1 to recognize "exotic" Unicode symbols

Nice one! I've noted it, with due credit, on Talk:International Phonetic Alphabet and Wikipedia talk:WikiProject Phonetics. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 21:15, 7 September 2008 (UTC)

Thanks, that's a useful find. The small size of the IPA file means that it will also work on old computers with no problems. Graham87 01:47, 8 September 2008 (UTC)

I'm glad it's useful. I had hoped that Jaws users could evaluate it before adding it anywhere—thanks. This should probably be added to topical help at Wikipedia:IPA for English (which Help:Pronunciation redirects to).

Is there an accessibility or screen-reader help page aimed at Wikipedia readers, as opposed to editors? — Preceding unsigned comment added by Mzajac (talk • contribs)

OK, I'll add it there. As for Wikipedia guides for readers using screen readers, I know of the incomplete Wikipedia:Using JAWS and the external Wikipedia guide for JAWS. Graham87 01:19, 9 September 2008 (UTC)

Template 'Unsigned' - text too small.

Please see Template talk:Unsigned#Text too small. Andy Mabbett (User:Pigsonthewing); Talk to Andy Mabbett; Andy Mabbett's contributions 11:41, 8 September 2008 (UTC)

Template for Line 1 of the Monterrey Metro

What do you folks make of {{MtyMetro1}}, the template for Line 1 of the Monterrey Metro? Are ether any examples of good practice for such templates? Or accessible alterntaives to sit alongside them? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:19, 8 September 2008 (UTC)

Style cat

I see this was added to Category:Wikipedia style guidelines. This could be a good thing or a bad thing. If the idea is to put the kinds of arguments that are heard here on an equal footing with the arguments on other pages, that's a good thing, at least when we look at the last several months. If the idea is to create a second page where we argue about embedded lists, leads and layout, that seems like a bad thing. I'm wondering if transclusions from WP:Layout, WP:LEAD and WP:EMBED would be a good idea. - Dan Dank55 (send/receive) 19:49, 10 September 2008 (UTC)

No response, so I take it people are happy. I think the current version does a reasonable job of highlighting the connection between accessibility issues and other style guidelines, and I don't have a problem with this being a style guideline. - Dan Dank55 (send/receive) 15:51, 12 September 2008 (UTC)

It's been classified as a guideline since July 2006...? -- Quiddity (talk) 21:55, 12 September 2008 (UTC)

User:Butwhatdoiknow seems to be experimenting with transcluded sections at this very moment. I really like the non-fragmentation of transcluding, as long as enough people watchlist the new pages: Wikipedia:Accessibility TT lead section and Wikipedia:Lead section TT text currently. Perhaps once the experiment is further along, the talkpages could all be redirected to a central location or two, to prevent fragmentation of discussions. :) -- Quiddity (talk) 21:55, 12 September 2008 (UTC)

It has claimed to be a guideline at the top of the page, but it wasn't a guideline until this month, when it got the guideline cat, per WP:POLICY, Quiddity. The reason POLICY requires the cat is that otherwise, 2 guys could get together and label a page a guideline, and no one would know about it. When pages are added to a policy or guidelines cat, they get announced by VeblenBot at WP:VPP (or at WT:MOS and WT:MOSCO, in the case of style guidelines). - Dan Dank55 (send/receive) 18:37, 16 September 2008 (UTC)

Ah, whoops, I assumed that the category was embedded in the template (like all the talkpage banners, and mbox banners, etc). Which surely should be the case, so that there aren't pages tagged with one but not the other? I'm not a template expert though, so I'm not sure what other ramifications that change would create, with Veblenbot et al. -- Quiddity (talk) 19:25, 16 September 2008 (UTC)

I'm not sure about that reasoning, Dank55; this bot business is entirely new, and I had never heard of the cat until this week. I'm not sure that is how guideline pages have been decided in the past. SandyGeorgia (Talk) 19:48, 16 September 2008 (UTC)

The "subcat guideline|style guideline" template automatically added the style cat, but the "style-guideline" template (which this page uses) didn't. I've checked WhatLinksHere, and I think we're good now; I'm going partly by memory and partly by checking pages, but I think all the pages that use the "style-guideline" template now also have the style cat, and I changed the other templates (style-guidelines, style guideline, etc.) a while ago; "style-guideline" and "subcat guideline|style guideline" are the only two used now on style guidelines pages, I think. - Dan Dank55 (send/receive) 21:11, 16 September 2008 (UTC)

A test

How does a screen reader deal with Decipherment of rongorongo? Also, what about color blindness? SandyGeorgia (Talk) 19:29, 12 September 2008 (UTC)

Accessibility guidelines suggest not relying on colour alone to convey information.[8][9] Joe Clark discusses colour blindness issues at length in his book, available online.[10] —Michael Z. 2008-09-12 21:18 z

And images should always have caption. JAWS reads one of the images in Decipherment of rongorongo as "graphic RR_006.gif/10px-RR_006" which isn't helpful. Graham87 03:50, 13 September 2008 (UTC)

I can work on the colors. As for the image captions, what do you do about inline images which do not have visible captions? kwami (talk) 01:41, 22 September 2008 (UTC)

I don't know, but it's late and I'm not thinking straight. How about using image maps? By default screen readers use only the alt tag to describe images. Graham87 15:48, 22 September 2008 (UTC)

Fractions

A colleague at WP:CHESS] has raised a question about accessible representation of fractions. My impression is that the {{frac|p|q}} approach is better for people with poor but not "disabled" eyesight, like me, but is a nightmare for those who are actually or virtually blind and have to use screen-readers, as e.g. {{frac|3|3|8}} generates the following (X)HTML:

<span style="white-space:nowrap">3<s style="display:none">+</s><span class="template-frac">³<big>⁄</big>₈</span></span>

which is not the value of the fraction but (X)HTML code for a visual representation of the value, and absolute gobbledygook when spoken. Is there a good solution both for people with poor but not "disabled" eyesight and for those who are functionally blind? -- Philcha (talk) 21:19, 21 September 2008 (UTC)

The example you give, 3+3⁄8, reads as "3 superscript 3 end superscript slash 8", on any modern JAWS version above 6.0. While this is wordy, it *is* possible to tell what the fracction is and there's no better way besides putting it into words ("three and three eights"), although that's not a good option for other reasons. The "+" in the "display: none" class will make it read as "3+3/8" in older screen readers, which is not perfect but is also accessible. For fractions like 2/3, the template will read "2/3" which is OK. The other markup doesn't affect JAWS. I'm not sure how the template would read in a refreshable Braille display. In summary, it's not perfect but it's the best that could be done until speech synthesizers can read mixed fractions properly (no pun intended). Graham87 15:46, 22 September 2008 (UTC)

Accessibility of NavFrame

I raised an issue at Wikipedia talk:NavFrame:

Using Firefox 3 with Javascript disabled by the very widely used "NoScript" extension, I find that the "collapsible" sections on {{Infobox Ship Begin/doc}} are already collapsed with no option to expand them.

and AlexSm has replied to point out that he raised the issue on MediaWiki talk:Common.js a year ago but nothing has been done. I view this as a serious failing; can someone assist in finding a remedy, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 18:53, 22 September 2008 (UTC)

collapsible sections and accessibility for sight impaired folks

• Do we have a hard & final word as to whether collapsible sections cause problems with readers for sight impaired folks..? Ling.Nut ^{(talk—WP:3IAR)} 03:36, 24 September 2008 (UTC)

Yes, I would like to know this as well since I use them on my userpage... L'Aquatique[talk] 05:11, 24 September 2008 (UTC)

In modern screen readers, no. They aren't as likely to cause problems as the HiddenStructure hack as an alternative for parser functions because the CSS and JavaScript controlling them is imbedded in the page, so screen readers will follow the browser and will show the new text when the hide button is pressed. They worked fine in JAWS 5.1 released in 2003, and would probably work in earlier versions, so collapsable sections aren't much of an issue at all with widely-used screen readers. Graham87 09:33, 24 September 2008 (UTC)

Help with a geometry article?

I've been working on a geometry article, the Problem of Apollonius, since January and of course I'd like to make it as accessible as possible to as many readers as possible. The article is at FAC now and Sandy suggested that I ask for help here on whether the article is accessible, especially with screen readers. In particular, Figure 11 might cause a glitch? Overall the article is somewhat technical, with several images and equations. Thanks muchly for all your help! :) Willow (talk) 09:52, 24 September 2008 (UTC)

I like mathematics, but geometry was never my strong suit because I couldn't see the diagrams. I understood the intro of the article but got lost around the "Lie sphere geometry" section. To be honest it would help if I could make a tactile copy of the diagrams, but that's not possible over the Internet ... yet. A couple of specific points:

• In the table listing the examples, it would help if the images on the right had a caption. At the moment my screen reader JAWS reads the first image as "Apollonius_PPP_black.svg/100px-Apollonius_PPP_black.svg". A caption of "PPP example", or even just "PPP", since the column header is "example", would work fine.

• In the section "Resizing and inversion", the use of semi-colons to separate sections causes a definition list to be created in the HTML, and JAWS reads it like so: "definition list of 1 items, Shrinking one given circle to a point, list end". I would prefer it if subheadings were used.

I did not notice anything unusual about figure 11. I use LaTeX to read math equations so I was able to read them (with difficulty, as there are so many symbols to digest). The graphics are described adequately and I can ima gine how they'd look (though I'd prefer to have some way of drawing them on paper).

Hope this helps, Graham87 12:22, 24 September 2008 (UTC)

An Argument for a Consistent & Realistic @lang policy for Wikimedia

Copied from User talk:GJR. Graham87 05:15, 29 September 2008 (UTC)

1. When there are English pronunciations of placenames or proper names, then the English version of that word or placename should be used:
   1. for example, the word "France" would not be spanned by a lang="fr" declaration, because in English, "France" is pronounced differently than it is in French;
   2. if, however, one is referring to an historical personage, such as Alfonso el Sabio, then such an instance of a name which has been incorporated into English usage in its original non-English form, SHOULD be marked as lang="es"; Likewise, whenever a placename has an English equivalent (Vienna for Wein) it is, of course, most appropriate to use the English equivalent in an article whose base natural language is English.
2. if there is a word or idiom absorbed into English intact from its language of origin, such as strum und drang, sang froid, realpolitik, zeigeist, gestalt -- any such instance SHOULD be not only marked as belonging to a different natural language than the base natural language declared for the page, but SHOULD also be glossed with the title attribute, because:
   1. not all capable of reading/understanding English will be congnizant of may foreign terms' meanings; and
   2. English is not the primary, secondary or tertiary language of a large numbers of users of thte English version of wikipedia;
3. Use of Latinisms, such as e.g.; i.e.; ca.; fl.; etc. should NOT be marked as Latin, but SHOULD be annotated using the ABBR element of HTML4x/XHTML1
   1. for example: <abbr title="and so on">etc.</abbr>; e.g.
4. a word comprised of non-latinate glyphs should either be:
   1. marked up using unicode (makes lang declarations redundant); or
   2. if entered directly as non-latinate glyphs, then the word should be marked up using the lang="xx" convention

remember, natural language declarations not only assist those using speech output, but those using high levels of magnification and refreshable braille displays

oedipus (talk) 20:11, 28 September 2008 (UTC)

That's very helpful information. Let's add it to the guideline page. Shana tova!-- L'Aquatique[talk] 05:26, 29 September 2008 (UTC)

I think this needs more discussion, and that's why I copied the text to the talk page rather than to the guideline page. How should the language templates be adapted to conform to these guidelines? There will also be issues with page size in articles with many non-English terms. How strictly should the guidelines be enforced? And there is one part I don't understand: how would the title attribute help users who don't have English as their first language? Graham87 05:57, 29 September 2008 (UTC)

Unless its changed recently, WikiMedia (at least, as implemented here) does not support abbr. Note the existence of {{lang}}. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:49, 29 September 2008 (UTC)

1) i am highly cognizant that wikimedia (at least, as implemented here) does not support abbr or acronym, both of which are not only beneficial for accessibility, but for internationalization and disambiguation, as there are many abbreviations, such as "St." which in english can mean "street" or "saint", much like "Dr." can be an abbreviation for both "Doctor" and "Drive"; acronym expansion is essential, not only for speech users, but for those for whom english is not their first language and who may be confused by the use of an acronym.

2) there needs to be a supplement to the language templates syntax, which is purely explanatory. since wikimedia frowns on the use of actual HTML/XHTML code, there needs to be another lang signifier, such as {{fr|le mot juste}} which would simply encase the word in a virtual <span lang="xx"> ... </span> without the language-link prefix, as is generated by the {{lang=de|doppleganger}} syntax.

3) there is also a need for wikimedia to accomodate the title attribute, especially, as i have pointed out above, so that latinisms such as "ibid" can be glossed into english for those unfamiliar with latinisms; this is particularly important for those who have to use the english version of a wikipedia article because one does not exist in their primary natural language -- how is someone who speaks cantonese and mandarin primarily, but who has a reading comprehension of english, supposed to make sense of a latinism? how many native english speakers can provide the meaning of terms such as: "ibid", "op. cit.", "i.e.", or "e.g."? moreover, title provides a means of disambiguation for identical acronyms that expand into different phrases, such as "ADA", which can mean "Americans With Disabilities Act" or the "American Dental Association" -- what happens when one discusses the ADA's ADA policies with regards treatment of patients with transmissionable diseases.

4) how contextual markup is exposed to the individual user must not be the basis upon which standards is set; rather, since it is possible to suppress natural language switching or exposition of title, those who are indifferent to them or are distracted by them can ignore them, but for those who need them, they must exist as part of a document's source code in order to be exposed to those who need and desire them.

oedipus (talk) 17:18, 29 September 2008 (UTC)

See also WP:JARGON; here's a summary. When a "term" (word, phrase, abbreviation, symbol, etc.) isn't understood by a significant number of readers, or differently by different readers, then usually, either define it in the text or replace it with a term everyone will understand. If you keep it, wikilink the first occurrence. (The exceptions are in articles that aren't going to be understood by everyone no matter how hard you try ... defining every term would clutter the text.) - Dan Dank55 (send/receive) 17:39, 29 September 2008 (UTC)

Plain language markup can be accomplished with {{lang|fr|le mot juste}} (e.g. le mot juste) as opposed to {{lang-fr|le mot juste}} (e.g. French: le mot juste).

Wikipedia should have as many normal accessibility features as possible, but let's remember that it isn't an English language course or specifically a learner's encyclopedia. Perhaps easily-confused abbreviations and jargon could be marked up, although I would guess that the nature of “St Mark's Cathedral” and “Portage Ave at Main St” are readily apparent without assistance. I don't think common English terms such as “etc.”, “e.g.”, “i.e.”, “ibid.”, etc. should be marked up, just as a normal printed publication doesn't put these into a glossary. It is the responsibility of the reader of any reference to be able to read the language, if necessary with the help of their own dictionary (or even some sort of free encyclopedia). —Michael Z. 2008-10-14 18:49 z

layout of the article germanium

I have received this comment about the article from the FAC director: layout issues abound, and they are too non-standard for me to sort. Please go to the WP:ACCESS talk page and inquire if this layout is accessible. Any opinions? Nergaal (talk) 02:02, 2 October 2008 (UTC)

Thanks Nergaal (but I'm not the FAC director, I'm the FAC delegate :-) I'll watchlist for the response. SandyGeorgia (Talk) 02:04, 2 October 2008 (UTC)

Which layout issues? Or have they been fixed by now? I don't notice any difference with my screen reader. Graham87 07:07, 2 October 2008 (UTC)

So the way all of the elements and images are laid out in the early sections processes fine through the screen reader? They're quite a jumble on my screen. Just checking, as I can't determine how they would flow through. SandyGeorgia (Talk) 07:19, 2 October 2008 (UTC)

Actually, not the top, the middle of the History section. SandyGeorgia (Talk) 07:20, 2 October 2008 (UTC)

Yes, the image layout before the table in the history section reads fine because screen readers read everything linearly. The only tghing needed for images to work with screen readers is a caption - it doesn't matter where their positioned. I'm not sure how a non-standard layout would look with screen magnifiers though. Graham87 08:33, 2 October 2008 (UTC)

The reviewers could get a first-cut simulation of a screen magnifier by using their browsers' "enlarge" facility - CTRL+ in FF and Opera. May not work in IE, as last time I looked IE failed the WCAG guideline that users should be able to enlarge even if the page specifies absolute font size (px). The other thing to watch out for is dependence on window width - complex layouts that work in maximised windows on wide (16:10) screens may not work in non-maximised windows or on the increasingly rare "standard" screens (4:3). -- Philcha (talk) 08:52, 2 October 2008 (UTC)

Equilibrium symbol

There is an ongoing accessibility problem in many chemistry articles about the double arrow used to represent a chemical equilibrium. We can either use TeX to render this as $\rightleftharpoons$ or Unicode to render this as ⇌. Inline TeX seems bad for users of screenreaders (and doesn't look wonderful on the page), but switching to Unicode will leave many readers with little boxes or question marks on their screen (at least the last time we tested it across different browsers). There's obviously a limit to how far we can avoid using this symbol in articles about chemistry, so I am interested in any comments from users at this page as to the relative merits of the current solutions. Physchim62 (talk) 12:20, 11 October 2008 (UTC)

The TeX version sounds bad with screen readers (they read the raw TeX), but at least it's possible to figure out what the symbol is and distinguish it from other symbols. With the unicode, unless the user has defined the symbol as "double arrow" or similar in their settings file, it won't be read at all. Therefore I slightly prefer the use of TeX in this case. Graham87 14:53, 11 October 2008 (UTC)

Would it help readers to provide downloadable or copyable character glossaries for IPA, math, etc? I suppose not the casual reader, but this could be generally helpful to anyone who has a persistent interest in whatever subject, in Wikipedia and elsewhere. —Michael Z. 2008-10-14 18:52 z

I think that's an excellent idea, not only for readers but for editors as well. Physchim62 (talk) 20:19, 14 October 2008 (UTC)

This sounds like an instance where having the title= attribute enabled would be of some help... ~ L'Aquatique[talk] 20:28, 14 October 2008 (UTC)

You can define alt and style attributes in math tags, e.g. A + B $\rightleftharpoons$ C - D — Dispenser 02:41, 20 October 2008 (UTC)

That reads fine with screen readers under the default math settings. At this point it doesn't matter to me whether we use TX with the alt tags or the image. Graham87 08:45, 20 October 2008 (UTC)

I think I prefer the image- at least in the browser I'm viewing right now (firefox on xp with low screen resolution) the TeX version is really blurry. I'll have to check it with other systems. ~ L'Aquatique[talk] 18:14, 22 October 2008 (UTC)

Arbitrary section break:Use image?

How about using a small image instead? For example:

2H₂ + O₂ equilibrium symbol 2H₂O

Wikicode: 2H<sub>2</sub> + O<sub>2</sub> [[Image:Rightleftharpoons.gif|16px|equilibrium symbol]] 2H<sub>2</sub>O

Note that the image has a title ("equilibrium symbol") which is included in the HTML code as the title for the link and as the alt text for the image:

[...]<a href="/wiki/Image:Rightleftharpoons.gif" class="image" title="equilibrium symbol"><img alt="equilibrium symbol" src="http://upload.wikimedia.org/wikipedia/commons/2/2d/Rightleftharpoons.gif" width="16" height="19" border="0" /></a>[...]

This has the advantage that we could produce an image which looks decent, unlike the TeX rendering and Unicode character in many fonts, and which can be displayed by any graphical browser, unlike the Unicode character. A disadvantage is that images in most browsers are not resizeable, but the same problem applies to the Tex version. Another problem is that the link pointing to the image information page is annoying (and I don't know how screen readers will deal with it). --Itub (talk) 15:10, 17 October 2008 (UTC)

Screen readers will display the image link on its own line. However I think the image is the best option because the image will display in all browsers and the alt text will be displayed by all screen readers. Graham87 15:26, 17 October 2008 (UTC)

If the image represents text, or a symbol, then the alt text should replace the symbol rather than describe it. Would it be more accurate to say “is in equilibrium with” or something which makes the equation read correctly? —Michael Z. 2008-10-17 15:41 z

I think you are right. Of course, if we go with the image idea, I'd suggest creating a template to make inputing the image easier, and to standardize the alt text. --Itub (talk) 15:51, 17 October 2008 (UTC)

Sounds good to me. Graham87 16:03, 17 October 2008 (UTC)

I would suggest using this code for the current template {{eqm}} in the medium term, once we've had a chance to test it at WP:CHEM. As an image it should be an SVG for example, and we would need to fit it to usual text sizes. Nothing major or impossible, IMHO. Physchim62 (talk) 16:20, 17 October 2008 (UTC)

There was a template called {{eqm}} that displayed the Unicode character, which was not used in many pages. I have boldly modified it to use the image instead. Let's test it here: A ⇌ B. We may need a better image, though. The current one sits too low in the line, with the bottom arrow showing as a descender. --Itub (talk) 16:22, 17 October 2008 (UTC)

That's easily fixable. I'm going on a plane trip today, I'll make an .svg version that sits higher inline while I'm sitting around. I'll have it uploaded tonight- ~ L'Aquatique[talk] 17:35, 17 October 2008 (UTC)

2SO₂ + O₂ 2SO₃. All right, not bad. I just need to shorten the horizontal lines a little bit and it should be good. ~ L'Aquatique[talk] 21:54, 17 October 2008 (UTC)

Okay, all uploaded. What do you guys think? ⇌ (you may need to purge your cache to see the latest version) ~ L'Aquatique[talk] 22:01, 17 October 2008 (UTC)

I think your harpoons are inverted? The "common" use is rightleftharpoons, not leftrightharpoons. --Rifleman 82 (talk) 05:33, 18 October 2008 (UTC)

Yes, it is backwards, and I think it could look better if the lines were a little bit closer. But in terms of position it looks good. --Itub (talk) 06:32, 18 October 2008 (UTC)

So... A + B ⇌ C + D. Well first I second/third Rifleman 82, the arrows need inverting in the plane of the page. On Safari (3.1.2) w/1280*800 (and a couple of lower resolutions) it looks fine. However looking at the previewed eqn I wrote out the bottom arrow could do with being brought up a little, as it still appears to hang below text line. I'll check it in Firefox too --EDIT--Firefox (2.0.0.13): Looks good, but bottom arrow still too low. --WhirlwindChemist (talk) 09:56, 18 October 2008 (UTC)

Haha, that's embarrassing, I'll flip it as soon as I get the chance. Here's the problem, though- as far as making it sit higher inline, that may be difficult since when you save a file as an .svg, you don't get to define the window size, it just automatically saves it as closely-cropped to the edges as possible. It may be better to simply make a .png- large enough to be relatively resizable... ~ L'Aquatique[talk] 16:32, 18 October 2008 (UTC)

Okie dokie, so what I've done is made a .png version, which is not a vector image and thus is not infinitely resizable, however it is 920 × 676 pixels which is big- I can't imagine a circumstance where we would need a chemical equilibrium symbol bigger than that! A + B C - D . Unfortunately, as you may have noticed... the lines are now too close together, and also I'm thinking a little too thick. Well, I guess I'm back to the photoshop drawing board... ~ L'Aquatique[talk] 00:52, 19 October 2008 (UTC)

Testing a new version: A B. I think the best will be to create a png in the exact resolution we want to use, because otherwise the rescaling can introduce some blurriness. --Itub (talk) 07:00, 19 October 2008 (UTC)

Arbitrary section break:SVG or PNG

Think we should stick with SVG for scalability? Wishlist: top heavy or bottom heavy eqm arrows to denote that equilibrium lies more to the right or left? --Rifleman 82 (talk) 08:50, 19 October 2008 (UTC)

No, I'm convinced by the arguments for PNG given above: an SVG image in this case is always going to sit too low on the line. Some of the blurriness would be removed if you made the dimensions of the PNG image an exact multiple of 16 (the pixel size we're testing at). I actually quite like Aquatique's last version with the lines slightly closer together. Physchim62 (talk) 10:25, 19 October 2008 (UTC)

It's not true that an SVG will always sit too low. An SVG image can be contained in a "page" that is larger than the visible part! --Itub (talk) 11:51, 19 October 2008 (UTC)

After purging your cache, tell me if you like this: A + B D - C. It's still a little low, but it doesn't show as a descender- at least for me. ~ L'Aquatique[talk] 17:41, 19 October 2008 (UTC)

Looks pretty good to me! --Itub (talk) 18:22, 19 October 2008 (UTC)

Me too! Let's just try scaling it:

16px + 0pt + A + B 16px − 0pt + A + B

15px + 0pt + A + B 15px − 0pt + A + B

14px + 0pt + A + B 14px − 0pt + A + B

The fifteen pixel version would be perfect, if it wasn't for the blurring. Physchim62 (talk) 18:44, 19 October 2008 (UTC)

It shouldn't be blurring like that, it's a vector image. That's really strange. ~ L'Aquatique[talk] 22:30, 19 October 2008 (UTC)

It's because, with SVG, you set a fixed width for the line: if that width doesn't translate into an integer number of pixels, you will get blurring. Let's try:

A + B C − D

You see that the PNG image is nice and sharp, because I touched it up by hand at the exact scale I wanted it (based on the Unicode character in Arial). Physchim62 (talk) 23:13, 19 October 2008 (UTC)

I still prefer using an .svg version because when font size is bigger, it will still be useful. Is there consensus that it 16px is too big? I thought it was just right. ~ L'Aquatique[talk] 23:22, 19 October 2008 (UTC)

The problem is that users won't be able to change the size of the image to fit the font size, so there's no advantage in having SVG in {{eqm}}. The SVG image is still useful to have around though! Physchim62 (talk) 23:37, 19 October 2008 (UTC)

[unindent]Well, I could write in a switch to the template that would allow you to define your own size. It would be like... {{eqm|size=50}} would render , but to not specify a size, i.e. just leave it {{eqm}} would render it at the default size, 16 px. ~ L'Aquatique[talk] 23:47, 19 October 2008 (UTC)

Thank's for the section breaks! We could easily put a switch in there, but I'm not sure it would ever be used. What we can't do is have the image appear bigger for people who read with larger default character sizes but normal size for the majority of users, not without a lot of fancy coding within MediaWiki. For any given wikicode, the HTML output is fixed. Physchim62 (talk) 23:55, 19 October 2008 (UTC)

Right, unfortunately I think we will have to do without that. There are enough positives to using an image that I think it outweighs these few negatives. Whether we use the png or svg doesn't really matter a whole lot to me.

As a side note, I left a notification a while back at WikiProject Chemistry that one of them should come over and okay this. I suppose silence implies content here. Once we agree on an image I guess next step is to start putting it into practice. A buddy of mine runs a bot that would be easily programmed to replace all instances of the unicode character and TeX markup with {{eqm}}. ~ L'Aquatique[talk] 00:05, 20 October 2008 (UTC)

Itub and Rifleman are both very active chemistry editors; I do a bit myself from time to time as well ;) Physchim62 (talk) 00:13, 20 October 2008 (UTC)

Perfect! ~ L'Aquatique[talk] 00:19, 20 October 2008 (UTC)

Help:Accessibility

Help:Accessibility is supposed to provide practical advice to readers about issues related to accessibility. So far, it says that you can adjust the size of the text in Firefox -- and that's it. Would someone like to expand it? WhatamIdoing (talk) 17:28, 14 October 2008 (UTC)

Script for screen readers like Fire Vox

Hi,

I'm interested in improving the accessibility of Wikipedia's articles, so I thought I'd say "hello" and ask for your help with a toy project. I've been experimenting with a script to strip the wikilinks out of Wikipedia articles so that the prose reads more smoothly in free screen readers such as Fire Vox. Would you help me to improve it? I think hearing articles read smoothly would help both the readers and writers of Wikipedia's articles.

You can try out the script by adding "importScript('User:Proteins/striparticlelinks.js');" to your monobook.js subpage under your user name, as you can see at my own user page. The script adds a tab at the top of your page entitled "strip links"; the tab is to the right of the "watch" tab. Once you put the script on your monobook.js page, you can invoke the script in any article by clicking that tab or by typing "alt-shift-s". An "alert" window will appear to let you know that the script worked and tell you how many links it removed from the article. It usually takes a few seconds for the script to complete its work, about 1 second per hundred links.

After installing Fire Vox, I've tried the script out on various Featured Articles, where it seems to have worked well. It's fun to hear articles such as Domestic sheep read aloud! But I'm new to accessibility concerns, and your suggestions for making the script more useful would be helpful. Perhaps the problem of reading Wikipedia articles smoothly has already been solved by more sophisticated screen readers than Fire Vox, but that would be helpful for me to know as well. No use re-inventing the wheel!

The script mainly strips out the wikilinks from the prose sections of the main article. It preserves the navigational links, the "See also" links, the edit links for each section, the reference links, the external links, and similar types of links. If you'd like to keep or eliminate other types of links , please let me know. I noticed that image captions get read twice; should I eliminate that? Thank you, Proteins (talk) 23:41, 14 October 2008 (UTC)

NonVisual Desktop Access is a much more complex free screen reader. Most blind people have gotten used to arrowing past links, because on most screen readers, they appear on their own line. But the script would be useful for beginners or those who don't link arrowing past ten million links. I don't have much time now, so I can't check it out properly yet. Graham87 01:45, 15 October 2008 (UTC)

Thanks for considering the script and the tip about NVDA, which does seem like a more powerful screen reader. I've downloaded it, but I'm also interested in Fire Vox, because it works across operating systems and seems easier for beginners to use. I'm hoping that the script will help editors improve their article writing by hearing what they've written.

I've made some improvements to the script since yesterday. I think I've fixed that bug 11555 you mentioned above, the one in which the section heading and its edit button occur in the wrong order. I also hacked a solution to the doubled reading of captions, and introduced image numbering. Please feel free to offer other suggestions when you find the time to try out the script. Thank you, Proteins (talk) 16:42, 15 October 2008 (UTC)

The script works very well, though is more reliable in Firefox. It didn't remove the links to Seattle Times when I tested it on this talk page. Another idea would be for it to remove distracting line breaks, like those at the Main Page. Graham87 15:39, 17 October 2008 (UTC)

Thanks! The script doesn't remove external links such as the Seattle Times links above, because I thought casual readers might want to follow those. If you try the script again on this talk page, you'll see that your and my internal links to Seattle Times in this section are removed, but the external links above are not. The script also keeps other potentially useful links that don't interrupt the reading too much, such as the inline citation links, the navigational links at the left, and the buttons for editing each section. I'd appreciate your suggestions and help in deciding which links to keep and which to eliminate.

I'm not sure which line breaks you're referring to on the Main Page, but I'll try to improve the script's performance there. The Main Page and other such portals seem qualitatively different from a typical article, don't they? Instead of having a linear flow, the Main Page is more like a six-ring circus, with major unrelated sections such as "In the news" and "Today's Featured Article". I'm not sure whether the HTML code provides enough clues about the portal's structure and I can imagine that such portals would be significantly harder to navigate. Proteins (talk) 09:47, 18 October 2008 (UTC)

Ah I didn't notice that the Seattle Times links above were external links. Keeping them in is fair enough then. What a useful internal link is depends on the reader - one user might need a definition of a particular word while another wouldn't. I think keeping links within lists would be useful, as links are an important part of lists. An example would be a list like Lists of French people. Removing date links and red links would be a good idea, because date links are distracting and red links are unlikely to be useful to beginners who just want to browse articles. Graham87 11:48, 18 October 2008 (UTC)

Thank you, Graham, I updated the script as you suggested. Now the script keeps list-links (except when those are references or footnotes) but eliminates redlinks throughout. Removing date links seem more difficult, so I haven't done that yet; but most of them were in the References section, where they're now deleted. I kept the ISBN links in the References, though, since they seemed equivalent to external links. Someday I'll figure out how to customize the script so that the user can specify which links they'd like to eliminate. I haven't had the chance to test the new script much, but it seems to work on a few articles such as List of French people, William Shakespeare, Sloop and a few others. Please let me know of any bugs you come across, and also fill me in on what you'd like for the Main Page. Thanks, Proteins (talk) 14:36, 18 October 2008 (UTC)

Checking out the Main Page more closely, it seems to be a special case. The line breaks I was talking about are in the lines "Welcome to Wikipedia,\ the free encyclopedia that anyone can edit.\ 2,587,508 articles in English". I've put backslashes where line breaks are read out with JAWS. There is also text that should be linked there, like the "overview" and "featured content" links, and the "more" link after today's featured article. I'm wondering how useful the strip links gadget would be on the Main Page, since the entire purpose of the page is as a springboard for going to articles in Wikipedia. Maybe it could strip out all links except those in bold or something. The Main Page actually reads quite well with a screen reader because of the headings. Graham87 15:06, 18 October 2008 (UTC)

I think I can keep links on the Main Page enclosed in bold type, but discard the others. The Main Page has special tag id's, often starting with "mp-", so it's easy to recognize. It may take me a while to find the right logic, though. I can definitely eliminate the two line breaks, you mention as well. Is there anything else you'd like for improving the Main Page? Personally, I'm having trouble navigating between the major sections of the Main Page using the keyboard; how do you do it? Proteins (talk) 15:29, 18 October 2008 (UTC)

OK, I think it works, but I'll have to eliminate the line breaks later. Enjoy! Proteins (talk) 15:40, 18 October 2008 (UTC)

It's discarding all the links in bold type instead of keeping them. To navigate the Main Page with JAWS, I use the "h" key to go to the next heading. Graham87 16:15, 18 October 2008 (UTC)

That's interesting: the script works fine in Fire Fox 3 on Vista (at least for me), but fails in Internet Explorer for the Main Page and Lists of French people. I'll have to do more research on how the pages are rendered in IE; perhaps a different Document Model is being used? Proteins (talk) 17:38, 18 October 2008 (UTC)

PS. Just to clarify, bold-faced links are given special preference only when they're on the Main Page. Bold-faced links on other pages are stripped as usual. Proteins (talk) 17:47, 18 October 2008 (UTC)

I tested the script on Fire Fox 3, Opera, Safari, and Google Chrome, and it worked correctly. The lone holdout was Internet Explorer 7. Most of the IE7 bugs were resolved by refreshing the cache memory; the browser was using an old version of my script instead of downloading the new version. However, something was still unacceptable about my code for updating images, as I observed at Bacteria and William Shakespeare. So I eliminated that code for now, until I can fix it, and the script ran fine. Proteins (talk) 03:09, 19 October 2008 (UTC)

Yes, it works well on the Main Page on IE7 now - it sounds much more pleasant for general reading. The only links I'd add now are the links labelled "Overview · Editing · Questions · Help", and so on, and the links after "recently featured" in the featured article and featured picture sections. Graham87, 05:00, 19 October 2008 (UTC)

Thanks, I think I might've corrected those things, although the linebreaks are still a problem. Please let me know if you find any other bugs or shortcomings of the script.

I noticed that Fire Vox skips the interwiki links on the Main Page that do not render in Roman letters, as though they weren't there. In one way, that makes sense, since Fire Vox would fail if you follow that link. On the other hand, it seems strange that the screen reader wouldn't note that Wikipedia has Arabic, Chinese and Russian versions. For fun, I'm drafting a little script to translate the interwiki links into English. Proteins (talk) 13:55, 19 October 2008 (UTC)

I would also like the links labelled "Contents · Categories · Featured content · A–Z index" on the Main Page to be kept as well. I'll let you know if I find any other problems. Graham87 14:30, 19 October 2008 (UTC)

Believe it or not, I did that before I wrote. Once again, the script works perfectly on every browser except IE7. Please try refreshing your cache, but I suspect that the problem is with IE itself. I'll have to look into it further. I may have to write separate scripts for people who'd like to use Internet Explorer, or include an internal check for IE. Proteins (talk) 15:13, 19 October 2008 (UTC)

I've refreshed my cache and it works fine here on IE7 now. Graham87 15:44, 19 October 2008 (UTC)

That's a relief! Perhaps my problem with IE7 is also cache-related, although I tried refreshing it once. In case you're interested, I finished a rough draft of User:Proteins/translateinterwikicodes.js. It translates the interwiki links in the lefthand column, but not yet those at the bottom of the Main Page. Thanks for your help in improving the scripts, Proteins (talk) 16:36, 19 October 2008 (UTC)

That's nifty - it would be useful for sighted people as well. It doesn't translate the links containing Template:Link FA in the article India properly under either IE 7 or Firefox 2. It would also have to deal with the redirects to that template as well. Graham87 02:13, 20 October 2008 (UTC)

Thanks, Graham, I think I've fixed the FA-link problem. I also suppressed the acknowledgment messages for translating each interwiki code, since I imagined that people wouldn't want to hear them. I posted the script on my user page, but I'll keep checking whether the script works well in different browsers and on different Wikimedia projects. Thanks again for your quick help! If you have any other wishes for scripts, whether for accessibility or otherwise, please let me know. I have a few ideas of my own as well... Proteins (talk) 13:12, 20 October 2008 (UTC)

The script sounds good now. Thanks for your work in creating and improving the scripts. I'll let you know if I think of any other ideas. Graham87 14:27, 20 October 2008 (UTC)

Hi, would you mind trying the striplinks script again on Internet Explorer? I was frustrated that the image code wasn't working there, so I've tried to fix it. It seems to work on my version of IE7, but that's only one datum. I wouldn't want to recommend the script if it were still broken, especially since IE is such a popular browser.

In the new version of this script, you'll probably hear the image caption repeated twice, but the first reading should be prefaced by the word "Image" and its number on the page. I also flagged some images that were invisible before, since they had no ALT text and no caption, such as those in navigation boxes; I hope that was the right thing to do.

As an additional feature, I was thinking of adding the total number of images to the ALT text, as in "Image 3 of 14:" I thought people might like knowing roughly where they are on the page. I could do the same with section numbering, for example, "Section 4 of 9: Translations of Shakespeare". Alternatively, I could give an estimate of how long it will take to read the remainder of the article, as in "You've read 33% of the article, with an estimated 45 minutes left to go" or give a quick link back up to the table of contents. In a really long Featured Article, people might want to skip sections that don't interest them. Lastly, I was thinking of making a hyperlinked List of Figures, a List of Tables and perhaps a List of Abbreviations analogous to and next to the Table of Contents, similar to what's found in academic textbooks and papers. Do any of those ideas seem helpful? I know that you can navigate easily using keystrokes in JAWS, so they might be superfluous. Proteins (talk) 21:08, 20 October 2008 (UTC)

Yes the image captions read fine in my test case, India under IE 7. I think something like "image 4 of 14" would be useful, as images are a good indication of a reader's progress through an article. I personally wouldn't need the lists near the table of contents - I can use "g" to move to another graphic, or "t" to move to another table. However they could be collapsable lists like "show a list of tables" or "show a list of headings". Another idea for the script would be either to move the edit links out of the heading titles, or remove them altogether, since people who use the script will be primarily interested in reading articles. I hear something like "Etymology edit" when I move between each heading: I'd prefer to just hear "Etymology". Graham87 03:43, 21 October 2008 (UTC)

Hi Graham, I made the changes you suggested, the "image 4 of 14" and removing the edit-section links. Your idea of making the Figure, etc. tables collapsible is excellent, too, but since such tables aren't urgently needed, I think I'll hold off on adding that feature until I finish some other scripts. I'll write to the few other editors that I've met, and see whether they have any suggestions for this script.

I'm developing another script User:Proteins/articlestructure.js to analyze the structure of articles, such as how much prose is devoted to each section. It's not really accessibility-related, but you might find it useful or it might give you ideas for other scripts that could help Wikipedians to write articles. I'm giving a seminar for some scientists in December with Tim Vickers and I'm beginning to develop tools that might help the newbie professors to "hit the ground running". Proteins (talk) 16:47, 21 October 2008 (UTC)

Visualizing x-y plots

Hi Graham, I made a subsection, since that section was getting long, don't you think? Besides, I have a new question.

What's customary for making two-dimensional x-y plots accessible to visually impaired readers? I was thinking you could represent such a plot acoustically by varying frequency (y) against time (x). For example, a straight line could be represented by a slow chirp, gradually increasing frequency with time. Some nice benefits of this approach is that you can represent multiple signals at once, and if they get close, you can tell how close they are from their beat frequencies. Other sonic alternatives — such as varying volume (y) against time (x), or volume (y) against frequency (x) — seemed less ideal, since people generally lose hearing as they age and might mishear a volume-based curve, especially if frequency represented the x-axis. I'm interested in the problem because I'd like to make the numerical results of future scripts accessible to as many editors as possible. It seems like an old problem, one that smart people have surely considered and found solutions for; I'd hate to re-invent the wheel or go against custom. If you could fill me in, whenever you get a chance, that'd be great. Thanks, Proteins (talk) 20:21, 21 October 2008 (UTC)

I studied advanced mathematics in high school so I had to deal with this problem. I used GTCalc, a talking graphic calculator made in Australia, to visualise graphics. It had a feature that allowed one to visualise a graph. It could only handle one graph at a time. You would type in the domain of values you wanted to hear (x and y minima and maxima), and it would make a sonic representation of the graph by varying the frequency based on the y-axis only. There was also a feature to trace the graph. The Audio Graphing Calculator converts graphs into audio in a similar way, but it plays white noise when the y-axis is below 0. GTCalc might still be available through Vision Australia, and I still have a copy of it. A thirty-day evaluation version of the Audio Graphic Calculator is also available. Seeing with Sound seems to be an even better program that can, among other things, convert graphs to audio, but the site has over-aggressive anti-spam protection and for some reason I'm banned from it. Graham87 04:52, 22 October 2008 (UTC)

The Seeing with Sound program, or vOICe as it is properly known, is very nifty indeed. It converts images into sound using the stereo position to indicate the position you are hearing, the pitch to indicate the nddepth, and the volume to indicate brightness. It comes with an in-built audio graphing calculator, which comes with many more options than the commercial alternatives. It can also convert images from the web into sound. The spam protection on the vOICe site is not over-aggressive: there are invisible links which, if clicked on, ban your IP address from the site, and I happened to activate one of those links with JAWS. Graham87 14:51, 22 October 2008 (UTC)

While I remember, the link that explains the graphing calculator part of vOICe is here, which also contains links to other good sites about mathematics for the blind. Graham87 16:38, 22 October 2008 (UTC)

That's great that you know so much about the subject! I looked over the three plotting programs you mentioned in your first reply, and I'm also impressed most by Seeing with Sound. Their links to other sites, such as the tactile force feedback, were fascinating as well. It's going to take a while for me to become familiar with all these various tools. But perhaps the take-home message for me is that this is a solved problem already?

I imagine that if you wrote to the Seeing with Sound people, they'd re-instate your browsing privileges. It sounds like an innocent mistake. If you wanted me to intercede for you, I'd be happy to do that; being a professor has at least a few advantages.

As I wrote on my talk page, I'm working on your list-merger problem. It's fixed except when you have multiply-indented text, as often happens on Talk pages; I'm still thinking about how to solve that problem.

The way that Seeing with Sound uses stereo hearing reminded me of my old friend Gill Pratt when we were at MIT together twenty years ago. His Masters thesis in electrical engineering was a headset system that used stereo sound to tell blind people which way was North; we had a lot of fun trying it out for him. Nice memories, Proteins (talk) 17:41, 22 October 2008 (UTC)

I got unbanned last night, which is how I was able to try out the program. I should have been more clear about that in my previous messages. Gill's thesis reminds me of the C2 Talking Compass. Graham87 07:10, 23 October 2008 (UTC)

Working script for outdenting discussions

Just a heads-up that I got the initial bugs out of the outdenting script, User:Proteins/outdent.js. Would you test it out and look for any remaining bugs? That'd be great. I made the access key "o", so if you're using Firefox, ALT-SHIFT-O should outdent everything that should be outdented. I don't think that conflicts with another access key, but let me know if it does. Note that the older script User:Proteins/unindent.js should NOT be used any more, because of its bad bugs. Thanks, Proteins (talk) 23:25, 24 October 2008 (UTC)

The access key "O" is the key for "Log in / create account", so there is a conflict in this case, but it doesn't matter because if a person is accidentally logged out and tries to use the indentation script, logging in is exactly what they'll want to do. However the access key doesn't work on IE 7 but works on Firefox. It works fine on this long boring discussion which goes to indent level 14. However for discussions like Wikipedia:Articles for deletion/Steve Pariso, it should remove the bullet points and/or the line breaks so it sounds much better with JAWS. Graham87 03:48, 25 October 2008 (UTC)

The problem is that HTML tags such as <ul> start a new line automatically, as you can see at the bottom of this sandbox. The only solution is to put the "(Indent n)" text within the list item, which I'll try to do now... Proteins (talk) 18:34, 27 October 2008 (UTC)

...OK, the script seems to be working; I tested it on my sandbox tests, the Steve Pariso AfD, the jbmurray RfA, and the talk page of FAC. But it might have some stealthy bugs; please let me know if you uncover anything amiss. Thanks, Proteins (talk) 20:21, 27 October 2008 (UTC)

It still makes JAWS say "list of 1 items" and so on before each indent in the AFD in both Firefox and IE (and I've refreshed Monobook.js on both browsers). Looking at the source code more carefully, it seems the easiest thing to do would be to put the bullet point before any indents. But that sounds like what you said above, so I'm beginning to wonder whether I'm having a caching problem. Graham87 02:05, 28 October 2008 (UTC)

You're right, that's what the new version script tries to do. The script keeps the bullet point, which marks the list of one item. Some editors seem to use that bullet point to indicate that a new editor has begun speaking; although it's usually redundant, I was loath to delete that style-mark. Instead, the new version of the script changes where it places the "(Indent x)" text and removes the linebreak that had preceded the bullet point; now, it places the indent text just inside the list item, so that it comes after the bullet point with no line break.

I tested the script on the Steve Pariso AfD on Firefox 3, Google Chrome, Opera and Safari, and it seemed to work at least on my screen. The two bullet-pointed lines, namely Ten Pound Hammer's comment "A who what?" and your reply, should be bullet-pointed and unindented like all the other comments on that page. If that's not so, perhaps try refreshing your cache with Cntrl-F5, which I've found works on both IE and Firefox 3. Also, please make sure that you're using User:Proteins/outdent.js and not the obsolete version User:Proteins/unindent.js.

Removing the list and bullet point altogether is possible in principle but would be more difficult. I'm afraid it would be difficult to write a script that would deal appropriately with all the pathologies that users would throw at it.

One thing I haven't done is add a third-pass loop to delete the now-empty discursive lists that were used to make the indentations. They're invisible to me, that is, they aren't rendered by the browser; but a sufficiently clever screen reader might note their presence in the Document Model tree — or perhaps that should be a too-clever-by-half screen reader. I'm thinking of deleting them, but it's always a little dangerous to be deleting elements in the document, so I'm working on the rest of the script first. Proteins (talk) 11:21, 28 October 2008 (UTC)

Aha, it's the empty discursive lists that I'm hearing with JAWS. I hear them on both Firefox and IE. They sound slightly better under the outdent script than they do when the page is loaded normally. There are many weird and wonderful indenting styles out there, from bullet points to ordinary spaces, so I understand your reluctance to deal with some of the more exotic ones. Graham87 13:23, 28 October 2008 (UTC)

Ok, that's helpful to know! I think I've fixed the script. The deletion loop is slightly more aggressive than it should be, but it shouldn't be a problem for most articles. I even know how to fix that problem, but today's my birthday and my wife and I are about to make a nice dinner, so I'll get to it tomorrow. I tested the script on the sample articles mentioned above, and the new version seems to work fine. Enjoy! but let me know any other problems... Proteins (talk) 00:31, 29 October 2008 (UTC)

Hmmm, I'm still getting discursive lists in the above-mentioned AFD debate, in both Firefox and IE 7. I've refreshed Monobook.js in both browsers and it's still not working properly. Also, when I pressed enter on the "outdent" link to activate the script, the alert didn't come up in IE as it should. I'm not sure what's going on. Oh BTW happy birthday. :-) Graham87 05:19, 29 October 2008 (UTC)

It ain't over 'til it's over; code isn't code until it's working code. I hadn't tested the script on Internet Explorer, which seems to be much stricter about valid JavaScript; the browser seems to throw an error if you take the property of a null DOM object. To make the script work, I added exhaustive checks on the NULL status of every object, which is good programming discipline. I always do that in more basic languages, but I'd mistakenly thought that JavaScript was smart enough to handle that automatically.

I tested the script on the Steve Pariso AfD in five browsers: Firefox 3, IE 7, Opera, Safari and Google Chrome. In all the browsers except Opera, I can check the DOM tree after running the outdent script; the DL elements have been deleted. I added diagnostic messages to confirm that as well. I tried the sandbox tests, the jbmurray RfA, and the talk page of FAC on IE7, Chrome and Firefox 3, and they seemed to work as well. Try it again? Thanks, Proteins (talk) 16:19, 29 October 2008 (UTC)

As I've just figured out, the discursive lists JAWS is reading aren't definition lists at all. They are unordered lists. Here is what JAWS says when I run the outdent script on Wikipedia:Articles for deletion/Steve Pariso under both FireFox and IE, with caches refreshed:

list of 1 items •Delete There is no assertation of notability. In fact, the whole things reads like a CV. -- Malcolmxl5 08:20, 31 July 2007 (UTC) list end

list of 1 items •(Indent 1) A who what? Ten Pound Hammer • (Broken clamshells •Otter chirps •Review?) 12:13, 31 July 2007 (UTC) list end

list of 1 items •(Indent 2) CV=curriculum vitae, known in North American English as a Résumé. Graham 87 12:33, 31 July 2007 (UTC) list end

list of 5 items <The rest of the AfD ...

The same thing occurs on your sandbox. I know I've had caching problems, but I've cleared out my temporary files area to make sure that no old versions are lurking in my computer.

How do I get at the DOM tree, so I can hear what JAWS is using to present the page? Thanks, Graham87 00:54, 30 October 2008 (UTC)

First the good news. I've begun writing a tutorial on scripts, User:Proteins/Writing_scripts_for_Wikipedia and the first section I've written is the one you asked for, how to see the DOM tree on different browsers.

The bad news is that what you're hearing is exactly what you should be hearing, according to my initial design. Here's how my script works. In the first pass, the script identifies the DD elements in discursive lists (also called definition lists) that are not underneath or adjacent to a DT element; it keeps track of the indentation level and labels and colors everything according to that indent level. In the second pass, it places everything inside those DD element into new DIV elements, hoists those DIV elements out of their discursive lists, placing them before them. In the third pass, it uncreates the now-empty discursive lists. Therefore, if the editor used an unordered list of one item to make a little bullet point, then you'll hear that because it got packaged into its DIV element along with everything else.

There are several solutions. The simplest is to add to the script a fourth-pass loop over the new DIV elements (which I've labeled for just such a purpose), and then eliminate whatever elements we wish to eliminate, such as unordered lists, without destroying the essential content within them. That will remove the bullet point that the user added for style, but we could replace it with a nearly equivalent marker. Alternatively, I could try to write some logic into the script to see whether such buried unordered lists could be integrated with a surrounding unordered list. Lastly, we could try to educate people that they don't need that little bullet point to indicate that a new person is talking, but that seems more difficult. Proteins (talk) 13:12, 30 October 2008 (UTC)

I was thinking that the little unordered lists could become nested, so basically turning the wiki-markup ":*" or "*:" into "**", and add more nesting for each additional colon. I'll check out the IE toolbar tomorrow morning my time. Graham87 14:40, 30 October 2008 (UTC)

I'm surprised that "**" is read differently than what's produced by my script. Doesn't JAWS also say something like "list of one item" to indicate the sublist of the "**" element? Since I don't have JAWS, I'm flying blind, if you'll forgive the well-meant joke. ;)

I'm game to keep working on the script if you are. It seems as though we're close to a good solution, if we can only communicate to each other what we're striving for. I'd thought that the definition lists themselves were the problem, that JAWS would read a triply-indented bullet-pointed reply "I agree." preceded by a linespace as something like

definition list of one item • definition list of one item • definition list of one item • unordered list of one item • I agree. • end of unordered list • end of definition list • end of definition list • end of definition list

My initial goal was to convert this into the much shorter text

unordered list of one item • (Indent 3) I agree. • end of unordered list

which the script does now. If the unordered list could be eliminated, either by more sophisticated programming or by educating editors not to add that redundant element, the minimal version would result

(Indent 3) I agree.

That's my understanding of our goal. Did I misunderstand something? Perhaps JAWS is smart enough not to read out all those "definition list of one items" when text is indented? If you could clarify the goal for me, that would help in writing a more useful script. JavaScript confers nearly perfect control over the elements of a webpage, so nearly any desired modification of lists and indentations is possible with sufficiently sophisticated coding.

I made a a new sandbox to experiment with lists and indentations. We might find it helpful in defining the desired behavior of the script. Proteins (talk) 16:44, 30 October 2008 (UTC)

Yes, JAWS says something like "list of 1 items nesting level 1" when coming in to a new unordered list. It does not make a distinction between ordered and unordered lists. You can actually download a free demo of JAWS to play with these things at the Freedom Scientific website.

The thing is, when reading an AFD vote, I ideally want a continuous unordered

list. I want to be able to move to each vote by pressing "I" to move to the next list item. When hearing "list of x items" with JAWS, I also want an accurate count of the number of votes, not including the indented discussions. That's why I was thinking of using nested lists, because I thought inserting a line break always ended a list. However that doesn't seem to be the case, as proven by my sandbox at User:Graham87/sandbox9, which represents the ideal way I would like to hear discussions using both indents and bullet points. Both my tests sound exactly the same with JAWS: the first one uses lists created with "*" while the second one uses HTML elements to create the list. Graham87 01:26, 31 October 2008 (UTC)

OK, I think I get it now. I downloaded the demo version of JAWS and learned enough to figure out some things that I hadn't realized. First, I had mistakenly believed that JAWS was reading the indentations aloud as definition lists, as I wrote above, but that's not true. For example, the indented sentences in this sandbox all read as though they were unindented, whereas I has imagined that JAWS was reading them like

definition list of one item • This sentence is indented once. • end of definition list

So I was solving a problem that didn't need to be solved. On the other hand, you might appreciate knowing that a text is indented, to flag when a new comment is being made, so perhaps it wasn't a total loss. Speaking for myself, I like being able to see the comments in different colors, and not wasting all that screen space with indenting. As an aside, is there a way in screen readers to flag text so that it's read in different voices? That might be the equivalent of seeing text in different colors.

The two examples you give in Sandbox9 are helpful, too, although you might be amused to know that the DOM tree representations of both are identical, except for the extra BR tag at the end of the second example.

Am I correct in assuming that you're OK with eliminating all indented unordered lists? That would leave you with unindented unordered lists, which are the ones you care about, right? I'll make sure to merge them so that you can count the votes. As another alternative, I could write you a simpler script that would just count and read off the list items that begin Keep, Delete or some other bold text. I have to go home in an hour or so to greet the children for Halloween, but maybe I'll try to write the latter script before then. Proteins (talk) 19:48, 31 October 2008 (UTC)

Yes, elimination of indented unordered lists is what I want. Sometimes JAWS does read the indents as "definition list of 1 item nesting level 1, nesting level 2 ..." which can get very annoying. I don't know of a way to predict when it will try to read out indents in this way. The Speech and Sounds Manager in JAWS lets you customise a different voice or a particular sound for headings, indents, colours, fonts, or anything you care to customise. However I don't like voice changes so I don't use that feature. In fact my JAWS configuration is quite eccentric, and has been fairly strange ever since I started using the program in 1999. Graham87 06:02, 1 November 2008 (UTC)

AfD summarizing script, possible FAC application

Hi Graham, I wrote a new script, User:Proteins/summarizeAfD.js, that summarizes the AfD !vote counts and who voted what way. The script ignores indented comments. You might find it useful in your work, at least as a quick overview since I understand that AfD's are not supposed to be votes. The script access key is "a", I hope that's OK. Let me know if you like the new script and whether I can improve it. I might make something similar for FAC's, although I know they're not supposed to be votes, either. I'll get back to the outdenting script on Monday. Proteins (talk) 04:15, 1 November 2008 (UTC)

I like it. I've tried it on this trainwreck of an MFD (for deletion of Wikipedia namespace and user pages, which have the same format as AfD's), and the script seems to evaluate it as I remember it. However, when it finds a signature that it doesn't recognise, I'd like it to tell me what that signature is so I don't have to go waist-deep into the AfD to find it. If it doesn't do it already, it should count user talk pages the same as user pages in sigs, because some people sign with a link to their user talk page only. Graham87 06:02, 1 November 2008 (UTC)

Also, on access keys, alt-A gets me to the favorites menu with Internet Explorer, but it doesn't really matter right now because none of your access keys work in Internet Explorer 7. Graham87 06:40, 1 November 2008 (UTC)

Hey Graham, I'm glad you like the script. I do determine the User talk page, if one is provided, and use it as a substitute for the User name if the latter is missing. In the new version, I added two new categories of votes (refactor and transwiki); the script also gives the list item in full when an error is encountered. Some of the errors on the Esperanza MfD seem to have been valid !votes, so I'll have to go back and find out why my script didn't flag them as such; but you can tell what they are from the error messages. Proteins (talk) 15:25, 1 November 2008 (UTC)

640x480

How essential is support for ~640x480 window size (or basically anything smaller then 800x600) for accessibility reasons? This issue has come up in Wikipedia talk:2008 main page redesign proposal Nil Einne (talk) 08:37, 17 October 2008 (UTC)

• None that I know of. The following news sites for instance: CNN, MSNBC, ABC, and CBS have all standardized upon 1024 × 768 as the minimum assumed monitor resolution below which scrolling is required. That resolution is pretty much the Web standard now. Greg L (talk) 00:03, 2 November 2008 (UTC)

Operation Epsom

This article has three infoboxes, templates in the lead: I'm unsure if this placement complies. SandyGeorgia (Talk) 03:16, 24 October 2008 (UTC)

From my POV, it's OK ... the tables are easy to skip and I can get to the main text in three keystrokes with JAWS. Graham87 16:28, 24 October 2008 (UTC)

Thank you, Graham87. If you have a moment, can you also comment on Acid dissociation constant? I have several concerns there, hard to summarize. SandyGeorgia (Talk) 17:00, 25 October 2008 (UTC)

There are probably too many navboxes, and I would prefer it if they could be hidden. The equilibrium symbols should be generated with Template:Eqm. Graham87 08:43, 26 October 2008 (UTC)

Fixed your redlink there, hope ya don't mind. ~ L'Aquatique[talk] 01:34, 2 November 2008 (UTC)

Nope, not at all. :-) Graham87 05:04, 2 November 2008 (UTC)

Timeline of MacBook Family Models

{{Timeline of MacBook Family Models}} seems to have multiple accesibility issues... Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:55, 25 October 2008 (UTC)

The inaccessibility of timelines was discussed at Wikipedia talk:Accessibility/Archive 1#Timelines?, among other places. They're still as inaccessible as ever, and will remain so until someone rewrites the EasyTimeline extension for accessibility. Graham87 08:58, 26 October 2008 (UTC)

Animated image in essay

There's quite strident opposition to the removal of a moving image at Wikipedia_talk:Drop_the_stick_and_back_slowly_away_from_the_horse_carcass#Moving_image; and I've been reverted twice, despite pointing out the accessibility implications and citing WCAG. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:44, 25 October 2008 (UTC)

At which I've just been told that "Wikipedia does not consider [WCAG] to be relevant"! Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:05, 1 November 2008 (UTC)

I think you're confusing some issues:

• Image:Bomba atomowa.gif is of poor quality, jerky and does flicker a bit - annoying cycles indefinitely although one cycle is enough to make the point. However the flickering is nowhere near as rapid or intense as the level at which UK TV companies issue epilepsy alerts before programmes.
• Some animations are very useful ways to illustrate processes, and the good ones are about as smooth as movies or TV. There's a good example at Four-stroke engine.
• In the discussion at Wikipedia_talk:Drop_the_stick_and_back_slowly_away_from_the_horse_carcass#Moving_image you cite a WCAG guideline on avoiding flickering animations until browsers provide an option to block or freeze animations - although this guideline apparently does not define threshold levels for animations that are likely to cause trouble. In the meantime most Windows browsers freeze animations if the user hits the ESC key and most offer an option to block images altogether; I expect non-Windows browsers offer similar facilites. I'm sure users prone to epilepsy already know and use these facilities, otherwise they'd have a seizure at every page that shows a jiggling banner ad.
• At another point in that discussion someone cited an RNIB page that allegedly defines the rate and intensity of flickering likely to provoke an epileptic seizure. It might be sensible to define a policy or procedure that allows removal of images that are in that range. However reviews of such images would have to be conducted in a totally objective manner based on current medical criteria supported by WP:RS, and not become witch-hunts against the use of animations. It seems to me that you have seriously damaged your case by appearing set on just such a witch-hunt. -- Philcha (talk) 14:51, 1 November 2008 (UTC)

It is you who appears to be confusing issues. Perhaps because you missed that I quoted "The animation should also come to a rest after 3 to 5 cycles" from the RNIB page you cite. You appear to believe, mistakenly, that epilepsy concerns are the only accessibility issues with animated images. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:16, 1 November 2008 (UTC)

• Concern over the welfare of epileptics is a red herring. Sufferers of epilepsy can take care of themselves. There are CSS style sheets to load into browsers to block GIF animations and users who are extraordinarily sensitive to animations can—and without a doubt do—avail themselves of these things. I wonder if there has been one sufferer of epilepsy who has ever come to Wikipedia to complain about any of our animations. Just pardon me all over the place for thinking this, but whereas Andy Mabbett may have the best intentions of epileptics at heart, I think his personal dislike of one particular animation has biased him enough that he is mentally seized upon that issue to help lend credibility and nobility to his cause. But his arguments simply aren’t supported by the facts. I don’t think Philcha has confused any issues; he is merely stating the facts and drawing logical conclusions. Andy’s arguments just don’t make sense. Sorry. Greg L (talk) 22:38, 1 November 2008 (UTC)

Your personal, fallacious beliefs are not relevant to this matter; and your statement of them here is a further breach of WP:AGF. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:01, 1 November 2008 (UTC)

I don’t question your right to express your beliefs here so I would appreciate it if you afforded me the same courtesy and didn’t presume to tell how I may think and where I may express my views. And, Earth calling Pigsonthewing: your personal beliefs are not the only ones on this pale blue dot that are meritorious.

Notwithstanding your attempt to hide behind the apron strings of WP:AGF (and a pronounced tendency to cite Wikipedia essays, guidelines, articles, and policies in an “if it’s blue, it must be true” fashion), as I said stated above, I believe you have the best of intentions here. I’m not questioning your good faith. I simply think you have an extreme personal bias on this issue. As a result of this apparent bias, I find no validity of your arguments, which are fallacious, specious and illogical. Given that no one else is agreeing with you on this matter, that would normally be a clue for most people that you just *might* be wrong. Yet, somehow, that possibility doesn’t seem to have dawned on you.

Judging from the tone and tenor of your above response—and your responses to every single other editor who has dared to disagree with you—I believe you A) are absolutely convinced there can be no chance that you are wrong on this, and B) are taking this way too personally, and C) every disagreement is an excuse to pull any stunt to win (witness your baseless ANI against me.) Philcha and I simply disagree with your conclusions and logic. Lighten up and please stop acting like a censor who has the unilateral power to delete animations from Wikipedia. Greg L (talk) 23:39, 1 November 2008 (UTC)

Clarification: Your personal, fallacious beliefs about what you imagine are my mtoivations are not relevant to this matter... Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:32, 2 November 2008 (UTC)

Perhaps. But that might explain why the factual basis for your arguments crumbles under scrutiny. Greg L (talk) 00:42, 2 November 2008 (UTC)

No such thing has happened, because you keep refuting straw-men, not my arguments. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 01:10, 2 November 2008 (UTC)

When there is nothing left to beat, consider that there are other options.

[ec]All right, all right. Please, you guys, let's try to get along here. Since compromise is my word of the day, let's try to find a compromise here.

I think all involved would agree that putting aside the merits and drawbacks of moving images and looking simply at the image in question... it's not a great image. It's grainy, the animation is poor, and it looks to be low res. Instead of repeatedly edit warring to remove it, why don't just we replace it? There's a whole bunch of static images in Commons:Category:Nuclear tests that would do just as well. ~ L'Aquatique[talk] 01:26, 2 November 2008 (UTC)

• Splendid. Would that make you, Andy, happy and end all this? Greg L (talk) 01:29, 2 November 2008 (UTC)

[unindent] How about this one? ~ L'Aquatique[talk] 01:51, 2 November 2008 (UTC)

• As I mentioned on WT:drop the stick, the original animation was one of wildly exaggerated violence juxtaposed against the relatively benign reality of edit conflict. “Error”: the basis of all humor. It was a humorous sight gag that was obviously added to help relieve tension and defuse conflict, which often occurs in a collaborative writing environment. I think your still image conveys the same effect. Greg L (talk) 02:42, 2 November 2008 (UTC)

Thanks, L'Aquatique; that's fine by me. I think that image should also replace the disputed image, on "Wikipedia-space" pages, and people who have the latter in their user space should be asked to consider dropping it. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:20, 2 November 2008 (UTC)

Order of Battles

An editor has added several divisional/Corps symbols to the following order of battle article: Operation Market Garden order of battle. Personally I think it looks ok and if it seemed ok with the wider community I was thinking of doing it myself to some order of battles I have worked on.

The way orders of battle are laid out they are rather text heavy and can be hard sometimes to see where the next division etc start.

On the same subject, I completed the following Operation Epsom order of battle and have found that it is hard to distinguish who the commanding officer of division/Corps etc is. Due to this I have made their rank and names in bold – from a MOS point of view is this acceptable?

Also any hints etc on how to make the article more accessible to the average reader?

Sorry for all the questions and thanks for the help.--EnigmaMcmxc (talk) 17:05, 27 October 2008 (UTC)

These multi-level nested lists tend to be busy and sloppy looking, and hard to read, but I don't know if there's a better alternative. They definitely could use some graphic help, but just enough to give the reader some milestones, because too much will increase the clutter.

In Market Garden, I would consider just having the insignia for top-level armies and corps, but not for every single bullet point.

For Operation Epsom, try unit names in bold and commanders in regular—this may still provide differentiation, but may seem more natural. Abbreviating the commanders' ranks may reduce clutter a bit.

Looks good so far. —Michael Z. 2008-10-27 18:27 z

I have adjusted the British half of the article for now, I will use that as a sandbox so to speak before I edit the German half.

The AG/Army/Corps/Division and brigade titles are now all in bold, the commanding officers have been returned to regular text and any additional information has been moved to a new footnote section at the bottom of the article.

After these few changes the list looks so much more clearer (I honestly don’t know why I didn’t think of some of these changes until now and others when you mentioned them). I personally don’t think that there is a need for graphics now, do you?

However the commanding officers, especially those without links, do become somewhat blurred within the text. As a test I did change the commanding officers so they to were bold however it didn’t seem to help much.

Any further suggestions on what could be done to make the article more accessible to the general reader? Or any comments on the changes made thus far?--EnigmaMcmxc (talk) 13:00, 28 October 2008 (UTC)

WCAG

It's clear from recent comments (see above) that some editors do not believe that the W3C's Web Content Accessibility Guidelines are not "relevant" to Wikipedia. I consider that to be a harmful position, but accept that there is no clear written policy (leastwise, none that I can find) mandating or recommending that those industry-standard guidelines should be followed, or to which level. Practical experience shows that it is sometimes necessary to work around certain poorly-worded or obsoleted parts, hence the (draft) WCAG 2.0 and WCAG Samurai; but I believe that there should be a clear policy that, in the absence of consensus to exempt specific cases, WCAG guidelines should be followed to a stated level; or at least that we should, as a body, strive towards doing so.

Does anyone have comments, and would people support such a move, and be willing to assist me in taking it forward? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 20:36, 2 November 2008 (UTC)