Wikipedia talk:Manual of Style/Accessibility

Accessibility of preceded by/followed by

On many Wikipedia pages, temporal sequences are generated as HTML tables with "preceded by" and "succeeded by" cells in each row. For instance, [Jimmy Carter] is preceded by person x and followed by person y for several different public offices. These are stated in the following sequence:

1) Preceded by 2) Name of office 3) Followed by

e.g.

1) Preceded by Lester Maddox 2) Governor of Georgia 1971 – 1975 3) Succeeded by George Busbee

While these tables are to be read in sequence, and therefore probably don't constitute a navigation issue for not having column headings, the sequence when read aloud is likely odd

"Preceded by Lester Maddox Governor of Georgia 1971 – 1975 Succeeded by George Busbee"

might make more sense as

"Governor of Georgia 1971 – 1975 Preceded by Lester Maddox Succeeded by George Busbee"

which would be coded in the following sequence:

1) Governor of Georgia 1971 – 1975 2) Preceded by Lester Maddox 3) Succeeded by George Busbee

This would be a significant change involving thousands of pages so I'm putting it out for discussion.

Thisisnotatest (talk) 06:43, 12 October 2009 (UTC)

As a screen reader user, I've probably just gotten used to it and I've never thought of the order as unusual. But you're right, it would make more sense to have the office name and dates read first. I kinda like the current configuration as a mini-timeline though ... the earliest event is spoken first and the most recent event (i.e. who became the Governer of Georgia after 1975), is spoken last. Graham87 10:10, 12 October 2009 (UTC)

Section headings and JAWS

In the Links section there is a caveat:

Some screen readers, such as earlier versions of JAWS, will stop reading the heading title when they encounter a link, and if the link is the first part of the heading title, they will only read the link text.

There is currently a discussion at Template talk:PRODWarning#Linked article name in section headings that raises the question of whether or not this is still an issue, i.e., is it unique to legacy versions? I would rather not download and install this program just to test it, and then uninstall it.

If someone can document that it is not a problem for the current/recent versions, then maybe it should be redacted. Otherwise, the dilemma should probably be discussed in another forum to reach WP:CONSENSUS.

Happy Editing! — 141.156.161.245 (talk · contribs) _{15:36, 23 October 2009 (UTC)}

Not quite sure what screenreader Graham is on, perhaps he could comment... –xeno^talk 15:39, 23 October 2009 (UTC)

I'm on JAWS 8 now, which is the earliest version that most people would use these days. It's not a problem now ... IIRC it ceased to be an issue around JAWS 7.1. Graham87 16:12, 23 October 2009 (UTC)

Kewl! In that case, does anyone have a problem with me adding a parenthetical "but not the current version" as a modifier? — 141.156.161.245 (talk) 17:03, 23 October 2009 (UTC)

Probably best to just say "such as versions of JAWS prior to 7.1" –xeno^talk 17:05, 23 October 2009 (UTC)

 Done – Works for me! — 141.156.161.245 (talk) 17:41, 23 October 2009 (UTC)

I dunno, from Graham says it's not a problem of practical importance nowadays, so I was bold and removed the prohibition. Please feel free to revert if I overstepped. Eubulides (talk) 21:40, 23 October 2009 (UTC)

I don't have a problem with the removal of that text. Graham87 16:22, 24 October 2009 (UTC)

Icons without supporting text - input required

A discussion about the use of icons without any supporting text is taking place at WT:FOOTY#National Team World Cup Tables - participants in this project may have useful input to give which would be very welcome there. Best, Knepflerle (talk) 22:15, 27 October 2009 (UTC)

links in section headers

I've just readded the point about not placing links in heading titles. It was removed on October 23, 2009, apparently with no discussion, and based on the revision summary is based on the misconception that placing links is no longer a problem. Keep in mind that section titles also act as anchors, which makes adding wikitext markup to them very problematic. The actual paragraph in Wikipedia:Accessibility#Links should probably be rewritten for clarity, though. The current content about screen readers isn't very relevant.
— V = I * R (talk to Ω) 14:44, 14 December 2009 (UTC)

To expand on that: anchors use HTML ids which must follow rules. The only allowable characters are alphabetic, numeric and hyphens, underscores, colons and periods. Thus the brackets used in wikilinks will render invalid HTML. ---— Gadget850 (Ed) ^talk 15:57, 14 December 2009 (UTC)

The developers could easily fix that with another escaping filter. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 07:00, 18 January 2010 (UTC)

The discussion is just two sections above! Happy‑melon 18:40, 14 December 2009 (UTC)

*smacks forehead* Thanks for pointing that out. I skimmed over the talk page, but nothing jumped out at me as being about adding links to section headers. For what it's worth I do tend to agree that the discussion about JAWS is not particularly relevant today, especially since the developers have apparently updated their software... still, the point about not using wikitext in headers is for everyone's benefit. Using links or templates in section headers makes it difficult to create internal links (wiki-links), let alone actual HTML anchors. If that isn't a good enough reason not to, the fact that there are a good number of (some very) old browsers, and some intentionally simple browsers, used to access Wikipedia ought to be a good reason to keep the point. Besides, the stricture against wikitext in headings is stated in many other Wikipedia documents as well, pointing to here for an explaination (for example: WP:LAYOUT and WP:HEAD mention it, and link here).
— V = I * R (talk to Ω) 19:42, 14 December 2009 (UTC)

There, I rewrote the point to (hopefully) better represent the problems. Take a look at the edit, and feel free to copy edit it or change it.
— V = I * R (talk to Ω) 19:50, 14 December 2009 (UTC)

The brackets used in links never appear in anchors for section titles. See the HTML source of a deletion debate, like this one, for proof. The relevant code is below the line with "edit section" in it. Graham87 01:22, 15 December 2009 (UTC)

Piped links don't show up in anchors either, per my sandbox. Graham87 01:27, 15 December 2009 (UTC)

However, the text of a template will show up as an anchor if the template is used as a section header, per my sandbox. That could make it difficult to link to the section. Graham87 01:35, 15 December 2009 (UTC)

Well... I've never really probed the limits of what is and what isn't usable in section headers. I just know that it tends to create problems, especially with wlinks, so I simply avoid doing it. It is kind of a neat feature to use, in some places, but... If I were the only one to feel the way that I do, that it's simply best to avoid markup in section headers, then I wouldn't say anything about it. However, it's my sense that most tend to agree. It would be helpful to have the actual technical limitations written down, but I think that there is a style and usability issue mixed in with this as well, so simply clarifying what is or is not technically acceptable is not the end of the issue.
— V = I * R (talk to Ω) 13:09, 15 December 2009 (UTC)

I'm not a great fan of wiki-markup in headings either, mostly because it can make a mess of edit summaries. The disadvantages of it usually outweigh the advantages. Graham87 15:03, 15 December 2009 (UTC)

Anchors in section headers

While we're on the topic of funky section headers, is there any problem with this?

== Thumbnails {{Anchor|thumb}} ==

Template:Anchor says this won't work, but it was in WP:PIC for ages, and now that I've replaced it with:

== Thumbnails ==

{{Anchor|thumb}}

the result isn't as nice, as WP:PIC#thumb links to the first word in the Thumbnail section, whereas I want it to link to the word Thumbnail itself. For an example of anchors in section headers, and how it works for you, please click on #Anchor to this section header (the version I prefer) and on #Anchor to this section body (the version I don't like as much). Eubulides (talk) 18:25, 15 December 2009 (UTC)

PS. Hmm, for the previous example to work in my browser, it appears that there needs to be a lot of text in the window, or for there to be a very small window. You might need to follow the link to WP:PIC#thumb (a page with a lot of text) to actually see the behavior that I don't like as much.

The only real technical issue with this sort of thing, that I'm aware of, is that the template wiki-text makes it nearly impossible to wiki-link to the section header "normally" (ie.: without using the anchor itself). For a good example of misbehavior along these lines, try linking to an item on a noticeboard, like something on WP:RFPP for example. More generally speaking though, including the template with the section header simply makes it more difficult for everyone.
— V = I * R (talk to Ω) 19:15, 15 December 2009 (UTC)

This very page/section is a good demo of the problem, now. Go to the history page here, and click the arrow next to the "Anchors in section headers " item in one of the entries. It should bring you straight to this section (or as close as possible, since this is on the bottom of the page), but instead it jsut brings you to the top of the page, because the internal anchor is broken. I'm going to correct the section title in this edit summary though, and it should bring you correctly to the section.
— V = I * R (talk to Ω) 19:19, 15 December 2009 (UTC)

You gotta read the {{Anchor}} template documentation. If you have ==Foo== and want additional links to it, you can't just do this ==Foo{{Anchors|Bar|Baz}}==, or yes, it will break. You have to do this: ==Foo{{Anchors|Foo|Bar|Baz}}==. The heading will link perfectly fine as [[#Foo]] (and [[#Bar]], etc.) as long as the original name is also one of the anchors. It is still messy, though, and there has to be a better way. I propose one below, that would require MediaWiki developer attention. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 07:26, 18 January 2010 (UTC)

Proposed technical solution

What we really need is a new syntax of some kind in MediaWiki, something like:

==[[Head:Foo|Bar|Baz...]]==

such that any

==Foo==

can thereby by given additional anchor id's.

And since I think every [[Something:...]] has a corresponding [[:Something:...]] variant that does something special, usually prevention of some expected effect (suppression of inlining an image, suppression of putting a page in a category, etc.), in this case it could perhaps be that [[:Head:Foo]] would create a heading that looked like the results of ==Foo== but did not have an anchor and did not show up in the table of contents. This would be a good way to handle the pseudo heading used for introducing template documentation on a template page, and I can think of several other uses, where it would be sematically valuable to have actual <h#> heading code in the HTML, but not ToC it. Under this scenario, I think that [[:Head:Foo|Bar|Baz]] should produce the same results as [[:Head:Foo]] (i.e., parameters after the first ignored) but [[:File:Filename|100px|right|thumb|Description.]] doesn't seem to ignore its later parameters and the sky doesn't fall down. I have no idea how long it would take to convince the developers to do something like this. I haven't been in the WP Bugzilla for a long time.

The rationale for doing any of this at all, of course, is that it is important that be able to reasonably link to sections, often under shorter or previous names for them. Anchors above a heading become part of the content of the preceding section, and may disappear or move with that section, which is a fatal problem for that usage. Anchors below a heading will, on all but very short pages, link to text with no heading in most browsers, because the heading will be scrolled up above the viewport. I imagine that it's even worse for screen readers, with text being read without any indication at all that this is actually a new section and the heading for it was missed by one line. This stuff is an accessibility, usabilit and maintainability problem of rather high severity, and one that's been vexing me for over four years.

— SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 07:21, 18 January 2010 (UTC)

Major change at alt text guideline

I was shocked by some of what I read in there, so I overhauled significant parts. I don't know how reverty the regulars there are, but I figured it could use more accessibility eyes over there, given the nature of WP:ALT. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 06:57, 18 January 2010 (UTC)

I have followed up at Wikipedia talk:Alternative text for images #Transcribing text. Eubulides (talk) 07:59, 18 January 2010 (UTC)

MOS:COLLAPSE outdated advice?

Someone recently suggested they might try to have {{footballbox collapsible}} deleted claiming that it's in violation of MOS:COLLAPSE. This has lead to some interesting discussion on the template talk page. Intrigued by the claims being made by this editor based on the advice found here, I set out to investigate exactly how "inaccessible" it is. I discovered the following...

Using 2009 Seattle Sounders FC season as my test case which makes extensive use of this template:

• I installed the LYNX browser (which does text only) on my machine and browsed to the page. I discovered that the full, expanded content of the boxscores (not just the first line) is visible.
• I normally use Internet Explorer when browsing Wikipedia, so I tried to "Print Preview..." the page and discovered that it expands all of the boxscores.
• I also have the Google Chrome browser installed. It does not have a "Print Preview..." feature, but when I actually printed the page, I discovered that it too expands the boxscores in it's print output.

Also, in the archives of WT:ACCESS I discovered this comment which explains the behavior I observed above and seems to address most of the accessibility concerns related to collapsible content.

I've also discovered this comment in a discussion about show/hide collapsible content in another article. While the circumstances of that conversation were very different (show/hide was being used in image descriptions to hide spoiler content), the point about the JAWS 5.1 screen reader having no problems accessing collapsible content is pertinant.

I would postulate that the verbage in MOS:COLLAPSE as it is currently written is overly cautious and possibly outdated. I admit I have not completed an extensive test pass (yet), but I have seen enough so far to come to at least a preliminary conclusion that this section in the MOS needs to be updated/rewritten. Given that this is the first time I've ever commented on MOS, I'm unsure how to proceed. Should I propose new text or wait for others to follow up on my request? Thanks! --SkotyWA^T|_C 07:27, 18 January 2010 (UTC)

It's worth noting that the default print CSS now uncollapses tables like this by default, anyway. Chris Cunningham (not at work) - talk 12:32, 18 January 2010 (UTC)

On a slight tangent, the last sentence of this guideline suggests that we should only ever collapse a navbox where all the content is already linked to in the article body. Am I misunderstanding this? WFCforLife (talk) 02:14, 24 January 2010 (UTC)

Collapsed sections aren't an accessibility issue AFAIK. I've never had any problems with scrolling referenced lists, but I can understand how they could cause problems for people using screen magnifiers. Graham87 05:41, 24 January 2010 (UTC)

Can you elaborate on the problems collapisble content could cause with screen magnifires? I played around the one included in Windows7, "Magnifier", and it seemed to work just fine in all 3 modes (full screen, lens, and docked) with my test article. I could expand and collapse the content without incident. --SkotyWA^T|_C 17:59, 24 January 2010 (UTC)

I said that scrolling lists could cause problems with magnifiers, not collapsible content. I only use a screen reader, and I'm totally blind, so I'm not sure myself. People with severe vision impairments use commercial magnifiers such as ZoomText. Graham87 04:22, 25 January 2010 (UTC)

Ah, I'm sorry. I misunderstood your comment when I read it the first time. That makes sense now. Thanks for the clarification and I appreciate your input on this especially as someone who can speak from experience. Thank you! --SkotyWA^T|_C 08:09, 25 January 2010 (UTC)

Collapsibles cause a problem on printable versions and on Wiki mirrors; I don't know why it ended up at ACCESS, I thought it was at MOS. SandyGeorgia (Talk) 01:20, 26 January 2010 (UTC)

Can you provide specific examples of the problems you mention? As I noted above, I experimented with two browsers to see if there were any printing problems and discovered that the collapsible content simply expands when printing. What specific problems are you aware of with printing? I would like to reproduce them myself if possible to understand them further. Likewise, can you point me at any Wiki mirrors that can illustrate problems with collapsible conent? Thanks! --SkotyWA^T|_C 01:35, 26 January 2010 (UTC)

Aren't mirrors designed to use our content in order to profit from ads? I don't quite see why either ACCESS or the MOS should accomodate them. WFCforLife (talk) 22:46, 29 January 2010 (UTC)

Wikipedia content should be as easy to copy or reuse as possible, IMO; there are probably many offline mirrors for personal use, so they're not just for advertising. Mirrors and forks don't have much to do with accessibility, however. Graham87 05:34, 30 January 2010 (UTC)

I'm very interested in the answer to these questions, as another editor and I have just spent a month greatly expanding Grandchildren of Victoria and Albert, which uses collapsed genealogy boxes ("ahnentafeln") within the main article for Victoria, Albert and the spouses of each of their children to allow an interested reader to reconstruct ancestry back for several generations (for example Kaiser Wilhelm II's direct descent from King George III) without making the whole page tedious and unmanageable. There are also collapsed portraits of several royal families. If this really causes a major problem for visually-impaired readers, we need to go back and think out how best to present the information. ¶ I don't want to print out reams of paper, but I'd be glad to do a quick visual test the next time I open my Windows Vista versions of Mozilla Firefox 3.5.7, Apple Safari 4, and Netscape Navigator 9.0.0.6 —— Shakescene (talk) 03:12, 29 January 2010 (UTC)

More data of what works and what doesn't would be very helpful. As I said above, I tried this out in both popular browsers and in a text-only browser and everything worked fine. If you have more data from different browsers or screen readers, that would be great. This will help drive an informed decision on what should be in the MOS rather than basing it on unsubstantiated "facts". --SkotyWA^T_C 17:40, 29 January 2010 (UTC)

On the last version (9) of the now-discontinued Netscape Navigator (available from OldVersion.com), which rode on the then-current version of Mozilla Firefox, the collapsed portraits in Grandchildren of Victoria and Albert open out very nicely and the ahnentafeln (family trees, which use their own standardized family of collapsible Wikipedia templates) don't appear in any form, even by title. Although I could chance some utterly-uninformed speculative guesses, I really have no notion why the two collapses should render differently in Print Preview on Windows Vista (for an HP Deskjet D1341 printer). I could do a test print, but I don't really want to unless really necessary. If anyone wants sample screenshots of my print previews and has some very easy way of transmitting and receiving them (e.g. e-mailing JPEGs to a personal account indirectly linked on a user page), let me know. —— Shakescene (talk) 02:17, 30 January 2010 (UTC)

When was netscape discontinued? WFCforLife (talk) 08:15, 30 January 2010 (UTC)

Netscape still keeps a shadowy existence as part of the AOL universe (http://netscape.aol.com/ ) but Netscape Navigator, the web browser, was discontinued in March 2008 (http://browser.netscape.com/history ). See also The Netscape Archive at http://browser.netscape.com/ . To add some of the features (like the mini-browser sidebar that's my reason for keeping a copy of Netscape) to a current browser, see http://browser.netscape.com/addons —— Shakescene (talk) 18:36, 30 January 2010 (UTC)

The Print Preview of Grandchildren of Victoria and Albert in Mozilla Firefox 3.6 (Jan. 2010) behaves in essentially the same way as that of Netscape Navigator 9 on my Windows Vista computer (for an HP DeskJet D1341 printer): that is, the collapsed pictures open out and display, while there is no indication (other than a blank line) for the ahnentafeln (family trees) referred to above. —— Shakescene (talk) 06:15, 31 January 2010 (UTC)

Could you do the same test on the boxes in Watford F.C. season 2009-10? I've tested both articles, and only the Victoria and Albert one caused problems (behaving exactly as you said). I suspect the issue may be with the template syntax, rather than the collapse function specifically. A test worth trying would be to remove the collapse function from one of the family trees (temporarily), to see if the print preview works. WFCforLife (talk) 09:06, 31 January 2010 (UTC)

I've finally opened Firefox 3.6 and the Print Preview opens out those games in the middle of Watford's 2009-10 season. However, the Print Preview doesn't show the collapsible navigation boxes at the bottom of the page, for either Watford or for West Ham United Football Club, which I had initially confused with Watford. Perhaps the navbox template won't print while other templates will. —— Shakescene (talk) 04:14, 5 February 2010 (UTC)

To be fair, we're both overachieving English clubs whose fans don't realise just how close they have come financial ruin.

Let alone another W FC that's over-achieved both on the field and on the edge of insolvency, Walsall Football Club —— Shakescene (talk) 04:58, 5 February 2010 (UTC)

If navboxes aren't accessible, that's a serious issue. I routinely omit "see also" sections, on the basis that the navbox covers it. If it doesn't, there needs to be quite a bit policy change about their use (wider than this talk page). Print preview isn't a problem, but are there other devices that would need to access links that might not be able to? WFCforLife (talk) 04:21, 5 February 2010 (UTC)

Print preview isn't a good test in this case. There is no reason to print a navbox since it would be useless on paper, so I think they were deliberately disabled in printing. I think a better test would be to find out if the end navboxes work on Lynx. (Notice that I said "work", not "look good"). If they work, then they're is no accessibility problem with article navboxes. If they don't work, which is quite unlikely, then Template:Navbox needs to be modified. Graham87 07:08, 6 February 2010 (UTC)

I've been bold and made changes that reflect the spirit of WP:ACCESS, while trying to get across my complaint with it. Hopefully it will stick, but at least if it's contested we should get an explanation of why it is the way it is. WFCforLife (talk) 08:15, 30 January 2010 (UTC)

I too have been bold and made the following minor adjustments: [1] and [2]. Hopefully they'll either stick or be reverted and kickstart further discussion here. Thanks all for the feedback so far. --SkotyWA^T_C 20:49, 30 January 2010 (UTC)

Proposal

At this point I think there has been enough evidence presented to conclude that there are no accessibility concerns with this type of content. Therefore, I propose that this section be removed completely from WP:ACCESS. The originial contributor of the section, Happy-melon, has already ported most of the pertinant information over to the main MOS article. I further propose that the MOS:COLLAPSE and MOS:SCROLL quicklinks should be moved to the "Scrolling lists" section of the main MOS article and the title of that section should be updated to be "Scrolling and collapsible content". On his talk page, Happy-melon has already indicated his approval of this as the outcome of this discussion (he pretty much suggested it). Does anyone have concerns with this plan of action? --SkotyWA^T_C 17:50, 3 February 2010 (UTC)

It's logical to move those quicklinks to the MOS, although it would be ideal to come up with alternative ones for WP:ACCESS. What I would like to do is move the "or to consolidate information already covered in the prose." segment into the MoS, on the basis that this is what infoboxes already do (or should do). WFCforLife (talk) 01:13, 4 February 2010 (UTC)

No objections here. Graham87 01:34, 4 February 2010 (UTC)

Okay, I made the updates and followed WFCforLife's suggestion of porting that segment over. I also tried to clean up the text a bit. Let me know if any of the additional changes are concerning. Here are the diffs: [3] and [4]. Thanks to everyone who participated in this discussion. --SkotyWA^T_C 03:52, 5 February 2010 (UTC)

Repetitive stress injuries

Scrolling lists and collapsible boxes cause problems for people with repetitive stress injuries in their arms/wrists, which affect about 1% of the population in most developed countries. Mouse work is often very difficult for people with carpal tunnel and such. Could we please go back to recommending against this, specifically for the purpose of providing maximum reasonable accessibility to people with one of the most common physical disabilities? WhatamIdoing (talk) 22:01, 3 May 2010 (UTC)

I'm not sure I understand your proposal. If you suggest to bluntly remove collapsible boxes and scrolling lists, I'm afraid it's a bad approach to improve accessibility. We must not reduce the quality of the content in order to be accessible. If you are proposing something else, could you provide more details? Yours, Dodoïste (talk) 23:10, 3 May 2010 (UTC)

Under what circumstances does hiding text (in the regular articles, not navboxes) actually improve accessibility or reduce the quality of content? (As far as I know, {{hide}} does not change any content.)

I have explained how they interfere with access: A person who cannot scroll to the end of a list because using a mouse causes him (or her) physical pain is prevented from reading the hidden text. Perhaps you could explain how hiding text supposedly makes it more visible? WhatamIdoing (talk) 00:10, 4 May 2010 (UTC)

Do you suppose it would be useful to modify the WP:keyboard shortcuts to allow a single key to expand/contract all hidden text on the page? (or to set a user style to do so) What confuses me though about your comment is that editors usually hide text to spare themselves from scrolling over it, under far less arduous circumstances. p.s. I wonder if anyone makes a large laptop-style touch pad for people to operate by foot... Mike Serfas (talk) 18:39, 8 May 2010 (UTC)

How do you decide that you don't want to read text whose contents you know nothing about, because someone hid the contents?

For example: Click here, and tell me how any reader with severe RSI could possibly decide (before clicking on anything, and without assuming magical knowledge) whether or not the pain involved in clicking on the [Show] button under "Personality traits" is likely to be worth it.

Rather than a shortcut or user style to expand text, I'd suggest that this approach NOT be used to hide text. I think it reasonable to assume that readers will generally prefer more information by default. WhatamIdoing (talk) 20:43, 8 May 2010 (UTC)

Resolution

I was wondering if someone can clarify the resolution guideline for me, in relation to this list? Although it's not ideal, I believe that at 800x600 the current format is acceptable; three vertical images is not unreasonable given the relative length of the table. What I'm less sure about is whether that would remain the case were I to continue adding images. Thanks in advance, WFCforLife (talk) 22:16, 19 January 2010 (UTC)

Font size and readability in tables

Accolades in film articles and filmographies in actors' and filmmakers' articles are usually displayed in tables. In these tables, I often see the font-size: 90% attribute. I personally do not mind this attribute, but I am concerned that this minimal adjustment affects accessibility in terms of readability. Such tables are major parts of the article body, and it seems detrimental to display their contents in a font size smaller than the font size used in the rest of the article body. I searched this talk page's archives for previous discussions about table readability but the closest discussion I found was font size in "References" sections, which I personally find secondary to the article body. Does anyone know if discussion has taken place elsewhere about this and if this is a real accessibility issue to investigate? Erik (talk) 16:00, 26 January 2010 (UTC)

Spaces with ref tags

There's a dispute at WT:MOS this week that, in part, discusses whether we should require editors to place <ref> tags immediately adjacent to the associated text, without an intervening (non-breaking) space. WP:REFPUNC has taken a hands-off, no-edit-warring approach for years, although certainly a "most common" style exists, if you look through pages.

The systems under consideration look like this:

• Common
• Spaced 

Coded as:

• Common<ref>One</ref>
• Spaced&nbsp;<ref>Two</ref>

I think the outcome will either be to make the common style be mandatory (most likely) or the absence of a standard. As far as anyone here knows, does it make any difference in terms of accessibility? I assumed that it doesn't... but I'd rather not be relying on my assumptions. WhatamIdoing (talk) 18:52, 13 February 2010 (UTC)

It doesn't make a bit of difference in terms of accessibility, since all modern screen readers recognise the non-breaking space character. I've gone ahead and put nowiki tags around your examples. Graham87 03:37, 14 February 2010 (UTC)

I've removed the nowiki tags, because the appearance might matter to someone with less severe visual impairments, or with text processing problems like dyslexia. The difference might be unimportant to users of screen readers, and important to some other user. WhatamIdoing (talk) 04:04, 14 February 2010 (UTC)

I've boldly added a "Coded as:" section to your initial comment, as I didn't realize that the example was using an   until I looked at the diff. Revert/fix at will :) -- Quiddity (talk) 08:09, 14 February 2010 (UTC)

The discussion headings in question, seem to be here: WT:MOS#Contradiction regarding inline citations and WT:MOS#Needed help regarding WP:Logical quotation (each has multiple subheadings). [for instant access, and future reference] -- Quiddity (talk) 08:09, 14 February 2010 (UTC)

Potentially Culturally offensive American bias.

I notice that this article, like many, is advocating American supremacy over British English. The language was written in good faith, but good faith, however innocent, can deeply offend. I would carry out the necessary edit myself to neutralise this in a reasonable manner for it to be politically correct, but edits to the page are only allowed on consensus.--Kudpung (talk) 08:53, 20 February 2010 (UTC)

Which article(s)?. You should post to WT:MOS, as that deals to when UK / USA English. --Philcha (talk) 10:37, 20 February 2010 (UTC)

I don't understand the problem, as no examples are given it appears that Kudpung is offended by the use of American English instead British English and the only solution is to change everything to British English. Jeepday (talk) 13:14, 20 February 2010 (UTC)

Furthermore, see the section on varieties of English in the Manual of Style. Graham87 15:00, 20 February 2010 (UTC)

I don't need to look it it up in the MoS, I know the sectiojn almost by heart - the differences, without any personal bias or offense whatsoever, between AE and BE happen to be a 30-year professional specialisation. I would willing rewrite the short sentence for cultural neutrality and political correctness, but unfortunately this just happens to be one of those pages where even a typo can't be touched without a consensus.--Kudpung (talk) 16:03, 20 February 2010 (UTC)

Precisely which sentence are you talking about? Graham87 16:08, 20 February 2010 (UTC)

I am guessing that this complaint was supposed to be about the guidance concerning the overcolored / overcoloured template. The previous language could be misread as if the American spelling was preferred. I changed it, but of course the language is more clumsy now for little gain. [5] Hans Adler 11:33, 25 March 2010 (UTC)

There's no need for this page to provide a list of redirects; tags don't have to match the variety of English used in the article. WhatamIdoing (talk) 14:25, 25 March 2010 (UTC)

Besides, Wikipedia, which is hosted in Florida, has at least some ties to the United States.--Damian Yerrick (talk | stalk) 12:46, 10 July 2010 (UTC)

on tool-tips

I have listed Template:Tooltip for discussion. I figured I should mention it on this talk page because I based my rationale partly upon the accessibility guideline which says “Don't use techniques that require physical action to provide information, such as tooltips or any other "hover" text”. Please direct all responses to WP:TFD#Template:Tooltip, thanks. ―AoV² 06:46, 1 March 2010 (UTC)

Note: discussion at Wikipedia:Templates for discussion/Log/2010 February 26#Template:Tooltip has closed. ―AoV² 22:54, 8 March 2010 (UTC)

Harm done by transparent areas in images

Please see Wikipedia:Village pump (policy)#Policy of using Transparent image backgrounds. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:07, 24 March 2010 (UTC)

Requirement for alt attributes removed from Featured article candidate criteria

...despite my best efforts. Please see Proposal to remove alt text requirement. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:20, 24 March 2010 (UTC)

Removed from Featured article candidate criteria because WP:ALT have serious issues, of which the most visible one is when to use long or short alt text. WP:ALT can't be "enforced" by WP:WIAFA until all issues in WP:ALT have been resolved. --Philcha (talk) 08:37, 25 March 2010 (UTC)

Perhaps; but the very idea of granting FA status to an article with images which require, but do not have, alt text on images with meaningful/ textual content - and thus whose content is unavailable to some of our users - is absurd. And offensive. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:59, 25 March 2010 (UTC)

General style guidelines

Feel free to revert the removal of the general style guidelines category if you like, but please see WT:MOS#General style guidelines. - Dank (push to talk) 18:10, 7 April 2010 (UTC)

Infobox headings

Discussion at MoS - Infobox headings has an accessibility component. Your views would be welcome. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 10:13, 8 April 2010 (UTC)

MoS naming style

There is currently an ongoing |discussion about the future of this and others MoS naming style. Please consider the issues raise in the discussion and vote if you wish GnevinAWB (talk) 20:48, 25 April 2010 (UTC)

Species distribution maps

Please note discussion of colours for species distribution maps, where input from people with accessibility expertise is needed. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:45, 28 April 2010 (UTC)

 Done Dodoïste (talk) 10:27, 28 April 2010 (UTC)

Repetitive Title Injuries?

Over at Manual of Style talk page for infoboxes, we're having a debate over titles for infoboxes, and we would like some input from the accessibility contingent. Here's what I know:

• Having titles/captions attached to tables, figures, and other such "boxes" is a generally regarded as good for accessibility.
• Having the exact same name repeated in the article title, the first sentence of the article, the infobox title, and the photo caption seems like it might be repetitive and confusing if a device like a screen reader is used. Consider the Larry Bird article.

Which factor weighs more than the other? Are there other accessibility factors at play? Your input is welcomed over there. --Rsl12 (talk) 21:47, 7 May 2010 (UTC)

Hidden rows in tables

I recently added a method to Help:sorting, but I'm worried about something said there:

The first unsortable row can also be a hidden row, with each element marked with <span style="display:none">...</span>, to ensure that each column has the desired sort mode. However, this technique creates tables that have accessibility issues, as it causes problems with screen readers and text browsers.

Alternatively, the entire row can be marked as hidden with |-style="display:none", which is probably better.

I am not certain whether this caution applies only to rows made unsortable using class="sortbottom", or whether the text above means that the |-style="display:none" is less troublesome in terms of accessibility. Also, this warning is not mentioned in your project page under Tables. Would someone familiar with screen readers clear up these issues here and/or at Help:sorting? Thanks. Mike Serfas (talk) 18:17, 8 May 2010 (UTC)

The text '|-style="display:none"' causes problems for screen readers with no CSS support at all (which are very uncommon these days), and text browsers such as Lynx. In these browsing environments, the marked text is displayed rather than hidden. I don't know if it's much of a problem these days. Graham87 02:44, 9 May 2010 (UTC)

I don't understand why you need to hide a row. Could you provide an example of use for this technique? Maybe we can find better solution than hiding the row. Dodoïste (talk) 11:38, 9 May 2010 (UTC)

It's a trick to make tables sort properly. For example, if the column you'd like to sort by happens to have a non-numeric entry at the top of the data (such as a footnote or "—"), even after other sort operations, it will be sorted alphabetically, unless something is done to prevent this. Some of the methods involve a hidden row containing the proper data types, and all involve some variety of CSS markup. See Help:Sorting for details. Mike Serfas (talk) 03:02, 10 May 2010 (UTC)

The table sort function used on Wikipedia is very lacking (and especially unsuitable for complex tables). We should ask developers to improve it rather than making fragile workarounds. Dodoïste (talk) 23:41, 3 August 2010 (UTC)

I'd second that. I look for improvements because that's just the sort of editor I am, but the sort function sorely needs a revamp. --WFC-- 23:47, 3 August 2010 (UTC)

Captions for line art

A user of WP:AIR has been removing the "thumb" attribute from line art images in articles, pointing to a general "disclaimer" on the WP:AIR MoS which says that users are not "obliged" to follow the image use guidelines. Comments are welcome at WT:AIR#Captions for line art. Chris Cunningham (not at work) - talk 08:52, 18 May 2010 (UTC)

Timeline

Is it possible to specify alternative text for the images generated by <timeline>...</timeline>? Thanks! Plastikspork _―Œ^(talk) 08:41, 5 June 2010 (UTC)

Apparently not. The output generated by the EasyTimeline extension isn't very accessible for screen reader users. Graham87 11:43, 5 June 2010 (UTC)

Yes, I just saw something at WP:ALT#timelines about it. I am working on a solution for {{Infobox political party/seats}}, and one possibility might be to overlay the text? Another would be to replace it with a variant of {{Horizontal timeline}}. This case should be fairly easy since the text is the content and the graphic is mostly decoration, although provide a cue to the reader if there is a majority. Thanks! Plastikspork _―Œ^(talk) 16:05, 5 June 2010 (UTC)

I think overlaying the text would be the best idea. The problem with Template:Horizontal timeline is that it's impossible to tell the time periods of the listed events with a screen reader. Graham87 16:18, 5 June 2010 (UTC)

Sounds good. The other option would be to replace it with a modified version of {{timeline row}}, shown above. It would need some modifications to move the text to a better place, and reduce the size a bit. However a simple text overlay is probably the best here. Plastikspork _―Œ^(talk) 16:29, 5 June 2010 (UTC)

Discussion regarding this guideline

There is currently a discussion at WP:Village pump (policy)#The use of colors in filmographies which involves WP:ACCESS#Styles and markup options. Please join in that discussion if you so wish.  Chickenmonkey  23:42, 6 June 2010 (UTC)

Loophole as Resolution under Article structure

Someone noted that "Resolution" is a subsection under the section "Article structure" allowing for a loophole, where no other pages need to be readable for special-needs viewers. Is that 3rd-level header a mistake, or should resolution not matter when reading other pages: project pages, essays, talk-pages, or disambiguation pages (they're not considered articles, yet). Perhaps there was a compromise and someone concluded: "Resolution is fine if applied to articles, but don't make it affect the formatting of WP policy or guideline pages?" There has been quite a battle to ensure disambiguation pages are not considered to be article pages (so they won't contain any extensive text, and don't need to follow any rules about articles). -Wikid77 (talk) 06:57, 7 June 2010 (UTC)

I think it was an oversight. IMO all pages on Wikipedia should be usable on 800x600 resolutions. I can't think of many cases where this rule is a problem, except perhaps large data tables for WikiProjects or statistics tables. Graham87 08:04, 7 June 2010 (UTC)

• Thanks for clarifying that. I hoped it was approved for all pages, so using Text-size "Larger" (or Firefox "Zoom-in") would still render balanced pages. I have convinced editors to re-typeset guideline WP:User_pages (for WP:ACCESS), so it now looks balanced at 800x600 (or even narrower). There was some strong resistance, but I am finding resistance to WP:ACCESS everywhere because the Firefox browser seems to keep boxes wide, while only MS Internet Explorer 6/7/8 tends to squeeze other text or Table-of-Contents boxes into 2-words-per-line at 800x600. Eventually, it was understood to affect IE's narrow boxes. -Wikid77 (talk) 15:37, 7 June 2010 (UTC)

Expecting extreme resistance

I have found widespread resistance, all across WP, to changing pages to conform with WP:ACCESS. The typical response is: "It looks fine to me, prove it's a problem, prove it can be fixed, prove those people matter, I don't think WP:ACCESS applies in this case". The resistance is not just in articles, or guideline formatting, but also in template formats, and everywhere, so I typically say it's been a guideline since before May 2009. Let me also note, that I have found similar widespread resistance to almost any changes in WP: this place is not a collegial dream of friendly collaboration. There have been numerous stubborn people, for more than 5 years. Anyway, has anyone written an essay, "Introduction to accessibility issues" which could be used to alleviate the initial resistance to caring about WP:ACCESS? Would an essay even help to reduce the severe opposition? I have learned that seniority does not sway many people: a person with 25,000 detailed edits gets little more attention than someone with 200 edits. So, I wonder about other ways to get people to become more cooperative about WP:ACCESS. -Wikid77 (talk) 15:37, 7 June 2010 (UTC)

Can you give us an example or two of changes you'd like to make, that are being opposed? As a general rule, if you're really getting opposition everywhere, then you might have misunderstood the community's position. WhatamIdoing (talk) 16:29, 7 June 2010 (UTC)

I feel that prohibition of color-on-color text is ludicrous. It's, as Twain had said about censorship, "like telling a grown man he can't have a steak because a baby can't chew it." Tom Danson (talk) 21:11, 9 June 2010 (UTC)

In mid-Mar 2010 1 editor rushed through a version of WP:ACCESS in about a week, with no attempt at WP:CONSENSUS. This version was based on the idea of "physical descriptions". In May 2010 WP:FAC dropped WP:ACCESS from WP:WIAFA. To get acceptance, a new version of WP:ACCESS must:

• show evidence of thinking serious about the problems, e.g. what about non-visual difficulties.
• get WP:CONSENSUS. That takes time and multiple editors. If needed, have a RFC. --Philcha (talk) 05:38, 10 June 2010 (UTC)

WIAFA has not dropped ACCESS; I'm not sure what you're referring to, but FAs must conform to MOS, and ACCESS is part of MOS. SandyGeorgia (Talk) 23:50, 20 June 2010 (UTC)

That's a surprise, as sound clips would also be needed. --Philcha (talk) 00:57, 21 June 2010 (UTC)

I support the general prohibition of color-on-color text. We want color-blind readers to be able to read our articles, too. WhatamIdoing (talk) 23:47, 20 June 2010 (UTC)

On strike

Previous discussion: Wikipedia talk:Manual of Style (accessibility)/Archive 1#Striking text out

From the style guide: "By default, most screen readers do not indicate text attributes (bold, italic, underline), so struck-out text is read normally along with any other text." The three examples of bold, italic, and underline are all considered presentational in HTML 4. But as I understand it, strikethrough in a discussion page most often denotes deleted text. This has a perfectly good semantic element (<del>) that all visual user agents I've seen render with strikethrough style. Do screen readers also not indicate semantic text attributes, such as emphasis (<em> and <strong>) or side comments (as HTML5 has retconned <small>)? --Damian Yerrick (on | strike) 02:15, 15 June 2010 (UTC)

They do, but you have to explicitly tell them to inform you about attribute changes. By default, screen readers won't mention any attribute changes at all (e.g. bold/underline/italics/strikeout), but when a key combination is pressed, the screen reader will say the attributes of the text under the cursor. With JAWS, the screen reader I use, it is possible to configure it to indicate attribute changes by chaging the voice or playing a sound, using the Speech and Sounds Manager. Emacspeak indicates attribute changes by changing the voice by default, but not many blind people use that screen reader. Graham87 13:59, 15 June 2010 (UTC)

Sorry, I misinterpreted your question. The answer is the same with semantic text attributes; they're not indicated by default either. Additionally, there's no way to distinguish them from normal text attributes: I can't tell the difference between emphasised text and italic text. I'm not familiar with side comments. Graham87 14:05, 15 June 2010 (UTC)

Template:Chinesetext

Template:Chinesetext Where should {{Chinesetext}} should go in an article? Before the infobox, or after? As an example, take St. Michael's Cathedral, Qingdao which sparked a bit of a debate, as it is up for FA. The infobox contains Chinese characters. ɳorɑfʈ ^Talk! 15:14, 20 June 2010 (UTC)

Ah. After Noraft said on the FAC that he wouldn't post here, I see he has. Order of items in the lead says navigational templates go after the infobox, but doesn't address foreign language templates. This is a hold up at FAC: can we please get a reading from editors with screen readers, and have this addressed on the ACCESS page? I personally think putting the chinese text template first is butt ugly, but if it's not an access issue, I don't care how it's sorted-- we just need an answer for FAC. SandyGeorgia (Talk) 15:17, 20 June 2010 (UTC)

(EC) It doesn't matter to me as a screen reader user. Graham87 15:19, 20 June 2010 (UTC)

That's what we need to know-- can you adapt some wording for the guideline page? SandyGeorgia (Talk) 15:20, 20 June 2010 (UTC)

Something like "The position of foreign language templates does not matter for accessibility"? But it feels clunky to put it in the heading about the lead section, especially when that part of the page defers to Wikipedia:Manual of Style (lead section). Graham87 01:26, 21 June 2010 (UTC)

As per your comment ("that part of the page defers to Wikipedia:Manual of Style (lead section)"), I have posted about the issue in that forum. I'm curious as why it doesn't matter to screen readers (or to you), considering that page elements are read in a linear fashion, and I'd assume that if your computer doesn't support a particular language, you'd like a warning of why you're getting improperly rendered characters before it happens; but I don't know how screen readers work. ɳorɑfʈ ^Talk! 06:33, 23 June 2010 (UTC)

I've responded there to avoid discussion fragmentation. Graham87 14:20, 23 June 2010 (UTC)

My tweaks to the item about spelling and grammar in the text section

The item about spelling and grammar in the text section was directly lifted from a message I wrote about accessibility nearly four and a half years ago. I've taken the opportunity to clarify that it's only applicable to speech synthesizer users. I've also removed the mention of grammar from the item because grammar errors in their purest sense (i.e. excluding spelling, punctuation, and capitalisation) do not affect the sound of the text with a speech synthesizer. Regarding spelling, in my experience, most blind people, especially those who do not read Braille well, are poor spellers. See the New York Times article "With New Technologies, Do Blind People Lose More Than They Gain?" for some fascinating insights about literacy in blind people who only "read" through audio technology. The sample story written by the sixteen-year-old blind kid about "sleep bombs" is hardly a paragon of good spelling or grammar. I myself am a good speller, but that is partly because I've read Braille for most of my life. I often rely on Google to confirm the spelling of words, and one of my first major spelling mistakes inspired me to create a Wikipedia user page mentioning that I am blind.

I don't think for a moment that Wikipedia should abandon good spelling or grammar. I'm just not sure how important it is for the average speech synthesizer user who isn't a pedant like me. :-) Graham87 14:38, 29 June 2010 (UTC)

Tables

Could someone tell me how this works with a screen reader? Plastikspork (talk) 19:02, 29 June 2010 (UTC)

I'll respond at the TFD for the template in question. Graham87 01:33, 30 June 2010 (UTC)

Hi, Graham. I use a sortable table-like feature at Robert Rossen. I also use (X)HTML tables, sometimes containing numeric data. How do well all of these work in screen-readers? --Philcha (talk) 00:15, 1 July 2010 (UTC)

They work very well, at least for me. I can activate the sorting links and the table sorts correctly. My only criticism about the works table in Robert Rossen is that I'd prefer it if the film title was the first column, so I could automatically hear the film titles when I'm moving up and down the table. See "Tables with JAWS and MAGic" for information about how tables work in JAWS; many other screen readers have copied its table-reading functionality. Graham87 01:56, 1 July 2010 (UTC)

The article is mainly a biography, and Rossen had a very eventful life as a politically commited filmaker and as being brought forward to the House Committee on Un-American Activities. I would suggest that the years therefore important, as some locate events.

However, you know much more than accessibility. If you prefer title in the first column, do you know a way to switch columns - I don't have the time do it one at a time. --Philcha (talk) 03:46, 1 July 2010 (UTC)

It's not a big deal to me; it's just a minor inconvenience to move between the columns to figure out which film the notes and other things are talking about. I'd admit that I navigated the table in a rather unusual way, doing things like going up and down the notes column. On a scale of 1 to 10, I'd give it about a 2.5. In the absence of automated methods for moving the columns around, I wouldn't worry about it. Graham87 08:56, 1 July 2010 (UTC)

RfC on Consensus

Given WP:CONLIMITED, to what extent and under what circumstances can individual WikiProjects and users customize article appearance with individual styles that deviate from site-wide style guidelines? Interested contributors are invited to participate there. --Moonriddengirl ^(talk)

Great, and can we put an end to this? Thanks! Plastikspork _―Œ^(talk) 05:43, 1 July 2010 (UTC)

How to make accessible tables

A quick note on the recent update of our guidelines: this is the kind of tables an accessibility expert (also admin on the french Wikipedia) recommanded to make in his list of best practices. This is also recommanded on websites with a lot of expertise like WebAIM. We should use this syntax from now on, and correct tables using the previous syntax. Thanks for your help. Yours, Dodoïste (talk) 16:53, 27 July 2010 (UTC)

In the following example, would the "scope=" also go where indicated?

{|class="wikitable"


|-

!scope=col rowspan="2"| Year

!scope=col rowspan="2" width="300"| Album details

!scope=col colspan="5"| Peak chart positions

|-

!scope=col| UK

!scope=col| US

!scope=col| CAN

!scope=col| FRA

!scope=col| SWE

|-

...

This would give a table header like this:

Year	Album details	Peak chart positions
		UK	US	CAN	FRA	SWE

--JD554 (talk) 08:47, 3 August 2010 (UTC)

Hi. Thanks for your interest. In order for me to answer thoroughly, could you provide a link to the complete table? Dodoïste (talk) 10:39, 3 August 2010 (UTC)

Most discography articles use this basic layout for the tables, a reasonable example could be David Bowie discography#Studio albums. --JD554 (talk) 10:49, 3 August 2010 (UTC)

Your header is correct. :-) I checked with reliable sources to be sure. This syntax is supported in JAWS since JAWS 6.0 (march 2005), for example.

I've updated the example on David Bowie discography. As I suspected, there is another issue with these kinds of tables. I'd be helpful to have row headers, but currently the "Album details" column is too messy to allow that. It wouldn't be very helpful to make years row headers here. A correct row header in this case would be the name of the album. I suggest to rework it as follows. Dodoïste (talk) 15:46, 3 August 2010 (UTC)

Album	Album details	Peak chart positions										Certifications (sales thresholds)
		UK	US	AUS	AUT	GER	NL	NZ	NOR	SWE	SWI
David Bowie	Released: 1 June 1967 Label: Deram Format: LP	—	—	—	—	—	—	—	—	—	—
Space Oddity	Released: 4 November 1969 Labels: Philips, Mercury Format: LP	17	16	21	—	—	—	—	—	—	—
The Man Who Sold the World	Released: 4 November 1970 Label: Mercury Format: LP	26	105	44	—	—	—	—	—	—	—

Thanks for the comprehensive reply (I was going to ask about "scope=row" next). I'll put your suggestion for reworking the table to WT:DISCOGS. Thanks again, --JD554 (talk) 17:03, 3 August 2010 (UTC)

Thanks for asking. :-) I've just added WT:DISCOGS to my watchlist and I will follow the discussion. :-) Dodoïste (talk) 19:34, 3 August 2010 (UTC)

Colspan and rowspan: issue or not?

Although concerned about getting to grips with this, I support the basic principles behind the change. But twice I've read the data tables section, and twice I interpreted the limitations at the end as suggesting that colspans and rowspans should generally not be used. If this is indeed the case, it constitutes a massive change to the MoS, and should probably be subject to wider scrutiny. If I have misinterpreted, perhaps some clarification would be in order on these concerns? Regards, --WFC-- 13:40, 3 August 2010 (UTC)

Please note that I didn't make any change to the paragraphs about colspans and rowspans. It seems quite old, for example this paragraph was added in July 2009.

Colspans and rowspans in headers used in my example above is accessible in recent versions of screen readers (such as JAWS 6.0 released in march 2005). I guess some inappropriate use may cause problems. I don't know enough details yet to provide a complete explanation.

I have a hard time to understand the warnings about colspan/rowspan either. But I believe it intends to teach about common pitfalls rather than prohibiting its use. If we can find the author of theses paragraphs we could ask him/her to provide practical examples. Dodoïste (talk) 16:41, 3 August 2010 (UTC)

Hmm. I'm trying to understand by reading Thisisnotatest's edits. For example, right before he came to fix it this table contained misuses of rowspan. This is not really an accessibility issue though, since it makes it hard to understand for sighted users as well. Dodoïste (talk) 16:54, 3 August 2010 (UTC)

I agree that there was no need for it there, but sometimes colspan and rowspan are unavoidable. For instance, in sortable tables colspans are sometimes used in lieu of breaking the table into sections which would negate the use of sorting. Although I really like your solution to discography tables, I'm sure there are examples of rowspan where it would be far harder to avoid using it. On reflection, this change is a good thing (although it will require a bit of education to wikipedia's army of list designers, myself included). But knowing the way the Manual of Style is applied on en.wiki, sooner or later this will become compulsory. I appreciate that you may not have the answer, but I'd like to know whether implementing this change for rowspan/colspan tables is detrimental, irrelevant, or to some extent beneficial. If it's the former, we should probably explicitly list it as an exception, while making clear that rowspans and colspans should not be used if they can reasonably be avoided. --WFC-- 17:24, 3 August 2010 (UTC)

Please note that I didn't remove the colspans and rowspans in the discography table above. And it is accessible indeed.

Let's review this rowspan/colspan case in detail before making decisions. One thing is sure though: the warnings about rowspan/colspan are misleading, vague and possibly incorrect.

I have yet to see an appropriate use of rowspan/colspan that would be incompatible with accessibility. Could you provide examples of complex tables or sortable tables using rowspan/colspan?

I know we will find tables that are nearly impossible to make accessible. Or at least, impossible without removing a sortable function or special layout that users appreciate. I found several on the french Wikipedia already. The thing is users want to produce way more complex tables that what MediaWiki is currently able to produce. In those cases, we should focus on improvements in MediaWiki, and not reduce the quality of tables for the sake of accessibility.

Just found out that the whole warning was added by Thisisnotatest in november 2008. We'll make a thorough review before taking any decision, but we might consider to just remove these warnings in the end. They seem unreliable. Dodoïste (talk) 01:30, 4 August 2010 (UTC)

For what it's worth, I have never encountered any problems with the use of colspan/rowspan. The major problem I've had with tables over the years is improper/missing row and column headers. Graham87 05:35, 4 August 2010 (UTC)

Not all visually impaired users can afford the USD 895 or GBP 659 for technology as advanced as JAWS (that is an accessibility issue in itself), but they can make use of text-to-speech converters such as the simple one built into the Opera browser or the addons available for Firefox. Simply put, rowspans make life difficult for readers using these simple sort of solutions in many tables on Wikipedia. I've documented an example at User:RexxS/Accessibility. I'm not sure if this is what you mean by improper/missing row headers, but I'd be interested to hear your comments on whether you think that example is an appropriate and accessible use of rowspans. Whatever recommendations are employed to improve accessibility, they need to be simple, otherwise most editors will ignore them. It may be over-simplistic to advise against all use of rowspans, but IMVHO, it goes a long way to making tables more accessible in the present circumstances. --RexxS (talk) 11:36, 4 August 2010 (UTC)

Could anyone suggest a decent firefox add-on for this purpose? I'm interested in doing a bit of testing. --WFC-- 12:08, 4 August 2010 (UTC)

Note that most blind users won't use Opera voice and Firefox Add-ons. The reason for it is simple: it only works inside the browser. Which means they need a screen reader to use the desktop and launch the browser. If they dont have money, they may use the open-source NonVisual Desktop Access (NVDA). See the article by WebAIM Using NVDA to Evaluate Web Accessibility.

When testing with a screen reader, keep in mind that you are only doing it out of pure curiosity. It is not a reliable method to test accessibility. We should comply to W3C's WCAG 2.0 techniques, and aim for the AA accessibility level. That is all. Dodoïste (talk) 13:43, 4 August 2010 (UTC)

In developed countries, it's usually possible for blind people to access the technology they need (i.e. a good screen reader, a portable computer), especially if they're either studying or working. As noted above, NVDA is a good free screen reader, and as far as I can tell, its Internet support is about as good as that of JAWS. As for the table example at User:RexxS/Accessibility, I think it's an appropriate use of rowspans, but maybe it's just that I'm used to it. If a screen reader user navigates the table properly (and most modern screen readers have reasonable table support), the meaning of the table should be clear. However you bring up a good point that navigating the table linearly is confusing when it uses rowspans. Even if a blind user is using a decent screen reader, they may not know how to use it efficiently, so they might effectively read tables linearly, no matter what we do. Graham87 14:18, 4 August 2010 (UTC)

Non standard ASCII

Any guidance on non standard ASCII such as A♥? Gnevin (talk) 09:31, 4 August 2010 (UTC)

Yup. Don't convey information by color alone. The unicode heart character might not be rendered correctly by all screen readers, but I'm not sure yet. Using icons with alt text (red Ace hearts) is a rock solid solution to this. But before suggesting this change, I would like to learn more about the hearts and their result in screen readers. I'll ask an accessibility expert. Dodoïste (talk) 13:10, 4 August 2010 (UTC)