Wikipedia talk:Manual of Style/Accessibility/Archive 11

This is an archive of past discussions about Wikipedia:Manual of Style. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 5

←

Archive 9

→

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)

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^[1]
Spaced ^[2]

Coded as:

Common<ref>One</ref>
Spaced <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)

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 ( and ) or side comments (as HTML5 has retconned )? --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

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)

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 ..., 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. --W F C-- 23:47, 3 August 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
Year	Album details	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)
Album	Album details	UK	US	AUS	AUT	GER	NL	NZ	NOR	SWE	SWI	Certifications (sales thresholds)
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, --W F C-- 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. --W F C-- 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. --W F C-- 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)

I'm sorry I didn't make that clearer, but huge numbers of readers who are visually impaired are not blind. For example, I have a good friend who is registered blind and has a guide dog, but he has one-sixth vision and can design web pages. With the assistance of text-to-speech, he is able to ensure that what he thinks he is reading actually corresponds to the text. He – and many others like him – do make use of the simpler assistive technologies, and it is important to recognise that. Please understand that testing with a screen reader is not a substitute for making web content accessible for the blind, but it is a very real consideration for many other visually impaired users who wish to use the same software as those fortunate enough to be fully sighted. That takes it well beyond the realms of "pure curiosity" as far as Wikipedia (or any other web content) is concerned.

WFC, I have CLC FireVox addon installed and am quite happy with it. It may be worth trying out different ones until you find one you like (they are easy enough to uninstall). --RexxS (talk) 14:25, 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)

@RexxS: yes, I know about that and we agree. My reply was too short and misleading, sorry about that. This note was only intended to avoid a common pitfall when evaluating accessibility. I think a FAQ would be more efficient to teach about common pitfalls. Dodoïste (talk) 00:41, 5 August 2010 (UTC)

That's an excellent idea, Dodoïste. I see you're a member of WP:WikiProject Accessibility – would the development of a FAQ be best undertaken there? Jack Merridew and some others are working to improve markup on the 'pedia, and I believe good markup goes hand-in-hand with good accessibility, so there may be a few more editors interested in such a venture. I'd be more than happy to help out in whatever small way I can. --RexxS (talk) 01:15, 5 August 2010 (UTC)

Hi. This is an interesting thread. I'm down on rowspans for a number of reasons, including the issue that RexxS has the subpage for. rowspans confuse a lot of people and a lot of software. It is a false optimization to combine data cells this way. A lot of the history of rowspans is from the bad old days of using table for layout purposes. It is unfortunate that tables persist in this manner on wikis; this is largely due to wiki-syntax not natively supporting things like div-elements and ol, ul, and dl elements other than implicitly. rowspans quite regularly confuse ordinary editors who do not really get what they're dealing with when editing a mucked-up table; they have a hard enough time with the curlies and pipes. Rowspans are also incompatible with sortability, which I see as for more important. I'm up for more work re this; I'm doing a lot of it out there on the 'pedia, anyway. Cheers, Jack Merridew 02:01, 5 August 2010 (UTC)

Sorry, but this is not really helping. We need detailed sources or advice from experts. We need examples of accessible tables. We need alternatives for tables using rowspan/colspan when relevant. But we won't be able to do anything with opinions like "sortability is good so rowspan/colspan are evil". Dodoïste (talk) 12:10, 6 August 2010 (UTC)

Apologies for leaving it for a while to post this, I was hoping that Dodoïste could explain the problem more eloquently. I restored Dodoïste's recent edit, which was reverted by RexxS. My understanding is that rowspan should be depreciated, but I've seen nothing supporting a similar depreciation of images in tables or colspans, both of which are frequently used in FLs past and present. As I said in my edit summary, it is one thing to detail something as good practise (as this page used to do). It is quite another to make a practise manditory for our highest quality articles (as this page now does, being part of our Manual of Style). The information doesn't require inline citation, but at the very least it does require a broad consensus that the problem exists, and agreement on how the Manual of Style should tackle it, bearing in mind the way that the MoS is applied. Regards, --W F C-- 11:09, 8 August 2010 (UTC)

I found several old accessibility tutorials and guidelines saying we should avoid rowspan/colspan. And they seem to be outdated. For example, WebAIM's article that recommends to avoid rowspan/colspan clearly state that they are outdated and that it's no longer a problem with JAWS. Statement that Graham87 has just confirmed. Until we find clear evidence that there is still an issue with rowspan/colspan I feel it should be removed from the MoS. Dodoïste (talk) 12:50, 8 August 2010 (UTC)

There is clear evidence that there is an issue with rowspan/colspsan, and Graham also confirmed that anyone who reads tables linearly can encounter difficulties. My friend, for example, finds NVDA unusable because it overwhelms him with information, much of which he can read. Partially-sighted readers (and even old folks like myself whose vision is much less acute than it used to be) have a choice of screen magnification or having highlighted text read out to us. The problem with screen magnification is that I often find I've lost my place in the article when I return to normal viewing. The following is clear: (i) rowspans in particular jumble information when read linearly; (ii) simpler screen readers do not cope well when either row or column headers are spanned; (iii) having an image as a row or column header causes problems unless it has sensible alt text. I simply don't see why we should second-guess the inconvenience that these sort of issues may cause, when the simple solution of recommending against the use of these elements is available.

It's worth remembering that MOS is a guideline, and some exceptions are justifiable, but it puts the onus on the editor to consider these issues; it is not blanket ban on the use of particular elements. We do a disservice to impaired users by assuming that they should be forced to adopt our ideas of what technologies are appropriate. It reminds me strongly of the old days when some websites carried a message "This website is best viewed in Internet Explorer at 800x600" because the developer was incapable of catering for diversity. --RexxS (talk) 13:29, 8 August 2010 (UTC)

The last paragraph should be true, but sadly isn't. The MoS is a de-facto requirement, as I have learnt many times to my cost when suggesting that common sense might be appropriate. Explicitly requiring alt text for any images in a table I fully agree with. Indeed, I also agree that we should depricate images unless clearly appropriate (for example the key, images and alt text here in preference to the yellow and red card coverage here). As for rowspan and colspan, I'd say add some sort of wording suggesting that colspan and rowspan are allowed, but that there should be a demonstrable benefit. As I see it, our opinions aren't that different. But any wording needs to take account of the fact that the MoS is treated in some quarters as canon law. It also needs to accurately reflect the problem, so that editors without screen readers can accurately gauge whether a particular use of rowspan/colspan (from my experience usually only the latter) is beneficial enough to justify ignoring the advice. Temporarily commenting the section out pending discussion seems the appropriate step to me. --W F C-- 14:25, 8 August 2010 (UTC)

We should advice to make simple tables in general whenever possible. And provide examples of ways to simplify a complex table, or to split it in small tables. We should also advice to avoid using rowspan/colspan when possible (without making it a detrimental requirement). And provide good alternatives to rowspan/colspan. That is feasible and the benefits would be clear.

I believe you both are capable of making examples and tutorials for that. I personally won't have time to do everything. There is so much to be done in this guideline. And so much to do with developers and the Wikimedia Foundation. Could you do it? That would be a great help. Dodoïste (talk) 15:27, 8 August 2010 (UTC)

I've just reverted the cut you made re rowspans and the undiscussed addition re bold. You're being entirely too bold at editing these guidelines as suits your agenda. Please cut that out an discuss changes prior to editing the guidelines. The "scope" changes should probably be cut while discussion occurs, too. Jack Merridew 15:47, 8 August 2010 (UTC)

Jack, I understand why you did that, but I don't see that as being particularly constructive, bearing in mind that this dicussion is very much active. Furthermore, I certainly don't see Dodoïste as having an "agenda" (it could be argued that I do, but I engaged in discussion first, and it's Dodoïste that took the initiative after discussion).

I'm very happy to add an accessible tables tutorial to my to-do list, although it would be a medium-term project. Estimated timescale: 3 weeks to get my head around the conflicting issues of a desire for maximum functionality, total accessibility and as little disruption as possible (it won't really take that long, but I'm involved in two FLCs and a GAN right now, and am on holiday towards the end of the month). The first half of September to draft it in my userspace, plus time to get feedback and make modifications before moving it into the Help namespace.

That said, I do take RexxS' concern on board. Perhaps the following would be a good interim measure?

Images should ~~generally~~ be avoided in table headers, unless there is a demonstrable benefit to using them. If they are used, alt text and a key should be provided, to ensure that all readers can understand the information. The extent to which rowspan and colspan cause accessibility issues with screen readers is currently under review. ~~As a rule of thumb,~~ Rowspans and colspans ~~are best used in cases where they simplify the table~~ should be used sparingly; they should not be used in an overly confusing or purely decorative manner. Rowspans in particular can cause accessibility issues; an example of the output from a screen reader is demonstrated here. Editors should take this into account when designing tables.

It's not perfect, and may need to be strengthened or considerably altered in the medium-term. But while it would be wrong to mandate against these things without having a firm understanding of the problem and a good grasp of the solutions, to remove all reference to these issues isn't good enough. On the other hand, asserting in the MoS that they are harmful without proof or having a ready-made list of solutions strikes me as going too far too fast. I see this as the appropriate middle ground, subject to adhering to the timescale I've outlined above and reviewing this towards the end of September. Does that sound workable? --W F C-- 16:07, 8 August 2010 (UTC)

I didn't mean much by my use of 'agenda'; POV or opinion would suffice. I've not much though on the image question in the above. However, images in lieu of text is poor form from a search engine optimization perspectives and a lot of accessibility issue track with SEO issues. Your rule of thumb re row/col spans is quite off as 'simplifying' tables with them is the core of accessibility issue; it entails simplifying the rendered appearance of a table by increasing the implementation complexity at the expense of accessibility and functionality (specifically, by precluding sorting). The solution to the rowspan issue is simple and at hand; don't use them in most cases and simply give each cell the appropriate content. Jack Merridew 16:37, 8 August 2010 (UTC)

We cannot state that they should not be used though, because the evidence is lacking. Even if evidence is found, it's clear that there is no consensus to ban them; a quick glance at sitewide practise, even on currently nominated audited content, shows that. I've strengthened the wording to take your points into account. As I say, this is only an interim measure, to reflect the fact that there is no consensus for the previous version, but consensus that colspans, rowspans (and images) need to be given consideration. Thoughts? --W F C-- 16:52, 8 August 2010 (UTC)

I support WFC's proposal. I believe it's a good starting point. Dodoïste (talk) 20:21, 8 August 2010 (UTC)

That better, but it needs to be clear that rowspans and colspans should specifically be avoided in cases where it would be done to simply reduce repetition of information such as things that occurred in the same year (a common use; years are not the issue). That they exist in large numbers is not a reason to keep doing this wrong. This guideline needs strengthening, not cutting down. I cut rowspans from tables everyday, and for good reasons. Consider sorting, which is damn useful; it doesn't work with rowspans and that's unlikely to change. While not exactly an accessibility issue, it is an MOS issue. Throw in that rowspans confuse heaps of editors on a daily basis, and we've a solid set of reinforcing rationales to largely deprecate their use site-wide. There will inevitably be some exceptions, but damn few.

I hear there's an 'expert' on wp:fr. I'm right here and have considerable real-word experience with this stuff. This should be brought to the attention of a wide swath of the community before and serious change is made, here. That would entail a healthy discussion and gathering of discussion point and then an RfC via CENT. Jack Merridew 21:52, 8 August 2010 (UTC)

I agree with the idea of opening this to an centralised RfC, although my opinion is that we should wait until the help section has been created and is live, and until an FAQ has been devised (ideally by someone who understands the issues better than me) If we do it before we have all the bases covered, failure is likely.

As for your comment about rowspans for the likes of years, I agree that it should be eventually be depreciated. But the fact that it is so widely used (even in audited content) very strongly indicates that current consensus lies somewhere between indifference and support for the practise. Therefore it would be counterproductive to explicitly say that they should not be used for that purpose, if we are definitely going to an RfC in a few weeks. At best it would make no difference, at worst when someone tried to apply it someone else would challenge the whole thing, starting an RfC before we're fully prepared. I've underlined the suggested compromise above. Finally, provided that the message is clear, the length of a guideline is inversely proportional to its use.

I've copied my suggested wording below, without any strikes or underlining. The last bit is admittedly not strong enough, but for the reasons outlined in the previous paragraph I think the line needs to be drawn there in the short term. It's a reasonable compromise; if an RfC started today, with little evidence for the need and little guidance available to the uninitiated, it is unlikely that the community would be in favour of a mass depreciation. --W F C-- 22:53, 8 August 2010 (UTC)

Images should be avoided in table headers, unless there is a demonstrable benefit to using them. If they are used, alt text and a key should be provided, to ensure that all readers can understand the information. The extent to which rowspan and colspan cause accessibility issues with screen readers is currently under review. Colspans and rowspans should be used sparingly; they should not be used in an overly confusing or purely decorative manner. Rowspans in particular can cause accessibility issues; an example of the output from a screen reader is demonstrated here. Editors should take this into account when designing tables.

I still support this change. I suggest to make explicit link title, and replace "; an example of the output from a screen reader is demonstrated here" by "; as demonstrates an example of the output from a screen reader." Just a small fix, no content changed. :-) Dodoïste (talk) 20:15, 10 August 2010 (UTC)

Having spent a couple of days looking over the issue, I think I've considerably underestimated the scale of the challenge; providing answers to most table-related problems is far beyond my level of access-related knowledge. I do maintain that the wording in the blockquote tag is closer to project-wide consensus, clearer, and more difficult to wikilawyer behind than the current text. I also hold the belief that while our mission should be to strengthen this guideline, that taking a medium-term view is the way to get more meaningful results faster. Changes to this guideline only take effect when community consensus is with it. While we can change it with consensus on this page, it will be ignored if deemed unreasonable or not in keeping with community's view on the benefits of a particular practise.

As I say, I don't think my overall understanding is good enough to be a driving force in our attempt to improve accessibility, so with deep regret I'm going to have to step back from my previous intention of drafting a how-to by September. But I don't want this to be seen as backing away from this area. I'm deeply committed to it, and would be happy to help someone else with a how-to in any way possible. I would describe myself as a user not directly affected by accessibility issues, but conscientious enough to take the principle seriously, technically adept and determined enough to find ways of accomodating the conflicting desires of functionality and accessibility, bad enough at writing that I do extensive work on tables, assertive enough (sometimes through articulation, sometimes through more abrupt methods) to get the apathetic to take a considered look at an idea, and, although I'm certainly not known for it, humble enough to ask for help when my knowledge simply won't cut the mustard. If anyone has suggestions on how someone with those attributes could help this area on a wider scale I'd be extremely interested. Regards, --W F C-- 02:59, 12 August 2010 (UTC)

Fractions

I've been looking around, but haven't been able to find an authoritive, definitive statement about how to deal with fractions. WP:Manual of Style (dates and numbers)#Fractions says that {{frac}} is "available", but doesn't mandate it. Unicode characters for ½, ⅓, etc. appear in the Symbols tab of the insertion bar below our edit window, so presumably they are endorsed somewhat. However, many popular browsers render the output of {{frac}} poorly, especially within tables, and discussion on Template talk:Frac confirms problems still exist. (The template was nominated for deletion for some of these reasons just a few weeks ago.) My question is which of the following is preferred from an accessibility perspective:

½	1⁄2

I have seen comments that screen readers will ignore the Unicode ½ but are those assertions true? How does the template output (which expands to 1⁄2) sound in a screen reader or look in a text-based browser like Lynx? Some guidance from accessibility experts would be welcome, thanks! — Andrwsc (talk · contribs) 18:17, 5 August 2010 (UTC)

I'm not an expert, but I can tell you immediately that ½ is read by Opera as "one half" and 1⁄2 is read by Opera as "one vee two". What screen reader did you have in mind? --RexxS (talk) 22:56, 5 August 2010 (UTC)

None in particular; I don't use a screen reader myself. I just want to know what the "best" wiki markup for fractions ought to be, all things considered (aesthetics, accessibility, etc.). I have no problem with ½ when viewing a page (although it looks terrible in the edit window font), but I see a clipped denominator with {{frac}} output in a table when using IE8.

My attempt to use ½ on a featured list was challenged, and I want to have some clear guidance on what method is preferred. — Andrwsc (talk · contribs) 00:02, 6 August 2010 (UTC)

(I can't speak for screen readers, but that last denominator is clipped in Firefox 3.6 as well.) --W F C-- 00:10, 6 August 2010 (UTC)

The last denominator is an image (screen capture from IE8). The wikitable markup looks ok in FF3.6 and Opera 10.60. I can check other browsers if you wish, but I expect Internet Explorer will have a problem in any version (as usual). --RexxS (talk) 15:06, 6 August 2010 (UTC)

JAWS says "one half" for the first example and "one slash two" for the second one. I'd prefer the a notation like that in {{frac}} be used, since screen readers will read it consistently. JAWS (and most other screen readers) are only able to read the fraction characters "½" and "¼" correctly by default. Graham87 03:41, 6 August 2010 (UTC)

Visual headings should be avoided

I recently added a paragraph about the issue with headings made out of bold text and ";", but I was reverted because there was no prior discussion. This paragraph is the translation of the first section of the French best practices for accessibility. Those best practices are written by an accessibility expert. I also saw this practice on the English Wikipedia here and there, so I assumed there wouldn't be any problem with it. Any thoughts? Dodoïste (talk) 20:16, 8 August 2010 (UTC)

"Headers" should not, of course, be mimicked using mere bolding or mucking with the font-size. How about we get clear on what you did: you added your new bit to the guideline and immediately used it as a rationale to revert a bit of a change I had made to an article. Thing is, those two "headers" you added were setting-off trivial amount of content. And I was not using the three-apostrophe syntax to indicate bold, I used a ';' to indicate a definition list, which an appropriate semantic structure for what I was doing. That page and, many others, do not need separate section headings for two bulleted bits of boilerplate. You have been far too bold in pushing guidelines, help pages and such about for one so inexperienced here. Fair warning: I'm about to start clearly calling you a disruptive editor. Jack Merridew 22:11, 8 August 2010 (UTC)

Take it slow, Jack. It's reasonable to assume English is not Dodoïste's first language, so the wording may not contain nuances that he intended, and so far nobody's stepped outside the bounds of our conventions on collaborative editing. I feel sure he was trying in good faith to make a point in his edit to this guideline that '; ... :' is not interchangeable with headings, nor as a means of emphasising a piece of text. You're quite right that a definition list has a place in semantic structure, but it's a point that is not immediately obvious to many editors, and it's our job to help clarify that. I do believe that the MOS guidance at MOS:LIST could usefully be expanded. It's also likely that this guideline would benefit from some guidance along the lines of Dodoïste's edit to emphasise the issues around the misuse of definition lists for the visually-impaired. Let's have a good look at what guidance should be given and try to formulate some wording.

Dodoïste, you may not be aware that edits to policy and guidance on en.wikipedia are slightly different from edits to mainspace, as there is a conventional requirement for a greater degree of consensus for such an edit. If you're unsure, I'd always advise bringing an issue up on the talk page first. --RexxS (talk) 22:56, 8 August 2010 (UTC)

I expect their first language is French, and per their fr:User:Dodoïste that Dodoïste is a she. My reference to their edging towards disruptive editing is rooted a few points; changing a guideline and then quoting that guideline as a rationale for a revert within a minute is plenty to give one pause. They've aggressively edited this guideline without prior discussion quite a lot, too, and have revered me elsewhere, as well.

Definition lists are one of the secret weapons of serious web developers ;) It's really a very versatile structure and there's a ref somewhere in the W3C spec that refers to it specifically as appropriate for a lot of structural use (not that that is what I was doing, here). The revert in question was a bad one, as were several others related to discographies. Far too many editors bulk-up TOC with too many minor entries that simply don't warrant being any level of heading, and this is where structures such as definition lists step in. Table captions, too. Dodoïste's revert (and proposed) change to the guideline both refer to bold text, which is semantically meaningless; it's about presentation. <aside>the markup generated by the usual apostrophe wiki markup is 'b' and 'i' elements, rather than 'strong' and 'em' elements, which is improper.</aside> I regularly convert explicit bold faux-headings to either true headings or to DL, as appropriate. A distinction is needed between a DL structure and mere bold text.

Dodoïste, you've already slipped the scope piece into this guideline and implementing that site wide as explicit markup is impractical, as there are literally many millions of table headings. The 'insert table' buttons don't generate this, so mostly it's not going to happen via this route. As said, please go slower with this stuff. There are at present only a few folks aware of these discussions, and this is a really big project with a lot of people with a lot of strong views. Jack Merridew 23:40, 8 August 2010 (UTC)

Oh my. A few explanations, but very short as I would really hate to get in a personal dispute or something. I don't want to hurt anyone, and I apologize if my edits were perceived in that way.

I did not see that the ";" were recently added to Kelly Rowland discography. I provided a link to this MOS only to add explanations the edit summary couldn't contain. I just edited this article like I edited another one year ago.

By the way I'm a man, and I stated on my french userpage that I love women. There is one person editing in front of my screen – me – so please stop referring to me as "they".

I'm happy that this guideline is part of the MOS. But don't you ever forget that it was written by enthusiastic amateurs. This page is really lacking. Hopefully it's better than what WP:ALT was a few months ago. Basically, after months of endless debate a clever user hopefully requested an accessibility expert to comment this guideline. He basically said they had it all wrong. Afterwards, the guideline was rewritten completely according to the expert's advice and is now fairly good. But as a consequence of the long debates it was removed from the guidelines. Too bad.

In short, if you don't want this page to be removed from the Wikipedia guidelines (like WP:ALT) you'd better improve it.

At Wikimania, I held a conference about accessibility and Wikipedia: First steps towards accessibility, where I mentioned the tables and how the guidelines should be improved (among other things). When I began to introduce "scope="col"" in the guidelines about tables I told Danny B. (a fellow member of the Accessibility initiative on usability wiki) about it. He replied: "Why are you doing that? You'll just be reverted!". I answered that my previous experiences in guidelines improvement on en.wiki were quite successful. And I believe there are a lot of smart folks here.

I don't have time to reply thoroughly on the content as I work tomorrow, and I'll have to get up in about 7 hours. But please, Jack Merridew. Please read again 10.3 Definition lists: the DL, DT, and DD elements in W3C's spec. Please check the source code produced by MediaWiki. What is a "definition term" (DD) without a "definition description" (DT)? Definitions are mostly for Wikitionary (and extremely useful there). The only article I found where use of DD and DT would be appropriate is HTML element#Document body elements. And this very article uses it incorrectly: tons of "definition list" (DL) containing one item (semantically bad); several "definition descriptions" (DT) per element instead of one (should use BR to make a new line instead); and no "definition term" (DD) at all. Seriously, what the fuck. It will be nearly impossible to get a good use of it on Wikipedia (but it has a great future in Wikitionary).

"The markup generated by the usual apostrophe wiki markup is 'b' and 'i' elements, rather than 'strong' and 'em' elements" --> Almost correct. But most uses of 'b' and 'i' are for layout only, which is why they were deprecated. 'Strong' and 'em' are semantical emphasis, not typographical layout. In short, MediaWiki is correct in his behavior. Dodoïste (talk) 21:47, 9 August 2010 (UTC)

Response to Jack: I think I can find the W3C examples you were thinking of – see below.
Response to Dodoïste: Definition lists are actually semantically appropriate whenever you have a list consisting of pairs of items that are related; W3C gives examples of other uses such as plays and advertising a product. Each pair requires one or more (dt) elements, and one or more (dd) elements that may contain block level elements – so no need for line break (br), as paragraphs (p) are usable (and are recommended by HTML3.0 on). So as you can see, the definition list is actually a very flexible structure used to associate elements without having a hierarchical structure such as headings. It may well have more applications on-wiki than you first think, but of course we are limited by wiki-markup. Properly used definition lists don't present a problem for accessibility. As for the way that the wiki-markup is rendered, I partially agree with you, but as layout it really should employ classes to delineate each element rather than (b/i/etc.) tags; this would allow for different skins or for registered users to override the default rendering as required. I guess that's another issue to sort out later. --RexxS (talk) 00:30, 10 August 2010 (UTC)

I agree with most of what you said. The biggest problem here is the high difficulty to produce semantically correct content with definition list in MediaWiki. Just try to fix HTML element#Document body elements, you won't be able to do it without changing {{XMLElement}}.

Add to it that most uses of definition list are for layout only.

Sure, instead we could teach users to make a good use of definition lists. It will be hard though. I suggest:

Bold should not be used to make visual headings because users without sight won't recognize them as headers. The ";" element is often used for the same purpose, which should be avoided as well. Note that ";" is meant to produce a definition list, and when correctly used it can be a great improvement. For possible uses, see Wikipedia:Manual of Style (accessibility)/Definition list (let's create a dedicated help page for it, because there is a lot to write about it). When the table of contents is too long use {{TOC limit}} to shorten it.

Yours, Dodoïste (talk) 20:03, 10 August 2010 (UTC)

What if the purpose is not actually to create a header, but to visually break up an oblong gray blur? Several readers with dyslexia have complained about long articles on Wikipedia. Liberal use of color (which we don't do) and text formatting (which we can) can make articles more accessible to some of them. So if you're putting a sentence in bold-faced text as signal that (1) is needed for some sighted people and (2) is never needed for non-sighted people, then why should this signal be arranged to be "visible" to non-sighted people, for whom it is useless?

As an example, consider a long, old-fashioned magazine article: It's a densely printed oblong gray blur. If you don't break it up visually, readers get fatigued and quit reading. Consequently, an editor might add dingbats, pull quotes, drop caps, bold text, small caps, italics, or other text-formatting features at the beginning of one or two paragraphs on each page -- merely to help readers keep their place on the page, not to provide content.

These features can solve a problem that only affects sighted readers. Not flagging those could not harm the non-sighted readers, as they don't need this kind of help. So -- why shouldn't we use bold-faced text on occasion? Why not use purely visual cues to solve a purely visual problem, when that can be done at no cost to our non-sighted readers? WhatamIdoing (talk) 23:50, 12 August 2010 (UTC)

Isn't that a solution looking for a problem? Well-written articles will already be broken up into sections with headings; sections broken into paragraphs; judicious use of images, lists and tables further break up the block of text. Many of these already have classes associated with them that can be overridden in the individual user's skin.css stylesheet – which is the place to do it. Hard-coding formatting merely imposes one presentation style on all sighted readers. If an article actually requires something to break up the text visually, isn't that usually a sign that some rewriting is in order? --RexxS (talk) 00:26, 13 August 2010 (UTC)

[Without taking a position on the underlying issue,] I've done over 7,000 edits since March 2008, and while I have only the very vaguest idea of what Cascading Style Sheets are and may do (no, I'm not asking anyone here for an explanation), I've never made skins or monobooks or CSS one of my preferences. In that I'm sure I'm with quite a large majority of registered editors. And registered editors are only a very small fraction of all Wikipedia editors and thus a minute sliver of Wikipedia readers. So saying "Many of these already have classes associated with them that can be overridden in the individual user's skin.css stylesheet..." suggests a workaround that almost no Wikipedia reader can, as presently conformed, make use of. —— Shakescene (talk) 03:07, 13 August 2010 (UTC)

You're quite right that unregistered viewers (and that's a huge majority) and most registered viewers won't modify how they see Wikipedia. They see whatever the editor presents to them. But if we're considering someone with an impairment, then it may be worth their effort to find out how to enhance what they see. It only takes one example for them to copy if they register, and it works on all of our pages. It's not difficult to make headings bigger or bolder or with more space above them if that's what they need, as long as we mark headings as headings, and not just as large or bold text, etc. The same sort of thing goes for paragraphs, lists, wikilinks, etc. It only takes a single line like:

h2 { font-size: 180%; font-weight: bold; }

in User:Shakescene/monobook.css (or User:Shakescene/vector.css if you have the new skin) for you to have bigger, bold, level 2 headings. The point I'm trying to make is that we can make reading easier for those who want the help, but we won't do it by inserting bold markup into huge numbers of individual articles. --RexxS (talk) 04:34, 13 August 2010 (UTC)

Changes to this guideline

Like I said above, I still have tons of thing to add and improve here. Should I write them in a subpage of the Wikipedia:WikiProject Accessibility? So you could pick up any change you feel is ready to become part of the MOS, after you discussed it here? Dodoïste (talk) 21:51, 9 August 2010 (UTC)

You could use a subpage of Wikipedia talk:WikiProject Accessibility or a subpage of this talk page here. I guess it would depend on the principal audience you are looking to draw into discussion. Either way, it would be appropriate to post a brief notice on each of the talk pages, drawing attention to your proposals. Cheers --RexxS (talk) 00:38, 10 August 2010 (UTC)

When a guideline needs a serious re-write, but at least parts of the structure can be retained, I've had some success with dealing with one issue at a time, on the talk page. Typically, you pick one section or paragraph, and propose changes just to that one part. That way, nobody's overwhelmed by the volume, everyone can see exactly what you want to change, and unrelated points can be discussed separately. Once consensus develops (or doesn't) for the first change, you then put the next proposal out. The downside to this incremental approach is that it requires some persistence and organization on your part, since you'd need to keep feeding revised sections to the talk page slowly, over time, instead of making one big push. OTOH, I think it has a higher rate of success, with less drama. WhatamIdoing (talk) 03:22, 10 August 2010 (UTC)

OK, I'll do it that way then. Thanks for your advices. :-) Dodoïste (talk) 20:06, 10 August 2010 (UTC)

Can I just say that this is becoming a bit of a nightmare as discussions have popped up in several other places such as the FL listing for Kelly Rowland discography and more significantly at Wikipedia talk:WikiProject Discographies/style#Accessibility issues. It seems apparent to me that this page is undergoing and update which is perfectly fine. But then it isn't acceptable for projects like MOS:DISCOG to then be littered with a brawl of confusing and undiscussed changes as well as genuine changes to the MOS:ACCESSIBILITY. So here's a suggestion. First of all someone should create an essay about the imcumbent changes to MOS:ACCESSIBILITY and explain that wikipedia in general is undergoing change. Then that essay should be made widely available. Following this the actually MOS should be updated as suggested above. HOWEVER changes should not be imposed on others until it is clear what the actual goal is. Dodieste can be my testiment that the recent on-goings at Wikiproject: Discographies has been a mad mess of confusion. Those trying to implement the accessibility changes point to a number of different pages all with conflicting advice. It would be better if everything was centralized and if simple non-jargon terms were used. Only one the accessibility policy is agreed can people and projects adapt. But there needs to be a clear outline which I feel at the moment there isn't. I'm sorry if this sounds negative but I do support a movement towards making wikipedia easier to access for all involved but like Dodieste has said... it needs to be done without drama and without overwhelming people. ---- Lil_℧niquℇ №1 (Talk 2Me) 02:02, 12 August 2010 (UTC)

Perhaps it would be simpler and equally effective to put a banner similar to {{Under construction}} at the top of this page.

And perhaps someone should advise the DISCOG folks to stand down for a couple of weeks, while we get these things sorted out. WhatamIdoing (talk) 18:18, 12 August 2010 (UTC)

Us lot at discogs have been thrown into the deep end because someone decided to criticise the entire project. This has resulted in the stalling of an FL nomination and an indescriminate messy discussion at the talk page of MOS:DISCOG because like I said there's no clear goal of exactly what is trying to be achieved. There's also too much 'expert' opinion being chucked around but not enough evidence or examples of the on-going changes / what needs to be changed. -- Lil_℧niquℇ №1 (talk2me) 22:50, 12 August 2010 (UTC)

If it is accepted that this guideline/policy is under construction then others should not be trying to enfore a broken/incomplete Manual of Style. -- Lil_℧niquℇ №1 (talk2me) 22:52, 12 August 2010 (UTC)

This discussion is predicated on the assumption that guidelines are prescriptive, not descriptive. Just as all articles are works in progress, so are the guidelines used to help construct them. When, as now, many more editors are becoming aware of the importance of accessibility and usability, some articles will reflect those changes before they are codified in MOS. If that becomes a barrier to FA/GA status, then it is an issue to take up with the FA delegates and GA reviewers, as they are the ones enforcing particular styles. When WP:WikiProject Discographies/style becomes part of the WP:MOS, then it will be reasonable for reviewers to ask for compliance, but if the recommendations at DISCOG were to conflict with the MOS, then it is clear that MOS will override them per WP:CONLIMITED. --RexxS (talk) 23:29, 12 August 2010 (UTC)

Table guidelines and highway articles

I will start out by saying that I'm out of my element here, and only discovered some of the discussed changes above by accident. I edit articles on highways, specifically highways in the US state of Michigan. Highway articles use a table to represent the major junctions along the highway. In Michigan, with a few exceptions, the tables are built using templates, so any necessary changes can be made to the templates to deploy the changes state-wide. I've added scope="col" to the templates that create the table headers. We use rowspans a lot. Looking at M-28 (Michigan highway), any time there are multiple junctions in the same county, the county name cell spans the rows. The same goes for the municipal locations like cities, townships, villages, etc. Is there a table formatting parameter I should add to the templates to update these tables? Imzadi 1979 → 03:21, 12 August 2010 (UTC)

While we're here, does scope="row" have to be used in conjunction with a row header, or can it also be used on an ordinary first cell of a row? --W F C-- 03:41, 12 August 2010 (UTC)

Thanks for your efforts, Imzadi1979. Your edit to Template:MIinttop improves accessibility, and is a good first step. The guidelines for further improvements (including rowspan/colspan) are currently debated and are not yet written. It is too early to make further improvements. Please check the evolution of Wikipedia:Manual of Style (accessibility), you may find more information in the months to come.

WFC, I won't answer that one before you show me a concrete need to use it. There are several ways to code an accessible table. But to much code and different uses of the code will confuse editors. In the end, editors will make more mistakes. That's why we need simple and consistent code to make accessible tables. We will use more complex syntax only when it's unavoidable. I need examples to make sure we can't solve those cases in a simple way. Dodoïste (talk) 10:35, 14 August 2010 (UTC)

Following on fromWikipedia_talk:Manual_of_Style_(accessibility)#Non_standard_ASCII

Provide a transliteration for all text in a non-Latin writing system. Screen readers without Unicode support will read a character outside Latin-1 as a question mark, and even in the latest version of JAWS, the most popular screen reader, Unicode characters are very difficult to read.

To be changed to

Screen readers without Unicode support will read a character outside Latin-1 as a question mark, and even in the latest version of JAWS, the most popular screen reader, Unicode characters are very difficult to read.
- Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
- Don't use unpronounceable symbols such as ♥, use an images with alt text instead Gnevin (talk) 14:07, 16 August 2010 (UTC)

Great idea, I support this change. I would add: "don't use symbols such as ♥ use an icon with alt text instead". Dodoïste (talk) 19:12, 16 August 2010 (UTC)

Is my essay on accessbility suitable for music editors?

I've had a go at simplying a few accessibility changes specifically for music editors and I thought the completed essay could be distributed amongst those in the community. Since i know many of the high profile editors I thought that if they saw me adopting the policy it might have a knock on affect. See User:Lil-unique1/Accessibility and let me know what you think. Please do not edit the page but if there are errors do let me know. ... -- Lil_℧niquℇ №1 (talk2me) 23:23, 16 August 2010 (UTC)

Good idea indeed. Whoa, there are far too many things going on here, I can't keep up. I won't be able to comment in detail before this w-e, please remind me my duty. ;-) For now, the basics:

"If a completely new editor wishes to modify the article with credible information they will find it extremely difficult because they won't know all of the intricate coding that goes into making the page look pretty." -> This is a usability concern, and is absolutely not related to accessibility. This is a very frequent misunderstanding.
"If viewed on a portable device e.g. mobile phone or iPod touch such pages often appear misformed." -> Interoperability is one of the induced effects of accessibility (and a part of the "universal accessibility" approach) but is not the main goal in itself. Though it's often strongly encouraged by accessibility experts.

To learn more about it, I suggest Introduction to Web Accessibility by WebAIM and Introduction to Web Accessibility by the W3C.

If you like videos, I found those to be really mind-blowing:

Yours, Dodoïste (talk) 23:55, 16 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)

It's not a good idea. I can't read the hearts symbol with JAWS. Graham87 14:20, 4 August 2010 (UTC)

Nor is it spoken by the simple text-to-speech converters that I tried. I'd prefer either "Ace of Hearts" as text, or an icon with alt text as suggested. --RexxS (talk) 14:34, 4 August 2010 (UTC)

Spelling out every card is totally impractical on pages like List of poker hands. Is there any way to apply alt text to text? Maybe <abbr> tags? Happy‑melon 16:05, 4 August 2010 (UTC)

Alt tags aren't read by screen readers are they? They are not printed out for sure Gnevin (talk) 16:14, 4 August 2010 (UTC)

Yes they are, see Wikipedia:Manual of Style (accessibility)#Images and WP:ALT. --JD554 (talk) 16:21, 4 August 2010 (UTC)

I agree the best way is to replace them with an Icon with Alt text Gnevin (talk) 16:23, 4 August 2010 (UTC)

The safest way would be to alter the penultimate four lines of {{Cards/core}} to supply the required output, then you wouldn't have to update each article. As Happy-melon says, I believe that <abbr title="spades">♠</abbr> should work, but I'd need to see it tested on some screen readers. You might want to do the same to render K as "king", etc. --RexxS (talk) 16:44, 4 August 2010 (UTC)

This would be a misuse of the abbr tag. Semantically speaking, A♥ 2♥ is nowhere near an abbreviation. And it would be confusing for the user. Last time I asked Graham87 about it, he told me the abbreviation is displayed on demand. That means he first has to know that the content is an abbreviation. In this case, the only spoken content is "2". And "2" is not supposed to be an abbreviation for anything. Best practice here is to use an icon with alt text. And thanks to Graham87 for testing. Dodoïste (talk) 16:57, 4 August 2010 (UTC)

On the contrary, that's exactly what an abbr tag is for. Semantically, the two characters 'A♥' (the output of the template) is an abbreviation for "Ace of Hearts", just as 'WHO' is an abbreviation for "World Health Organization"[6]. Would you raise the same objection if it output 'AH'? There is nothing confusing for a user to hear (or see as a tooltip) "Ace of Hearts" instead of 'A♥', nor would it confuse a search engine. I don't see where you get "2" from, but even if we were considering '2♥', it's worth noting that the character '2' is a label for the "Deuce of Hearts" and has very little actual relationship to the numerical value 2 - it is merely coincidental that the abbreviation for the deuce/two is a character that is recognisable as the same thing. Try your logic on 'K' and tell me it's not an abbreviation for "King". I have nothing against using an icon with alt text (other than a preference for text over images that could be rendered as text, and the associated unnecessary byte overhead), but what icon are you going to use for "Queen", which would otherwise read as 'Q'? --RexxS (talk) 19:17, 4 August 2010 (UTC)

Don't forget wiki is meant to be printed also ! Gnevin (talk) 20:43, 4 August 2010 (UTC)

Apologies if I'm being dense, but why would printing 2♥ be an issue? --W F C-- 20:49, 4 August 2010 (UTC)

~~Eh, it won't .... carry on nothing to see here just a user making a fool of himself Gnevin (talk) 20:55, 4 August 2010 (UTC)~~ Awe I remembered, abbr don't print out but we have had both it would be ok Gnevin (talk) 20:58, 4 August 2010 (UTC)

(edit conflict) You can't always guarantee that non-ascii characters will print as they are displayed on screen, so it's always worth checking, so Gnevin actually has a point. I can confirm that printing from Firefox under Windows XP to a pdf file displays the hearts character just as it displays on my screen. Dodoïste, when you change earlier comments, it's conventional here to use ~~strike though~~ for the text removed and insert for added text, as a courtesy to others who may be confused by other comments made before your amendment (which would show as A2). --RexxS (talk) 21:08, 4 August 2010 (UTC)

Thanks for reminding me RexxS, I forgot. Actually, <s> is deprecated. <del> is the tag that goes along with <ins>. Now will you place the <del> tag around your strike trough and insert a correct deletion after it, or will you change earlier comment at the risk of confusing readers? :D I feel soooo evil! Dodoïste (talk) 11:05, 6 August 2010 (UTC)

Hehehe - t'as raison! I won't change anything more, at risk of confusing other readers. My only defence is that <s></s> is available from the extended editor interface, so is quicker to use for editors (in my case it's just laziness). In fact, since almost the only use on-Wiki is to indicate deleted content in talk, we ought to be asking for it to be replaced by <del></del>. Cheers --RexxS (talk) 14:53, 6 August 2010 (UTC)

I think Template:Card and Template:Cards should be merged, if that is possible. I made the former template accessible by adding alt text; the same approach should be used at the latter template. Graham87 01:26, 5 August 2010 (UTC)

There are also WP:MOSICON considerations here namely Wikipedia:Manual_of_Style_(icons)#Do_not_use_icons_in_general_article_prose Gnevin (talk) 08:52, 5 August 2010 (UTC)

That guideline is primarily intended to explictly ban flags being used in prose. Something I agree with. However, in my opinion there are strong grounds to make an exception for poker, an opinion that (judging by the lack of mention of it at the List of poker hands FLC) appears to be reasonably widely held. --W F C-- 14:35, 5 August 2010 (UTC)

I'd be in favour of WP:IAR in this case also but just make users aware of it Gnevin (talk) 21:37, 5 August 2010 (UTC)

As the article List of poker hands doesn't actually contain icons at present, the lack of mention of that at FLC is hardly surprising. I still have a preference for not using images where text can convey the same information (albeit non-ascii text in this case). I still think text+title attribute is a superior solution to image+alt text in any such case. --RexxS (talk) 22:47, 5 August 2010 (UTC)

Before going into the details with abbreviations and icons versus unicode character, let's try something simpler. Heart (symbol)#Computer code contains a list of different codes to produce a heart. The one used now is a unicode character. But HTML codes can also be used to produce those signs and may have a better result in screen readers. How does screen readers read 1) ♥ 2) ♥ or 3) ♥ ? Is there a difference ? Dodoïste (talk) 10:58, 6 August 2010 (UTC)

A quick way to estimate any difference is to examine how a browser renders the html delivered to it (and that will depend on the coding set for the page, "charset=UTF-8" for Wiki):

(original editor's source:) 1) ♥ 2) ♥ or 3) &hearts;
(Opera page source:) 1) ♥ 2) ♥ or 3) ♥
(Firefox page source:) 1) ♥ 2) ♥ or 3) ♥

So it is likely that there is little difference. Certainly Opera reads them the same, but not as "hearts" - it says "ee". Graham will be able to tell you if JAWS produces better results. It would be interesting to see how:

♥ (i.e.) ♥
or <abbr title="hearts">♥</abbr> (i.e.) ♥

are read by JAWS. --RexxS (talk) 14:53, 6 August 2010 (UTC)

JAWS reads all three examples as question marks. Graham87 14:58, 6 August 2010 (UTC)

Well, that settles it for me. Icons+alt text is the most accessible solution. Apologies to WFC – he has it right. --RexxS (talk) 15:12, 6 August 2010 (UTC)

Re using User:Chzz/cardtest. I'm responding to the note dropped on the gambling page. I'd vote strongly against the change to this proposed template. The images are totally blurry. I wonder why there is even a question with them being blurry. They are simply not useable! Vegaswikian (talk) 19:01, 12 August 2010 (UTC)

Ok changes made. Can someone with a screen reader tell us how it reads Gnevin (talk) 13:59, 16 August 2010 (UTC)

Image links are placed on their own line with JAWS and other screen readers. So the output of the template sounds like this, where a comma is a line break: "k, of hearts", "2, of diamonds", etc. That's OK and far more readable than before, but I still prefer the solution that I implemented at Template:Card. Graham87 14:09, 16 August 2010 (UTC)

{{Cards}} and {{Card}} handle a different roll .Using {{Card}} in the middle of sentence would certainly fall foul or WP:MOSICON. Gnevin (talk) 14:16, 16 August 2010 (UTC)

OK, fair enough. Graham87 14:56, 16 August 2010 (UTC)

Great, thanks Gnevin. Maybe the alt text could be improved by replacing "k, of hearts" by "King of hearts". Is that what you meant Graham87? Dodoïste (talk) 19:07, 16 August 2010 (UTC)

Which takes us back to the question of how to expand ascii text abbreviations for screen readers. It would be nice, but I haven't seen a foolproof way yet. --RexxS (talk) 20:06, 16 August 2010 (UTC)

No because it would be read a k, King of Hearts which doesn't make sense Gnevin (talk) 22:07, 16 August 2010 (UTC)

Yes, because that's the point I'm making. There isn't a foolproof way of getting ascii text to read as something else. --RexxS (talk) 23:06, 16 August 2010 (UTC)

@Gnevin: Oh, that's right. :-) Dodoïste (talk) 23:16, 16 August 2010 (UTC)

@RexxS:

The abbr element is implemented in assistive technologies as "some additional information that will be used (e.g. spoken) when the user request it". Which means that it should be used in contexts where the user will expect that the content is an abbreviation. Otherwise he won't have any chance to ask the software to speak the abbreviation out loud. And the abbreviation will be useless.

In the case of Unicode emoticons, it's much more robust to use an icon with alt text. That way we are sure the information is conveyed properly to screen reader users. In the case of ASCII art, both abbreviations and images can be used.

If you want to learn more about alternatives to ASCII, see Providing text alternatives for ASCII art, emoticons, and leetspeak et Failure of Success Criterion 1.1.1 due to using ASCII art without providing a text alternative. Yours, Dodoïste (talk) 23:16, 16 August 2010 (UTC)

Without having to grumble about egg-sucking grandmothers, I'm perfectly aware of H86, and you'll note that the use of the <abbr> element is part of their recommended solution. However, here we are not dealing with ascii-art, unicode emoticons, nor leet-speak. As you're no doubt aware, H86 notes that not all assistive technology deals with abbr in an ideal way, and common visual agents such as IE7 fail the test for H86 (although that's a minor concern). Hope that helps. --RexxS (talk) 00:37, 17 August 2010 (UTC)

Yup, I'm aware of it too. I replied that way because I misunderstood your previous post. I thought you were still supporting the abbr solution. Sorry about that. Nice to see you are able to use the WCAG 2.0.

I chose the previous reference because it is detailed about abbr and contains an example of technique with an icon and alt text. A more accurate technique would be F26: Failure of Success Criterion 1.3.3 due to using a graphical symbol alone to convey information. F26 is about "pictorial or decorative character symbol (glyph) which imparts information nonverbally" and suggest to use "an image with a text alternative instead of the glyph". Dodoïste (talk) 12:47, 21 August 2010 (UTC)

Symbols in usernames a FYI

Wikipedia_talk:Username_policy#Are_symbols_as_usernames_allowable.3F Gnevin (talk) 14:44, 19 August 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)

A look at Grandchildren of Victoria and Albert with all the ancestry tables (ahnentafels) opened up (as they were at one point after a template changed) should give you an idea of why collapsing can be preferable or even necessary. See the discussion at Template talk:Ahnentafel top/Requested Comments 1. I understand the problem with over-dependence on mousing, especially right-clicking, but sometimes the alternative would be repetitively hitting keys rather than mice. However, I think that keyboard shortcuts are definitely worth investigating. —— Shakescene (talk) 08:19, 26 August 2010 (UTC)

Accessibility of the lists at the Missing Wikipedians page

Please see Wikipedia talk:Missing Wikipedians#Accessibility problem with the use of the admin bullet. Graham87 03:52, 27 August 2010 (UTC)

Rowspan and colspan, answer from an accessibility expert

Hi all. Several days ago I got the answer from an accessibility expert about this issue. The whole answer is quite long, and I'll need some time to translate it completely. Here is the summary:

There are a few precise cases where rowspan/colspan causes accessibility problems. Among other precise cases where a table has accessibility issues. I had already identified this cases before I asked the expert and he confirmed my thoughts. I will make a list of those cases on Wikipedia:WikiProject Accessibility/Manual of style draft soon. And I will provide relevant techniques to produce accessible tables.

Apart from those few cases, the use of rowspan/colspan should not be considered as an accessibility problem. No up-to-date expert resource nor the WCAG 2.0 guidelines recommend to avoid using rowspan/colspan. Fairly recent versions of screen readers (JAWS 6 - march 2005, and most used softwares) support rowspan/colspan. It's the responsibility of text-to-speech and Opera Voice producers to update their software. Our part of the job is to make sure we conform to W3C's guidelines (WCAG). W3C's guidelines have to ensure the conformed content can be used be assistive technologies. And it's the responsibility of the user agent providers to make sure they produce accessible technologies (UAAG).

Plus, the community will never agree to let got of rowspan/colspan because they are so useful for presentation. We will encourage to make simple tables (and avoiding rowspan/colspan when relevant will be a part of that). But it should not be an accessibility requirement. Because it is not an accessibility requirement. We should not create our own guidelines or else we'll just end up doing a poor job (like what happened with alt texts a few months ago). Our role is only to meet the WCAG 2.0 conformance. Perfection is the enemy of good enough. Kind regards, Dodoïste (talk) 22:48, 24 August 2010 (UTC)

Thanks. It's tricky because while colspan and rowspan can be used to make elegant but over-elaborate tables with lots of hierarchy, they're often used for the opposite purpose: to simplify tables, i.e. to present information in the easiest, most transparent way. —— Shakescene (talk) 01:03, 25 August 2010 (UTC)

Perhaps you could get your expert to comment on the issue of rowspans with text-only browsers. I've prepared a small demonstration at User:RexxS/Accessibility#Linearisation. --RexxS (talk) 01:34, 25 August 2010 (UTC)

If I'm not mistaken, table linearization only concerns layout tables. See F49: Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized.

This is a fine example. It can be used to encourage users to make simple tables. But as I said previously it should not be an accessibility requirement. If you want to have a detailed answer you can ask him yourself at fr:user talk:Lgd. His level of english is good enough (or should I say professional?). Regards, Dodoïste (talk) 01:16, 26 August 2010 (UTC)

You may well be mistaken; and F49 should not be taken as the last word on the issue. Table linearisation is just as much a concern for data tables as it is for layout tables, for exactly the same reasons. Since data tables are essentially no more than an organisational structure for the data (equivalent to a 2-dimensional list), any user agent that linearises the page content will need the table to be written in such a way that it can make sensible decisions on how it produces its output. Failure to write the table in such a format restricts the accessibility of the page for anyone using this kind of browser (user agent), whether or not F49 explicitly says so. You could argue that Lynx needs to be upgraded (in the same way that text-to-speech agents need to), but until that happens, I'm opposed to any guidance that does not encourage editors to consider the possible impact of their table designs on partially-sighted users and those who have insufficient bandwidth to use a graphical browser. To me, it is abundantly clear that it is an accessibility requirement. --RexxS (talk) 02:12, 26 August 2010 (UTC)

Hello,

Just to confirm a few things :

The use of colspan and rowspan attributes is definitely not an accessibility issue. If you want to improve Wikipedia's accessibility, please stick to Web accessibility standards and don't add extra requirements to WCAG2.0 : WCAG AA level is difficult enough to achieve
The table in Zachary Bennett is not a layout table, but a data table with only two main accessibility issues : the lack of caption element and the lack of scope attributes.
Table linearization only applies to layout tables, and never to data tables. Data tables linearization doesn't make any sense. That's why data tables must have header cells and scope (or id/headings) attributes in order to associate header cells and data.
Lynx is not the appropriate tool for testing table linearization, because it has a (minimal) table support (you can see rows and columns in your screenshot). To test linearization, you should use an appropriate tool, like the Web Developer extension for Firefox (Miscellaneous menu > linearize page). That will certainly make it easier for you to figure out what table linearization is and is not.

Regards, --Lgd (talk) 07:11, 26 August 2010 (UTC)

Maybe this will help :

Here is a nice and perfectly accessible data table (really simple, without colspan or rowspan) :

Accessibility criterias
A level	AA level	AAA level
72 criterias	28 criterias	36 criterias

This is the real table linearization, which doesn't make sense :

Accessibility criterias
A level
AA level
AAA level
72 criterias
28 criterias
36 criterias

Do you see why WCAG doesn't apply linearization criteria to data tables ? If you want data tables to be accessible when linearized, you're going to forbid the use of most data tables, even without any colspan and rowspan. Moreover, that will be wasteful for accessibility, because when this table is not visually rendered by a conforming agent (screen reader), the th elements and scope attributes are enough to make it accessible.

Regards, --Lgd (talk) 08:33, 26 August 2010 (UTC)

Many thanks for that, but I still have to disagree with over-reliance on WCAG; web designers also need to be able to structure data properly. I'm sorry to say that your example is poorly structured (even though it's a common form of presentation). There are two axes of information: level and number of criteria, which should become headers when rendered properly. Here's the rewritten table:

Accessibility criteria
Level	Number of criteria
A	72
AA	28
AAA	36

Now, you can see that each row has a unique header, and the numeric data is solely numerical. This is an important principle (as you have already stated on your user page). The table will now linearise into an understandable format (I've used web developer toolbar for a long time, but it doesn't mimic properly the display rendered in Lynx).

Accessibility criteria

Level

Number of criteria

A

72

AA

28

AAA

36

I hope you can see why linearisation is always an important consideration for any table. WCAG can only help so far, but designers still have to engage their brains. RNIB have far more experience in dealing with their members' feedback; one of the big criticisms of WCAG is that they do not seek sufficiently broad feedback from actual users. Look at how long it took them to update WCAG 1.0 to WCAG 2.0. Let me add one question - would you write the following table using rowspans? If not, why not?

Foo criteria
Level	Number of criteria
A	14
B	12
C	12
D	10

As I said before, there's no need to "hang out to dry" readers who depend on text-to-speech and text-only-browsers while they wait for technology to improve. Better, simpler design and some consideration of the impact on others is still key. Hope that helps. --RexxS (talk) 18:25, 26 August 2010 (UTC)

I know you act on good faith. And it's nice to see you are quite knowledgeable about accessibility. But don't you dare think you know better than one of the best french accessibility expert (Lgd). Plus Lgd has about 5 years of experience on the Wikimedia projects.

Your approach is seriously lacking "prioritization" and "feasibility evaluation". WCAG 2.0 do not aim at 100% accessibility. Because it's plainly impossible. Instead, it encourages the most feasible and top-priority criterions to reach a good enough level of accessibility in a fairly short time.

Your approach will never be adopted by editors because it's way too difficult to conform to. We have experience on the excessive burden that accessibility can cause on editors. So please trust us. And please don't repeat the same mistake that user:Eubulides made on WP:ALT. The risk is to have this recommendation removed from the MoS. Kind regards, Dodoïste (talk) 11:02, 27 August 2010 (UTC)

Thank you for your assumption of good faith. I believe both you and Lgd have only the best of intentions, although I have already demonstrated where you are going wrong. I'd be grateful, though, if you would stop making appeals to authority that does not exist on Wikipedia. You have no idea whom you are addressing, and my own credentials and experience outside Wikipedia are irrelevant here – just as are Lgd's.

I flatly refute your assertion that giving good, simple guidance for editors is infeasible. We have an aim that text in our best articles be presented as "brilliant prose" (see WP:FACR #1); the same high standard of presentation is no less true for tabular data. It is a fact that rowspans are never necessary, and often have a negative impact on the accessibility of the data, as I have demonstrated. Advising editors to consider these implications is the very least we can do.

I appreciate your concern about placing a burden on editors, but it is a mistake to assume that this equates to not giving the advice. Wikipedia is a collaborative project, and the shortcomings in one editor's contribution will eventually be improved by others if the goal is clear. There is no need to aim for a short time scale, as we have no deadline. By insisting that there are no accessibility issues connected to rowspan and colspan, contrary to ample evidence, you remove part of the incentive for those editors who have the technical and design skills to improve the presentation of tables.

By the way, I don't think I can overstate the massive contribution that Eubulides made to improving Wikipedians' awareness of the importance of alt text. Not every editor has the skills to create good alternative text – and that is why it remains a recommendation, not a requirement. Nevertheless no editor could object to the addition of good alt text to an image on the grounds that it isn't required, because editors are now much more aware of those accessibility issues. We want to move away from the position where editors place aesthetic considerations above improved accessibility because they are not aware. The aim for Wikipedia is 100% accessibility. If you are satisfied with less, that's your choice, but please don't obstruct those who want to aim higher. We know improvements don't happen overnight, but they do happen eventually. --RexxS (talk) 14:28, 27 August 2010 (UTC)

The problem is that WP:ACCESS is part of the Manual of Style. The intention for that change was a good one- to give ACCESS more clout. Unfortunately that's a double-edged sword. Given that anything that goes on here is as near as makes no difference manditory, the burden is on editors here to persuade the wider community that the effort is proportionate to the benefit. My opinion is that WP:ACCESS needs to be split into two pages- a policy, for things which should be considered non-negotiable, and a non-MoS guideline, for things that we should always try to do, but in some instances simply aren't feasible with the current limitations of the software. --W F C-- 14:47, 27 August 2010 (UTC)

It's worth regularly reminding other editors that, contrary to popular belief, MOS is a guideline, not policy (and for good reasons). However, I agree that MOS is often treated as mandatory, and I support all attempts to give ACCESS more clout. It is clear to me that the underlying principles of ACCESS should be policy without reservation. If this is the encyclopedia that anyone can edit, it had better be the encyclopedia that anyone can read as well. In fact WP:5P needs to be WP:6P, and recognise that. I do agree that the details of the implementation of policy are best set as guidelines, so a separate page may be the answer. --RexxS (talk) 15:31, 27 August 2010 (UTC)

"A separate page may be the answer": that's actually what I had in mind all along. Many thanks to WCF for making it clearer. :-) That's what I had in mind when I wrote the first post of the section: "We will encourage to make simple tables (and avoiding rowspan/colspan when relevant will be a part of that). But it should not be an accessibility requirement." First we need a detailed tutorial on a dedicated page explaning how to produce accessible tables. The top of this page will contain accessibility requirements that are top-priority and simple to do. The rest of the page will be advanced techniques or "bonus guidelines". Basically, "bonus guidelines" are recommendations that do improve accessibility but are no priority and/or difficult to apply (for example, difficult to have the editors accept the change).

I hope this solves the controversy. If it does, I will begin to work on this "accessible tables tutorial" next week or so.

Not relying on a person's supposed expertise or background (which is impossible to verify) is fine when we rely on references. We don't need to rely on a user's authority because we have verifiable sources from experts that provides all the information we need. But is it the case here? So far I'm the only one who is backing up his assertions with references. I was one of the first users to insert references from WCAG 2.0 in this guideline. Most of the current references were inserted by me. And I'm the only one who is trying to provide references during discussions.

A while ago I showed you F49 about layout table linearization. You replied that I was half wrong without providing references. An accessibility expert confirmed what I said and provided details. And you kept on disagreeing. I don't bear the slightest grudge towards it or anything. However, if we are to work together – I sincerely hope we will achieve that – we need a way to get to agree on something. Yours, Dodoïste (talk) 22:41, 27 August 2010 (UTC)

That sounds like a good way forward, Dodoïste, and I'm keep to help any way I can. We're not going to agree on every point, but I respect your commitment and enthusiasm. Did you notice the reference I provided from the Royal National Institute of Blind People RNIB, (accessibility guidelines)? It's rather easier to read than WCAG, and although it is less up to date than WCAG 2.0, it represents an approach derived from their experience with users, and it does specifically refer to Lynx as an example of a text browser. It's true, of course, that as broadband coverage increases globally, a smaller proportion of readers will be viewing with text browsers, but we're still a long way from being able to assume text browsers can be ignored.

I suggested that F49 was "not the last word" on table linearisation, and provided an example. Let me be clearer then, the problem I have with your reliance on F49 is that F49 does not address data tables at all. The fact that F49 (Failure of Success Criterion 1.3.2 due to using an HTML layout table that does not make sense when linearized) does not mention data tables does not mean we can ignore them. If you want WCAG references, look at SC 1.3.2: "1.3.2 Meaningful Sequence: When the sequence in which content is presented affects its meaning, a correct reading sequence can be programmatically determined", which applies to all content, including data tables. You can also refer to the definition of "linearized table" in WCAG 1.0: "A table rendering process where the contents of the cells become a series of paragraphs (e.g., down the page) one after another. The paragraphs will occur in the same order as the cells are defined in the document source. Cells should make sense when read in order and should include structural elements (that create paragraphs, headers, lists, etc.) so the page makes sense after linearization". Having also provided you with examples of problems with data tables when linearised, I think I'm well within my rights to disagree with both your opinions that linearisation of data tables has no accessibility implications, since the only evidence you put forward is that F49 only applies to layout tables. As I said, I'm happy to work with you to improve Wikipedia, but I doubt that I'll agree that WCAG 2.0 is the sole repository of all wisdom on accessibility, when it is clear from practical example and common experience that there are areas that it does not cover adequately. --RexxS (talk) 01:42, 28 August 2010 (UTC)

So I'll make this table tutorial then. :-)

I found several guidelines easier to read than WCAG 2.0 (that was the main concern when WCAG 2.0 was released) but none of them were up-to-date. WebAIM's WCAG 2.0 Checklist is basically the WCAG 2.0 made easy to read.

I had a quick look at RNIB's guidelines. Lgd told me the RNIB does not promote nor use any criterion that isn't part of WCAG. Basically, they didn't add any criterion in their guideline. The RNIB doesn't invalidate – in their audits criterions – any use of colspan / rowspan nor any linearization issue of data tables.

Those quotations from the guidelines are not enough of a proof. If data tables need to linearize correctly it would have been stated clearly. SC 1.3.2 is high-level and data tables may be the only case where it doesn't apply. It is not stated anywhere that the definition of "linearized table" is related to data tables. In fact, no up-to-date accessibility guideline say anything about data tables linearization. No references, no chocapics! ;-)

But if you still insist, go ahead and try. I've just improved Usage share of web browsers and made the tables conformed to the WCAG 2.0 requirements. What will you do to make them linear?

I was not able to find any mail related to our discussion in the public mailing list. Could you show me directly which mails you are thinking about? Yours, Dodoïste (talk) 21:36, 28 August 2010 (UTC)

A table tutorial would be very helpful.

RNIB's "WAC See It Right Standards" gives background information and guidance on their audit process. Although RNIB is an active member of W3C, it has different emphases from WCAG (and produces more accessible documentation!). An obvious example of a criterion removed in WCAG 2.0 is RNIB's "14.1: Use the clearest and simplest language appropriate for a site's content" which it inherits from WCAG 1.0. You'll find that WCAG 2.0 has replaced it with G3.1 (in particular G3.1.5 which ironically breaks its own guideline). I know of no web designer who has found that an improvement. Wikipedia has WP:JARGON which serves the same end. Since RNIB specifically names Lynx as a text browser that it uses for testing (WAC See It Right Standards, p.8), pages which fail on Lynx fail RNIB audit. I've already demonstrated that rowspans are not distinguished from empty cells in Lynx, resulting in loss of information where both are present in the same column. Linearisation of the data table produces the same result, but may be easier to test for. Either way, my demo table fails RNIB, and you need to recognise that even if a particular problem isn't listed in WCAG 2.0, it can still exist. SC 1.3.2 applies throughout and you're not entitled to guess that data tables are an exception, when there's no evidence of that. The problem is that I show you an example of a data table that fails to provide all its information when rendered via a low-bandwidth browser, and you say "It can't be an accessibility issue because WCAG 2.0 doesn't specifically say it is". I don't need references to tell me how to think, as I can recognise a problem when I see one. I guess we'll just have to agree to disagree on that.

Now, there's a lot of improvement available for the tables in Usage share of web browsers, and although little of it breaks accessibility, much of it will be poorly presented for those using AT, low-bandwidth connections or low-resolution screens. As an example, take the "Global usage share data" table. The use of inside the cells to attempt to force a visual effect is wholly inappropriate and a nuisance for anyone using a screen reader. The explicit repetition of the header at the end is a bad idea (in HTML, the THEAD|TBODY|TFOOT elements are available for long tables), because it annoyingly repeats that row on a screen reader. If you want to have a table that linearises properly, you need to put a value in each cell, so the "Chrome" column should contain something like "N/A" if the data is not available. If you don't care about linearisation, then don't bother – it is rendered fine on Lynx (but try looking at it on a mobile phone browser if you want to see an example of the problem). Pretty much the same applies to the other tables. I'll also add that "style=text-align:right" is more or less useless when you have differing number of decimal places in the data (proportional fonts don't help either). Keep the number of decimal places consistent and wait for CSS3 when you will be able to have "style=text-align:'.'" to align at the decimal points. At present it's also just one more hard-coded style to find and check when the page is translated between left-to-right and right-to-left languages.

I apologise; I wasn't clear enough before. I didn't mail anything. I put all the examples and references at User:RexxS/Accessibility. Please let me know if there's anything you can't find there. --RexxS (talk) 00:01, 29 August 2010 (UTC)

I've reverted your removal of the guidance and explanation from Data tables. The changes result in advice that has no rationale and requires the user to look elsewhere for its requirements. That does not make it clearer. In addition, it is disruptive to implement changes while they are under discussion. I don't agree that there's agreement to remove cautionary advice on the use of row/col spans. It is undeniably true that they can cause problems, and editors need to be aware of it. --RexxS (talk) 00:24, 29 August 2010 (UTC)

No. It's the recommendation against rowspans / colspans that is debated. Until we reach consensus it shall be removed. In the meantime I placed [citation needed] on those paragraphs. If you still disagree on that, disagree elsewhere. I'm pissed off. :( Dodoïste (talk) 00:45, 29 August 2010 (UTC)

I understand English may not be your first language, but at present there is no recommendation against rowspans/colspans on the page. There is only a description of the potential for problems. I've showed you that there exist such problems, which disadvantage certain classes of user, and I've attempted to suggest ways to solve them. I'm much more interested in updating the guidance to make it more usable, than in removing useful commentary. I have no interest in reducing the page to a cut-down summary of WCAG 2.0. That is already adequately referenced in the page and viewers should be encouraged to read it. And the way we work here is WP:BRD. You make a bold edit and I revert it; that is where it sits while it is discussed. Now, if you want to learn how to work the Wikipedia way, you'd best strike that nonsense "Until we reach consensus it shall be removed", as that will be construed as a declaration of your intention to force through your change by edit-warring. I'd strongly recommend you read those two pages, as you may not be familiar with their concepts. I'm ready to discuss calmly what you want to change, whenever you're willing to do so without threatening to edit war. --RexxS (talk) 01:13, 29 August 2010 (UTC)

We also have the "3RR" on the french Wikipedia. I know. I won't make an edit war.

Sight. Just relax for a few days and stop posting here. I'll make this tutorial quietly. We'll resume this discussion afterwards. That's the only solution since we don't understand each other. Dodoïste (talk) 01:40, 29 August 2010 (UTC)

Images or colors inside a table

The edit to "Images or colors inside a table" makes the guidance clearer and more useful. Can I just point out that WP:Manual of Style (accessibility)#Images recommends the use of image captions. Do we want to imply that captions should be used for images in tables? If not, it might be worth noting that as an exception. HTH. --RexxS (talk) 02:10, 29 August 2010 (UTC)

I finally did something right! :-) WP:Manual of Style (accessibility)#Images is right to be high-level and summarize the guideline. Thumbnails are the most common cases in articles. But in data tables images a generally decorative images. The relevant informations are in Wikipedia:Alternative text for images. Anyway, this case is quite complicated. I will provide details on this issue in the tutorial. Dodoïste (talk) 11:49, 29 August 2010 (UTC)

Images with links

Template:Conservation status, has an image with links on it . These disappear if I tell my browser not to display images. Can a screen reader handle this or does this need looking at Gnevin (talk) 15:23, 26 August 2010 (UTC)

This one is a good use of the imagemap extension. It is accessible. We should make detailed guidelines about it. Like a tutorial on how to make accessible imagemaps. But it need to be in aother page than the MOS. If I understand correctly, MOS re editorial guidelines. But lots of accessibility requirements rather concerns templates and MediaWiki software. I don't have the time just yet, but it's definitely on my to-do list. :-) Dodoïste (talk) 16:39, 26 August 2010 (UTC)

But shouldn't users using text only browsers seen the links too? Gnevin (talk) 20:27, 27 August 2010 (UTC)

Semantically speaking, there is everything needed in the code of Template:Conservation status to be accessible. Afterwards, if Lynx decides to support the area tag is none of our concern. It's their job, we can't do a thing about it. Dodoïste (talk) 21:04, 27 August 2010 (UTC)

@Gnevin: Yes, all users should be able to access the links, even with images turned off. The older WCAG 1.0 Checkpoint 1.5 is specific:

"Until user agents render text equivalents for client-side image map links, provide redundant text links for each active region of a client-side image map"

Since each of the links in the image map has an equivalent link in the cells above it, it has become accessible in that context. This is good practice.

My only criticism of the image map is that the image has "Status iucn3.1.svg" as its alt text. Not exactly what one would hope for.

@Dodoïste: We cannot afford to ignore current text-only browsers. That makes it our concern. Please see Guideline 2.1 Keyboard Accessible: Make all functionality available from a keyboard]. The fact that redundant links are already provided proves that there are measures we can take. --RexxS (talk) 22:15, 27 August 2010 (UTC)

WCAG 1.0 is outdated as you already know. If you know of a corresponding criterion in WCAG 2.0 we will follow it. If there is no corresponding criterion in WCAG 2.0 I would advice not to follow the WCAG 1.0 criterion.

The alt text issue was trivial to fix. Except that in the source code produced by MediaWiki the image tag with the alt text is placed after the area tags. This is suboptimal. Software issues, software issues again... When will the Wikimedia Foundation employ an accessibility expert to fix their soup tag?

Hmm... I'm quite surprised to see that those links created by the area tag are not keyboard accessible (tested only with Safari, other user agents may behave differently). I said this template is accessible because Lgd said those uses were correct. But maybe it's not fully accessible and it's simply the best we can currently achieve. I'd be best to get some details about it. Dodoïste (talk) 23:35, 27 August 2010 (UTC)

Thanks for fixing that alt text – agreed about the crappy placement. A lot of people were disappointed that WCAG 2.0 failed to specifically mention redundant text for image map, but WCAG were trying to remain up-to-date longer by being more technology neutral (and to be fair, modern screen readers will find the links associated with area). Even if WCAG 1.0 is now outdated, us old-timers can still recognise where it's useful, and in this case redundant links solve Gnevin's problem. My advice: don't dismiss WCAG 1.0 lightly; if the techniques there can solve a problem that WCAG 2.0 doesn't address, don't be afraid to use those techniques. Regards --RexxS (talk) 02:27, 28 August 2010 (UTC)

I've just tested with IE 8, Firefox 3.5 and Safari 5 (I updated from Safari 4). They all have keyboard support for Template:Conservation status. Safari 4 did not support it, but it's now outdated and will soon be almost unused. I did not test with Chrome (but since it's Webkit it should be fine) nor Opera. Anyway, the two major browsers have keyboard support for those imagemaps. And you admitted yourself that major assistive technologies support imagemaps as well. It's the responsibility of the users agents to have keyboard support for imagemaps.

It is now very clear that WCAG 2.0 doesn't address redundant text for imagemaps because there is no need for it anymore. Major user agents support it. Other just have to keep up with them: they are not to hold the web back like IE6 does (that's an extreme example but you understand the point ;-)).

Accessibility-wise there is no need to encourage redundant links anymore. Now usability-wise it's another story. Most imagemaps are not intuitive at all. Depending on the situations redundant links could improve usability.

Oh, and to answer Gnevin's first question. I could not reproduce your bug. What browser did you use? With Safari 5 if I disable images the links remain.

Yours, Dodoïste (talk) 18:48, 28 August 2010 (UTC)

Firefox 3.6.8 with images turned off (via Web developer toolbar or via options/content/load images automatically) doesn't display any links for the image map, on both Windows and Ubuntu, (nor does Lynx nor IE6). IE8 8.0.6 with "Internet Options/Show pictures" turned off has the links available from keyboard as does Opera 10.61. Frankly, I would not be comfortable disadvantaging such a substantial proportion of low-bandwidth users. At present redundant links are easy and solve the problem, so must be recommended. It is not acceptable to insist users change their preferred browser when a simple solution is available. In addition, many users (both corporate and in public locations) are "locked in" to a particular browser by windows policy (see W3 Schools for an example of browser usage). When all common user agents provide links for image maps, then WCAG 2.0 will be adequate. Until then, old-fashioned redundancy is still necessary. --RexxS (talk) 22:24, 28 August 2010 (UTC)

I never said users should change their preferred browser. I said user agents that doesn't have keyboard support for imagemaps should be improved. And that is all. I'm well aware of browsers usages and I've just spend several hours improving usage share of web browsers. W3schools stats are representative of browsers usage among geeks / developers only. I also said there is nothing wrong with those redundant links. It can be a bonus or something. But unless you find an up-to-date accessibility guideline which recommends to provide redundant links we won't recommend it either.

We are no accessibility experts and aren't able to make guidelines ourselves. Sight. For simplicity's sake we should blindly follow a published and up-to-date accessibility guideline. If we need to have lengthy discussions like that every day we will spend years over tiny annoying details. We have lots of other priorities than making endless debates, testing supports in users agents and all. Experts already do all the job for us. We just need to make a decent manual of style out of the current extremely lacking draft we have. Why not go for the endless debates afterwards. Yours, Dodoïste (talk) 23:59, 28 August 2010 (UTC)

If user agents have not yet been improved, yet you refuse to accept that their users should be considered, how else is anyone to interpret it? Each website's stats are naturally only representative of their audience, but I pointed you to W3Schools because they show the proportion of their viewers who still use outdated browsers like IE6. If over 7% of "geeks/developers" are using IE6 to view W3S, how many more viewers are using it to view Wikipedia?

We don't need to be accessibility experts to make our own guidelines. No matter how much you blind faith you put in an external guideline, it cannot substitute for the process we have developed on Wikipedia. Discuss the issues and make your case. Show me how anyone using text-to-speech can understand the first table in User:RexxS/Accessibility. Explain how a Lynx user can get the information from the second table there. Tell me why we should allow either of those tables to become garbled when viewed on a mobile phone browser. Find me an real expert who will justify disadvantaging numerous viewers simply on the grounds that WCAG 2.0 fails to specifically mention the issue. I'm deeply disappointed that you only seem interested in attempting to remove advice from the guidelines, when we can all agree on many things that ought to be added. --RexxS (talk) 00:49, 29 August 2010 (UTC)

<cynical>Don't worry. I've just added content: "citation needed".</cynical>

You know, if I hadn't to spend most of my time discussing with you I would have finished my tutorial a long ago. Conclusion: I'll stop wasting my time in endless debates. If you continue to provide your own confused advices here and there I'll just answer "citation needed". Simple enough. Dodoïste (talk) 01:12, 29 August 2010 (UTC)

I want to make sure that I understand the problem:

If a person has turned off images in (at least some) regular, reasonably common, reasonably modern browsers -- say, because the person has photosensitive epilepsy, and a 'bad' image could result in a potentially fatal seizure -- then this person is currently unable to click on the links to Extinct in the Wild, Endangered species, etc., in the round dots at the bottom of the template? Do I correctly understand the problem report? WhatamIdoing (talk) 00:27, 29 August 2010 (UTC)

No. This is a Firefox-specific bug. And it's a browser bug. I mean, Firefox is at fault here, not us. Dodoïste (talk) 00:34, 29 August 2010 (UTC)

Many viewers turn off images because they don't live in a country where cheap, high-bandwidth connections are available. That's most of the world. If we are aware of a problem/bug that exists in Firefox or Lynx or IE6 and don't do anything about it, then it becomes our fault. --RexxS (talk) 00:53, 29 August 2010 (UTC)

The two first sentences are correct. The third needs a citation. ;-) Dodoïste (talk) 01:12, 29 August 2010 (UTC)

So the problem statement becomes, "If a person using Firefox has turned off images -- say, because the person has photosensitive epilepsy, and a 'bad' image could result in a potentially fatal seizure -- then this person is currently unable to click on the links to Extinct in the Wild, Endangered species, etc., in the round dots at the bottom of the template." Is that correct? WhatamIdoing (talk) 04:42, 29 August 2010 (UTC)

Yes, precisely. :-) Dodoïste (talk) 11:51, 29 August 2010 (UTC)

I don't get the links in IE8 or Firefox Gnevin (talk) 09:39, 31 August 2010 (UTC)

Question regarding timeline

An editor created a timeline of the list of Red Hot Chili Peppers band members using a png file, and added it to the featured list. There was originally a timeline like this, but I had to remove it, since a featured list must meet all of the criteria, including WP:ACCESS. I'm not sure if this png file passes WP:ACCESS, and I'm not exactly sure how to check. Any information or confirmation is much appreciated. Thank you! WereWolf (talk) 04:22, 5 September 2010 (UTC)

The usage of the image doesn't meet WP:ACCESS since it has no alternative text which would explain its purpose to anyone who can't see the image. In addition, a good piece of general advice is never to use an image to convey information that can be conveyed equally well by text. Having said that, it could be argued that the information in the image is already present in the text of the article, so anyone reading the article without images still has the information presented to them elsewhere.

My initial view is that the image only provides an overall summary of that information, which is a bonus, but unfortunately presents it in such a way that it is inaccessible for those who cannot see the image. Whether or not that is an appropriate use of 155 kB of article content is probably best left as something to discuss on the list article talk page. I'll see if I can add some simple alternative text to give screen readers a basic idea of what's there. --RexxS (talk) 06:41, 5 September 2010 (UTC)

That's right RexxS. :-) We can hardly do anything better because of MediaWiki's limitations. So an alt text will do for now. More importantly, we should not remove images because they can't become fully accessible for now. Or else edidors might begin to hate accessibility or decide to ignore it. It would be unproductive on the long run. ;-) Dodoïste (talk) 08:11, 5 September 2010 (UTC)

Thank you for your help. I will try to contact the user who created the timeline and see if there is a compromise we can meet. I appreciate it! WereWolf (talk) 14:41, 5 September 2010 (UTC)

I've also commented at the talk page on the filesize, which is only an accessibility issue for those on low-bandwidth connections. Reducing the colour depth provides a big improvement (155 kB -> 32 kB), so may make the image more acceptable. HTH --RexxS (talk) 17:00, 5 September 2010 (UTC)

Having owned and used Microsoft Excel 2000 for a decade, I can easily recognize that this image is of a relatively simple Excel spreadsheet, using basic Excel color choices. Although the pointers to different songs or albums appear to indicate very specific points in time, they in fact seem to be just to whole years in the column headers. There are several free Wikimedia-user-created programmes (e.g. http://excel2wiki.net/) that convert Excel spreadsheets to Wikitables. What I'm wondering, as a complete ignoramus in both accessibility and software coding, is would converting the spreadsheet to wikitables (1) require fewer kilobytes of code and (2) be more easily readable on an accessibility device? (for all of its refinements, this table doesn't seem to use much colspan or rowspan.) —— Shakescene (talk) 18:05, 5 September 2010 (UTC)

Converting into a table is a very good idea (both accessibility-wise and bandwidth-wise). And it is feasible, although it may be a bit tricky. I'll provide an example soon. Regards, Dodoïste (talk) 21:16, 5 September 2010 (UTC)

I suspected that it was Excel, and agree with Dodoïste that a table would be much better for all sorts of reasons. It would need a little reorganisation because many of the cells carry their information purely by colour. My inclination would be to fill them in with 'B', 'G', 'V', 'D' (for "Bass", "Guitar", "Vocals", "Drums") for each quarter where the member was part of the band - and then remove the column "Primary Instrument", which would make the table more compact. I'd also prefer to see an annotation (e.g. "*") or linked group ref (appearing as ^[nb1]) to indicate current members. Taken together, that would remove the dependence on colour. Have a think about it if anyone is intending to create a table. --RexxS (talk) 21:34, 5 September 2010 (UTC)

I'm not sure how accessible they are, but infographics like this are usually best turned into imagemaps. See Wikipedia:Picture tutorial#Image maps. -- Quiddity (talk) 21:40, 5 September 2010 (UTC)

The example in the picture tutorial is accessible (except for a few browsers bugs but it's arguably not our fault). Now using this technique to make a meaningful table... If even possible, I bet it would be really tricky and fragile. Imagemaps are not meant to produce tables, so I'd rather encourage a table solution. Yours, Dodoïste (talk) 22:10, 5 September 2010 (UTC)

(edit conflict) Image maps with proper alt text will be accessible for visually-impaired readers who use screen readers, and many modern browsers will supply that text even when images are switched off, but they do present some problems with a few modern browsers and many older browsers. If we also consider the accessibility needs for readers on low-bandwidth connections, then image maps don't do well, particularly on text-only browsers such as Lynx. Overall, a well-implemented table will always be the solution that goes furthest to meeting present accessibility concerns. --RexxS (talk) 22:20, 5 September 2010 (UTC)

[edit conflict] I think it would be far easier to work with the table's creator, User:Sir Edward V, who seems at first glance to be an eager new user studying computer science (see User talk:Sir Edward V), and with the Excel spreadsheet from which he made the timeline. Among many other considerations, I'm sure the timelines that start before or after the end of a year were generated by Excel from underlying dates, which would be quicker and surer sources than eyeballing an approximation from the graphic image. Perhaps a suitable adaptation of the Excel's code ("View Source") could serve as the alt-text. —— Shakescene (talk) 22:29, 5 September 2010 (UTC)

Yes, the precise dates are needed in order to convert into a table. Regards, Dodoïste (talk) 00:10, 8 September 2010 (UTC)

I didn't feel like dealing with the semantics of getting precise dates for everything, hence my choosing to deal with quarters. I did find the dates in the wiki article, then made changes by quarter and forgot about the exact date. Everyone is right, it was done in excel. I considered making it with wikitables, but I'm not terribly familiar with the syntax on here, so Excel seemed more appealing. I can find a way to upload the xlsx file so others can have a hand at improving it. I don't come on here frequently enough to really support making changes. Hooray, open-source! Nathan (talk) 06:02, 14 September 2010 (UTC)

Just a question. Would we need to include the former touring musicians to the timeline, as well? WereWolf (talk) 15:26, 6 September 2010 (UTC)

I personally didn't think they were important enough to the point I wanted to make with the graph. I was interested in who the full members of the band were for the different albums, and thought others would like to see it too. Nathan (talk) 06:02, 14 September 2010 (UTC)

xls nor xlsx are supported filetypes in wikimedia commons... If you point me to a tool to convert the excel spreadsheets to a wiki table or any of the other things mentioned, I'll take a look at converting it. Nathan (talk) 06:27, 14 September 2010 (UTC)

Accessibility table tutorial is coming

Hi. As promised most important parts of the table tutorial are now complete: Wikipedia:WikiProject Accessibility/Manual of Style draft/Data tables tutorial. Firsts comments and feedback are welcomed. As I am not a native speaker copyedit in sections marked as complete is welcomed too. ;-) Regards, Dodoïste (talk) 01:55, 10 September 2010 (UTC)

Thanks Graham87! :-) It's very useful to see the corrections you make. You guys are my new english teachers. :-) Dodoïste (talk) 13:07, 10 September 2010 (UTC)

Half of the tutorial has been reviewed by an accessibility expert and I made most of the corrections already. Which means this tutorial has reached its final form. Now is the time to comment its content. If you disagree on something or don't understand a guideline, please do tell about it on the tutorial talk page. Wikipedia:WikiProject Accessibility/Manual of Style draft/Data tables tutorial. Kind regards, Dodoïste (talk) 20:31, 26 September 2010 (UTC)

Since nobody replied I just made the changes. Dodoïste (talk) 16:58, 27 September 2010 (UTC)

How to make this list accessible?

Hi! I am new to WP:ACCESS and am trying to figure out how to make List_of_National_Treasures_of_Japan_(crafts:_swords) more accessible. Two issues have been raised in the (active) featured list candidacy:

The use of colors in tables (quote: "Be aware of WP:ACCESS when you say that some swords are noted in yellow or green")
The use of color in this map (quote: "Can you just check that saying "marked in red" in a map also meets WP:ACCESS?").

As for "2.", I added alt text to the image. Is this sufficient or do I need to change the map itself? As for "1.", I have no idea how to make it more accessible. I am therefore looking for some help from an accessibility export. Thanks in advance. bamse (talk) 20:07, 17 September 2010 (UTC)

I'm not an expert, but I've commented at WP:Featured list candidates/List of National Treasures of Japan (crafts: swords)/archive1. Nevertheless, other editors may be able to suggest further improvement, and I'd encourage the regulars here to take a look. --RexxS (talk) 21:50, 17 September 2010 (UTC)

Thanks a lot for your feedback! Much appreciated. bamse (talk) 22:18, 17 September 2010 (UTC)

Colored map accessibility cleanup

If anyone's an old hand at SVG maps and has some time to kill, please see Talk:Sexually transmitted disease#xs. — SMcCandlish Talk⇒ ʕ(^Õل^ō)ˀ Contribs. 05:01, 9 October 2010 (UTC)

I just added advice for geographical maps to this guideline. Dodoïste (talk) 12:19, 9 October 2010 (UTC)

Transparent backgrounds

Why do images use a transparent background ? So that they merge into the surroundings on any page, no matter what color the page is using? But images themselves have colors in them, so images with transparent backgrounds cannot be used on pages that are colored with the any of the colors that the image itself uses. Take for example the image File:World-Population-1800-2100.png, which is a graph that uses 5 colors, which means the image is not viewable if the webpage uses any of these colors.

Images with transparent backgrounds can only be used on pages where you know the page color is compatible with the image, but if you know what page color is going to be used then why does the image use a transparent background in the first place ?

On the other hand if you don't know what color the page is going to be then you won't know that the page color will be compatible with the image, so why does the image use a transparent background? Either way, whether you do or don't know what the page color will be, it doesn't make sense to use transparent backgrounds in images.

Webpage color is not determined by the website. Browsers and operating systems can and do override the page settings for accessibility reasons, e.g. making pages white text on a black background. It is a fundamental feature of the markup language HTML that webpages should be readable on any platform and not assume the website is in control of the presentation.

Putting transparent backgrounds on images mixes the content of the image with the style of the webpage rendering many images unviewable depending on browser and operating system settings, particularly if the OS is set to high-contast black and white then black equations, graphs, charts and diagrams on a transparent background are invisible. User:Blackbackground

I moved your section here, because it is written as a debate/discussion rather than a guidance. And while the point about transparent backgrounds seems sensible, it is not part of any accessibility guideline I know. And I'm not sure its priority is high enough to dedicate a lengthy section about it. It would be worth mentioning at the general requirements for images, though. Let's refine this idea, I hope some regulars here will comment. :-) Yours, Dodoïste (talk) 20:17, 16 November 2010 (UTC)

Overlinking

In data tables which are sortable, we link everything that's linkable on every instance. This guideline makes it clear that that approach is unacceptable, to whit:

Do not overlink. Screen readers put each link on its own line.

Are sortable data tables exempt from this part of WP:ACCESS? The Rambling Man (talk) 19:17, 2 January 2011 (UTC)

Can you give me an example? I've never had any trouble with overlinking in sortable data tables. When I wrote that sentence, I basically meant "Here's one more reason not to overlink". Graham87 03:38, 3 January 2011 (UTC)

Well, any recently promoted FL with a sortable table will have the traditional "overlinking" issue, e.g. List of National Basketball Association season steals leaders links team names every line. This is, obviously, because the table is sortable and therefore the data could be presented in any order, so there's no guarantee that linking just the first occurrence is adequate as it may not appear first after a re--sort. The Rambling Man (talk) 10:28, 3 January 2011 (UTC)

That's not a problem because JAWS and other screen readers put each table cell on its own line, so adding a link doesn't change the flow of the text. Graham87 14:18, 3 January 2011 (UTC)

Okay, so can we say that overlinking in sortable data tables is just fine then rather than simply "do not overlink."? The Rambling Man (talk) 15:57, 3 January 2011 (UTC)

Yes. Graham87 02:46, 4 January 2011 (UTC)

Thanks The Rambling Man for the cleanup you have done in this Manual of Style (accessibility), it is much appreciated. :-)

The guideline "do not overlink [...]" has nothing to do with accessibility, so I've bluntly removed it. I understand that a collection of links in a sentence makes it tedious for a screen reader user to read the sentence. And overlinking happens often on Wikipedia. But overlinking is not an accessibility criteria in any accessibility methodology. And the problems that overlinking causes to blind users are on pair with the problems overlinking causes on "normal" users. Overlinking is reather a usability issue that would be worth mentioning at Wikipedia:WikiProject Usability/Readability guidelines.

In short, overlinking is evil. But it has nothing to do with accessibility specifically, so I removed it from this page. Yours, Dodoïste (talk) 21:00, 15 January 2011 (UTC)

Guidance on italic text

At present, we have the following guidance at the section WP:Manual of Style (accessibility)#Color on alternative methods of providing information conveyed by colour:

"Ensure that color is not the only way used to convey important information. Especially, do not use colored text unless its status is also indicated using another method such as italic emphasis or footnote labels. Otherwise, blind users or readers accessing Wikipedia through a printout or device without a color screen will not receive that information."

But in the section WP:Manual of Style (accessibility)#Text, we advise:

"... By default, most screen readers do not indicate presentational text attributes (bold, italic, underline) or even semantic text attributes (emphasis, importance, text deletion) ..."

So, while I appreciate the fact that italic text may substitute for colour for colour-blind viewers, it seems to be unsuitable as a substitute for blind viewers (under default screen reader settings).

The context in which I'm considering this is when a table uses colour as a key in a legend, and the editor has chosen to employ italic text as the accessible alternative (see e.g. Philadelphia Phillies all-time roster (C)). At least one very experienced editor has found this apparent contradiction to be confusing and unhelpful (see User talk:The Rambling Man#MOS guidance), and I'd appreciate any thoughts on how we should be presenting guidance on alternative methods of providing information conveyed by colour. Specifically, I think the guidance on using italic text needs to be removed. --RexxS (talk) 17:47, 3 January 2011 (UTC)

If italic text is used in a table, they're should be some explanatory text saying "these items are in italics" or whatever, then screen reader users would know to search for the italic text, or tell the screen reader to announce formatting changes. Screen readers can also identify the colour of a particular piece of text as well. I don't have much time to work on this right now, and I'll be away until Friday. Graham87 02:50, 4 January 2011 (UTC)

Without extra information to alert a screen reader, I think italic text is a poor choice for providing an alternative to colour, so I've amended the guidance to recommend an accessible symbol with matching legend. --RexxS (talk) 22:19, 15 January 2011 (UTC)

Thanks. :-) Dodoïste (talk) 22:40, 15 January 2011 (UTC)

Section headers and links

At WP:Manual of Style (accessibility)#Links we currently have this guidance:

"Avoid putting links in section headings. Some screen readers, such as versions of JAWS prior to 7.1, have significant difficulty correctly rendering such headers."

I believe this is no longer an accessibility issue, and should be removed. Originally there was a software problem in making anchors containing links, but the developers resolved that some time ago, and there is now this guidance at Help:Section#Section linking:

"An internal link in a section heading does not give complications in terms of section linking."

Since JAWS 7.1 is now over four years old, the only objection to links within section headers appears to be the inconvenience of having a screen reader precede each link by a newline. That is clearly a usability issue, not an accessibility one. Removing this outdated restriction would allow richer and neater organisation of sections within an article, avoiding multiple uses of {{see}} and {{further}} by replacing many of those with direct links within the section headers. See List of birds of Pennsylvania where a template creates the links to good effect, although I'd be cautious about having large numbers of links within a section header, because of the nuisance value to screen readers. I checked with a regular editor who uses JAWS and his reply confirms my observations. --RexxS (talk) 22:39, 15 January 2011 (UTC)

I fully agree. I also thought about removing this guidance long ago, but somehow forgot to do it. Thanks for bringing this up. Dodoïste (talk) 22:53, 15 January 2011 (UTC)

OK, I've removed that item. I'd think the item that says "Use as little code as possible ..." should be removed as well, since it's not an accessibility issue either. Graham87 02:24, 16 January 2011 (UTC)

Done. Graham87 02:28, 16 January 2011 (UTC)

Small fonts

These are back again for reflists, despite ".references-small { font-size: 100%; }". And since most readers of WP don't have accounts, even if botching the CSS was a good solution, it is only for a few. Rich Farmbrough, 12:05, 23 December 2010 (UTC).

See MediaWiki talk:Common.css#Regarding references. Users decided to change it. Now you need to add to your User:Rich Farmbrough/monobook.css:

div.references {
    font-size: 100% !important;
}

It should work, let me know if it doesn't. Yours, Dodoïste (talk) 10:29, 16 January 2011 (UTC)

Thanks. I still can't see why we are doing this. Rich Farmbrough, 12:44, 16th day of January in the year 2011 (UTC).

Good question. I'd be interested to know why it was added to this MoS. This advice is supposed to improve readability, and has nothing to do with accessibility. I moved it to a page about readability, which I suppose is more appropriate.

As you can see in the following sections of this talk page, we are doing some much needed cleanup to this guideline. As of now, I still see 2 advices that are not strictly related to accessibility: the section about screen resolution, and the paragraph about striketrough in articles. We'll complete this cleanup sooner or later. We already did several changes in two days, and those last two might be trickier than the rest. Kind regards, Dodoïste (talk) 19:54, 16 January 2011 (UTC)

Text - spelling errors

Spelling errors should be fixed anyway, and editors do make theses corrections spontaneously every day. I feel the following requirement is not needed, and could be removed.

Spelling errors, such as "initative" instead of "initiative", can dramatically affect the sound of the text when it is read by a speech synthesizer, which can make it more difficult to read.

Any objections? Regards, Dodoïste (talk) 11:46, 16 January 2011 (UTC)

No objections from me. See my previous musings on the topic. Graham87 13:09, 16 January 2011 (UTC)

Great! :-) It's done. Dodoïste (talk) 19:44, 16 January 2011 (UTC)

Not directly related but I do think this re-visit of MOS (access) is a really good thing for us all. I hope to keep advocating ACCESS at WP:FLC and clear, unambiguous instruction is the only way forward. I appreciate the ongoing efforts to make it more accurate, more relevant, and I also appreciate my (possibly naive) comments being given consideration. The Rambling Man (talk) 20:09, 16 January 2011 (UTC)

Tables section - a link

In the tables section there's a link to Wikipedia:WikiProject Accessibility/Infobox accessibility. I checked the link out, but that very page says, as an intro:

"this page has been inactive for years and is believed to be outdated. It is kept as an archive and as an example of template accessibility improvement."

Either (a) the MOS needs to stop referring to a page which introduces itself as inactive and outdated or (b) the page it links to is made active and updated, and the initial caveat removed. The Rambling Man (talk) 20:16, 16 January 2011 (UTC)

Sure. :-) I don't have the time to update this page anytime soon. And much less to participate in the drastic work that comes with it. Though we will need to work on infoboxes one day, I'm perfectly fine with removing this section for now - solution (a).

Note: I had some free time this week-end, so I decided to see how things are going and make a few edits. A lot of important discussions just begun, so I'll do my best to keep an eye on it, but I can't guarantee I'll be able to participate. Regards, Dodoïste (talk) 22:19, 16 January 2011 (UTC)

Done, I removed this section. Dodoïste (talk) 19:07, 17 January 2011 (UTC)

Accessible symbols

Following discussion at Wikipedia:FLC#Philadelphia Phillies_ all-time roster (C), which included the "invention" of templates such as {{dagger}} and {{double-dagger}} (which are appropriate for screen readers and also allow alt text to be used), I wondered if this was a useful opening for a more open and extensive review of symbols that could/should be used along with clear discussions over whys and why nots? The easier we make this for folks to implement, the more likely for it to be accepted at places where this is most prevalent, e.g. WP:FLC. All the best, The Rambling Man (talk) 20:38, 16 January 2011 (UTC)

I think that would be helpful. As a convenience for others, here's the link to a previous archived discussion that examines the general issue in some detail: WT:Manual of Style (accessibility)/Archive 11#Non standard ASCII. The method of replacing a non-ascii symbol by an icon + alt text is recommended by WCAG under technique F26, so I'd like to see us giving stronger guidance here to that effect. I can now make a template for any displayable symbol, but I'm still undecided on whether to use anti-aliased or non-aliased images for each symbol. Which is better:

or

? --RexxS (talk) 17:58, 17 January 2011 (UTC)

The "plain" one looks a lot better in my opinion, at both 1280x800 and 800x600. I'd very happily use that. —W F C— 19:14, 17 January 2011 (UTC)

Agreed, the plain one is better for scaling and appropriate for those tasks I envisage it for (e.g. wicketkeeper designation). The Rambling Man (talk) 19:17, 17 January 2011 (UTC)

Ok - I've amended Template:Dagger and Template:Double-dagger to use the plain (non-anti-aliased) images. It may take a while before the cached image is replaced by the new one. I'll bear the anti-aliasing in mind when we need to create other accessible symbols. --RexxS (talk) 19:36, 17 January 2011 (UTC)

Nice work. I've implemented both on the lists I know I've used daggers in. —W F C— 19:42, 17 January 2011 (UTC)

I'll do the same, and make recommendations to editors nominating cricket lists where use of the dagger is commonplace. I'll also note it wherever I see it in other nominations which just happen to use the dagger to identify something. Cheers. The Rambling Man (talk) 19:43, 17 January 2011 (UTC)

To my knowledge, there are now at least 6 templates of this nature (the daggers and card suits), and consensus is that there should eventually be a few more. Given this, perhaps we could list them on the access page, or at least provide a way of finding them? At the moment we have "Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead." But as far as I can tell, there is no further help for an editor wishing to follow this guidance. —W F C— 20:02, 17 January 2011 (UTC)

Agreed, hence the origins of this thread. If not discussed in detail on WP:ACCESS, perhaps a dedicated page which we could link to with a brief explanation of why this is a good thing, how to use them, and which ones are available? The Rambling Man (talk) 20:17, 17 January 2011 (UTC)

We do have the guidance "Symbols that cause problems for screen readers may already have templates created to substitute an image with alt text. An example is {{†}}; see Category:Image insertion templates for more". However, I've just looked at Template:Spades, but was disappointed to see that it still uses a text symbol: ♠ – which we know is read as '?' by JAWS. I think that some debate is required at the talk pages of the cards templates to see if there's any reason that an image + alt text (like "of Spades") shouldn't be implememted. If that's done, then I think a category Category:Accessible symbols should be made, and referred to in the guidance here. --RexxS (talk) 20:24, 17 January 2011 (UTC)

That sounds like an excellent idea, and one that all (potential and actual) featured material (as a minimum) could use to ensure we've got brilliant accessible material. The Rambling Man (talk) 20:28, 17 January 2011 (UTC)

Any chance we can quickly (?!) make those card symbols accessible too? They are used quite extensively throughout lists so an easy "find-an-replace" would be perfect. The Rambling Man (talk) 20:58, 17 January 2011 (UTC)

Quickly - no :( I've just spent an hour trying to make a spade symbol that looks good even when the screen is zoomed. And of course, I can't. Here's the text symbol followed by the image: ♠

– as you can see, the antialiasing required to make curves at normal size turns into fuzziness as the browser zoom is increased. It did the same with the anti-aliased dagger, but I was able to make a plain version of that without any curves or diagonals, and that's not possible with a spade symbol. Any thoughts? --RexxS (talk) 21:39, 17 January 2011 (UTC)

That's fine for articles (like cricket ones) which can (and now should) select alternatives. Not so sure what we can do about, say, poker or contract bridge articles which clearly are utterly inaccessible... Perhaps Jack has a solution? (turns on massive floodlight, pointed skyward, with J A C K on it... [apologies to Batman]) The Rambling Man (talk) 21:43, 17 January 2011 (UTC)

Image placement

Often images are placed in one section deliberately to "leak" into another, and I think this para in ACCESS tries to dissuade users from doing it:

"Note also that the image should be inside the section it belongs to (after the header and after any links to other articles), and not just before the header for similar reasons."

The "similar reasons" is a little unclear to me, but I guess it's because screen readers (for instance) would read it out in a different section from that intended by the fully-sighted editor who put it there in there in the first place? If so, could we clarify this explanation a touch? Perhaps just to be explicit that images should always be in the section to which they relate? The Rambling Man (talk) 21:14, 16 January 2011 (UTC)

That's probably a good idea. Yes, your explanation is correct. Graham87 07:59, 17 January 2011 (UTC)

Yes, this MoS needs to be clarified. Now that we removed irrelevant section, we have some more space to clarify the relevant sections. I just made an attempt to clarify, but I'm not conviced by my attempt. Any help is welcome. Dodoïste (talk) 20:56, 17 January 2011 (UTC)

Other languages

Could we expand on why we should use the {{lang}} template? All I see here that it renders the same text as not using the template. I guess that it helps screen readers to understand what language they're hearing (do they get a "French" or something spoken here?). Right now, for regular readers, there's no discernible gain to use the template, so some clarification would be useful to all. The Rambling Man (talk) 21:30, 16 January 2011 (UTC)

The lang template is used by some screen readers to change the spoken language of the text. For example the text {{lang|it|ciao}} will cause screen readers with the relevant feature enabled to say the word "ciao" in Italian. I myself don't have the "language detection" feature enabled, but some screen reader users are quite passionate about this topic. The template also has other non-accessibility-related uses; see Template:Lang/doc#Rationale. Graham87 07:59, 17 January 2011 (UTC)

I added the explanation to the MoS. I don't feel the need to get into complicated debates on how to use this template (unlike some passionated users). Indicating language changes should be quite straightforward. Dodoïste (talk) 21:38, 17 January 2011 (UTC)

No, I wasn't saying it needed something passionate, just that the previous explanation, well, explained absolutely nothing. At least now readers without screen-readers will understand that the text is read out, sometimes in the language defined in the template. That makes a huge difference. And I'll be able to start advocating its use at FLC because our contributors will understand the benefit of just a few extra characters that don't get in the way of 99.99% of our readership! Win–win I think they call it...! The Rambling Man (talk) 21:41, 17 January 2011 (UTC)

Sure. I just hope my little explanation will suffice, please let me know if it is not the case. When I mentioned "complicated debates on how to use this template", It was in reply to Graham87's comment. I know it isn't what you asked for. :-) Please let us know if you feel the need for more clarifications in this MoS. I'm so used to accessibility that I can't read this page as regular FLC editors will do, so your comments are much appreciated. Yours, Dodoïste (talk) 22:26, 17 January 2011 (UTC)

Keyboard shortcuts section

I'm not sure what this section has to do with WP:ACCESS. All it says is that shortcuts exist and can be disabled. Can we clarify what this has to do with web accessibility and why disabling them is relevant? Of course, the {{seealso}} is informative, but leads to a page which is in no way related to the manual of style. Is this subsection of WP:ACCESS even relevant? The Rambling Man (talk) 21:36, 16 January 2011 (UTC)

You're right, it's probably not relevant to web accessibility. Graham87 07:59, 17 January 2011 (UTC)

Although keyboard shortcuts are related to accessibility (all operations that can be performed by a mouse must be able to be duplicated using the keyboard alone), I agree that they have no relevance to the guidance we want to see given to editors at WP:ACCESS. I'd recommend that the section is simply removed. --RexxS (talk) 18:27, 17 January 2011 (UTC)

Keyboard shortcuts, in the way they are implemented on Wikipedia, are useful for some users with disabilities, and bothersome for some screen readers users because it interferes with the shortcuts of their screen reader. The best solution would be to have costomizable keyboard shortcuts. So, some users need to disable these shortcuts.

Regardless, as The Rambling Man pointed out, this information is irrelevant in this accessibility MOS. This page explains what editors must do to produce accessible articles. Techniques and advices for the screen reader users should be moved to other pages. Dodoïste (talk) 19:05, 17 January 2011 (UTC)

Done, I removed this section. Dodoïste (talk) 19:08, 17 January 2011 (UTC)

Partial replacement for a bar graph

I would appreciate any comments concerning Template:Georgia, Largest cities, 2009 Census -- Bar Graph. The top bar chart is the new one that I just made, and the bottom is one using the "timeline" syntax. It seems to me that the top one should be better for a variety of reasons, but I only have one browser, so I thought I would check here. Frietjes (talk) 01:25, 10 March 2011 (UTC)

Yes, the first version is much better. For better accessibility, add a table caption and row and column headers to it, so screen readers can detect it as a data table. Graham87 14:32, 10 March 2011 (UTC)

Indeed, your new bar chart surely improves accessibility. Nice one! :-) Also, don't worry about the rendering in different browsers: there is nothing in the graph code that may cause any issue with browsers.

Oh, and I agree with Graham87 of course: your graph has potential to become perfectly accessible, trough the techniques Graham87 suggested. If you're unsure about the methods to further improve accessibility, I'll be glad to help you with the coding. Cheers, Dodoïste (talk) 20:46, 10 March 2011 (UTC)

I wonder whether you'd consider describing this approach at Wikipedia:Graphs? WhatamIdoing (talk) 20:49, 10 March 2011 (UTC)

I think it's excellent, although the choice of "linen" as a colour is a little odd, it's quite hard to perceive. In any case, it's way, way better than the timeline template. It would be awesome if you could conjure up a generic timeline template (although I realise that's a big ask). The Rambling Man (talk) 21:01, 10 March 2011 (UTC)

If there is general interest, I believe I could make something more generic. I agree that the linen color is not the best, but I was looking for something that would have enough contrast, but still be visible. Please change it to something else if you can come up with a better option! The basic structure for creating the bars was created using {{Infobox political party/seats}} as a starting point, so I will ask the authors of that template for some suggestions and help as well. Thank you. Frietjes (talk) 21:24, 10 March 2011 (UTC)

I made some minor changes to the bar color, use em units, and split the rows into table rows, which may parse better on a text only browser. Hopefully this doesn't break anything. I believe we could turn this into a more general horizontal bar graph template. Thanks! Plastikspork _―Œ^(talk) 05:03, 11 March 2011 (UTC)

I made some big changes to the table. I added a table caption, column and row headers, and such in order to transform it into a standardized data table. Now Template:Georgia, Largest cities, 2009 Census -- Bar Graph is completely accessible. :-)

If the looks of it is okay with everyone, I'd be happy to make a more general horizontal bar graph template. Cheers, Dodoïste (talk) 14:45, 13 March 2011 (UTC)

Great! I went ahead and created {{Bar graph}} using Frietje and Dodoïste's revisions to the Georgia template. I believe we are converging on something very useful. Thanks for all the help and comments! Plastikspork _―Œ^(talk) 01:29, 14 March 2011 (UTC)

I just found {{Bar box}}. Frietjes (talk) 20:44, 24 March 2011 (UTC)

Thanks for notifying us. Now, {{Bar graph}} is way more accessible than {{Bar box}}. So we should really use {{Bar graph}} instead, when possible. Or change significantly {{Bar box}}. Cheers, Dodoïste (talk) 22:32, 24 March 2011 (UTC)

Default "alt text" for images

Hello ACCESS. I wondered if anyone had considered asking Mediawiki (or whoever) to implement a "default alt text" that could be set up at Commons which would provide a default alt text comment for all images there? Ok, so images uploaded to Wikipedia (e.g. fair use) would need some local addition of alt text, but I think it's a little odd that Commons images shouldn't have some default alt text. This may have been discussed before, and perhaps I'm asking for the impossible, but how good would it be to know that anything coming from Commons has something for screen-readers etc without worrying about it? The Rambling Man (talk) 18:51, 24 March 2011 (UTC)

Is you idea the same as the one suggested at bugzilla:19906? If so, you could support the proposal. Cheers, Dodoïste (talk) 22:41, 24 March 2011 (UTC)

Template:Flatlist

I see that {{Flatlist}} is recommended here. I've never heard of it (in nearly six years of editing) so I thought I'd see where it's used. Currently, according to this tool which counts transclusions of templates it's used 97 times across all of English Wikipedia. Is this really something we should be advocating, or is it something that has been superseded? I have seen horizontal lists, usually as part of templates, but clearly they rarely use this template. I think it's worth talking about, since MOS is advocating its use. To be fair, it's currently borderline {{TfD}} material. It'd be nice to know...! The Rambling Man (talk) 21:23, 16 January 2011 (UTC)

It's for marking up lists in the proper HTML format, so screen readers can detect them as lists. See Wikipedia talk:Manual of Style (accessibility)/Archive 10#Horizontal lists. I don't care about it that much. Graham87 07:59, 17 January 2011 (UTC)

With a different layout, {{Flatlist}} could (and should) be used in navboxes, in order to produce semantic lists. It has any number of other uses. It would be worth the effort, but might not be top priority as Graham87 said. Yet another tedious task that is gathering dust on my to-do list. Let's just say this template has some "potential". XD Dodoïste (talk) 22:00, 17 January 2011 (UTC)

Okay then, could you do me a big favour and find a list (e.g. List of birds of Pennsylvania) which may have a "flat list" and show me what the ideal "accessible" answer would be using the flatlist template? It'd be instructive to see what we get. Cheers, The Rambling Man (talk) 22:07, 17 January 2011 (UTC)

Well... Without changing its appearance, the table of contents and the navbox couls use such a flatlist. There would only be a semantic difference, without any change in appearance. It's only unfortunate that {{Flatlist}} produces such an ugly layout, I can't show you the result easily. Dodoïste (talk) 22:32, 17 January 2011 (UTC)

Problem with this template is the the bars that it generates to separate the items do not look vertical and causes problems trying to read it for some sighted users. This is more evident on very shote items where the separators are close together. This needs to be addressed before the template is used widely. Thus I always use bullet characters which avoid the problem. Keith D (talk) 01:29, 18 January 2011 (UTC)

If the template is problematic, it shouldn't be recommended for use in the MOS, surely? The Rambling Man (talk) 07:28, 18 January 2011 (UTC)

The template is correct from an accessibility point of view, which is the most relevant aspect here. However, the layout produced by {{Flatlist}} needs to be refined. The layout I suggest would look like the other horizontal lists, possibly with normal bullets like

For example in the navbox:

Provinces: British Columbia
• Alberta
• Saskatchewan...

Conclusion: {{Flatlist}} could be improved in a decent amount of time. So it wouldn't be the best choice to remove it from the MoS now. Dodoïste (talk) 21:30, 18 January 2011 (UTC)

Please provide an example of a correctly semantically marked up (i.e. using <li> in its HTML) horizontal list where you have used bullets. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:36, 28 March 2011 (UTC)

Hang on, while I agree that it could be improved (in whatever timescale), we should not be recommending the use of a template which is problematic. Given the number of usages, (and I'm still hoping someone can provide me with a good example of a featured list or article where this is beneficial, considering it's used 97 times across all of Wikipedia - 3.6 million articles) we should really work out if this is appropriate. If it is then we need to start telling people about it. Otherwise it's a dead end and the approach needs refining. The Rambling Man (talk) 23:11, 18 January 2011 (UTC)

Well, it's obviously useful when we want to present a list all on one line. I mean, its purpose is purely presentational as an alternative to using the * wikimarkup on consecutive lines. The reason it's not used more is that the best use would be to make a list of lists - and that equates to the table structure that everyone is already familiar with. To some extent, it's a circular argument: most editors don't structure the data they provide, so they don't understand lists, so flatlist doesn't get used, so nobody sees it, so editors don't learn that they could use it to structure data, and so on. It does have a niche use already in navigation templates, and the potential to be used more exists. I see no problem in recommending its use where appropriate, e.g. in collections of variable length lists like this:

List of major cities in the UK

England:
London
Birmingham
Manchester
Leeds
Liverpool

Scotland:
Edinburgh
Glasgow
Inverness

Wales:
Cardiff
Aberystwyth

N. Ireland:
Belfast
Derry

Although I concede that it really needs another parameter to turn off that CSS border between the elements. I'd probably use an image of a mid-dot with null alt text and no link as a separator if I were re-designing it, or do it in css by using a supported bullet. --RexxS (talk) 01:03, 25 January 2011 (UTC)

This is still not addressing the problem of the vertical bar and it looking non-vertical in some-cases, causing accessibility problems for some sighted people. This needs to be addressed before this template is widely used and it should not be recommended until this flaw in it is fixed. Keith D (talk) 20:32, 28 March 2011 (UTC)

Do you have any evidence if an accessibility issue being caused to sighted people? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:24, 28 March 2011 (UTC)

That's a bad example, because "England" is not part of the list which includes London and Birmingham. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:24, 28 March 2011 (UTC)

I beg to differ. It's an excellent example. HTML does not have markup for the semantic equivalent of row/col header in the implementation of a list. It does for a list of lists, i.e. a table. I don't see you criticising headers in tables just because we mark them up as elements of the table. If a list-header tag existed, then I'd have marked up the country with it. Just because you can't see the semantic connection between a country and the cities in it, there's no need to insult those who can. --RexxS (talk) 23:21, 28 March 2011 (UTC)

Please don't confuse criticism of the example with an insult to the provider of that example. The former - unlike your fallacious allegations about what you imagine or would like to think I cannot see - is not a personal attack an is perfectly valid comment. I'm familiar with the limitations of HTML lists in regard to headings; having raised that very issue with the WHATWG working group in the hope of rectifying the situation in HTML5, but that doesn't negate my point; and nor do false comparisons with tables. List mark-up is correctly for lists of items of equivalent type not such items plus headings. But these are side issue which shouldn't detract from the job at hand. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 00:09, 29 March 2011 (UTC)

Difference of opinions
Topic	Andy	Rexx	Reason
England	"England" is not part of the list which includes London and Birmingham	"England" is part of the list which includes London and Birmingham	A header should be associated with the data in its scope
Limitations	Claims to be familiar with the limitations of HTML lists in regard to headings	Doubts Andy's claim	Andy is unable to explain how "England" should be marked up
Tables	Tables cannot be compared to lists	Tables and lists are intimately connected data structures	A table is a list of lists
Lists	List data must be homogeneous	Homogeneity is a desirable, but unnecessary restriction, which does not account for the limitations of HTML markup	The list item acting as a header will be a label for the set of list data
Side issue	This is a side issue	This is a side issue	This is a side issue

--RexxS (talk) 12:08, 29 March 2011 (UTC)

Side issue or not; kindly refrain from making false claims about my position or capabilities. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:24, 29 March 2011 (UTC)

I have made no false claims. You can't explain how to mark up a list header to indicate its relationship with the list, and insist on imposing your opinion that lists have to contain only homogeneous data. Then you have the gall to criticise another editor's work simply because it doesn't coincide with your opinion of how things should be done. I didn't ask you to comment on my example, but you felt you had to anyway because you thought you knew better. Well it turns out that you don't; your position is utterly worthless in a Wikipedia discussion, and your capabilities are clear enough for anyone to see above. Now you have a choice: you can keep on provoking me by making things up, and I'll keep showing you where you're wrong; or we can bury the hatchet and get on with the real work like the horizontal list template. Your call. --RexxS (talk) 15:52, 29 March 2011 (UTC)

More false claims. I suggest that, if you wish to persist with this, we take it to one of our talk pages. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:40, 29 March 2011 (UTC)

Please note discussion below, at #Horizontal lists in navboxes, which I started earlier today, not knowing this topic was already in progress. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:39, 28 March 2011 (UTC)

Complex list formatting at WT:LISTS

I have asked a question about formatting a complex list at Wikipedia talk:Manual of Style (lists)#Complex_list_formatting. Since several people here know more than I about lists, and I'd be happy to have you look at it. Thanks, WhatamIdoing (talk) 19:41, 28 March 2011 (UTC)

Should be fixed now. --RexxS (talk) 23:46, 28 March 2011 (UTC)

How enforcible is WP:ACCESS?

Is this part of the manual of style arbitary or not? I recently tried to make some access changes at American Idol (season 10) but was gunned down in an instance. I brought it up on the talk page, and was again steam rolled. The opposition appears to be that the Idol project has their own standards of doing things. In particular i'm concerned with tables which use formatting such as {| border="5" cellpadding="3" cellspacing="0" style="margin: 1em 1em 1em 0; background: #f9f9f9; border: 1px #aaa solid; border-collapse: collapse; font-size: 90%;" |- bgcolor="#CCCCCC" before they even begin to list content. Additionally there's very little use of !scope= and an apparent disregard for color etc. — Lil_℧niquℇ №1 ^[talk] 01:43, 1 April 2011 (UTC)

Projects do not WP:OWN the pages in their area of interest. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 15:39, 1 April 2011 (UTC)

That is true but many projects have their own style guides and unless a project page is being pushed through FAC or FLC, there's no mandate for them to comply with WP:MOS and no mandate for them to comply with WP:ACCESS. A better approach, rather than crying "ownership", is to try to work with projects to help them see that many accessibility changes can be made relatively simply without compromising articles for the regular viewers. That's what User:RexxS did for us at WP:FLC and it's worked wonders as, over there, we try our best to accommodate as many accessibility issues as possible. The Rambling Man (talk) 15:42, 1 April 2011 (UTC)

Are you saying there's no mandate for Wikipedia to meet WCAG accessibility guidelines? I know you can't prove a negative, but can you show anything to back that up (I'm not being argumentative; I'm geninely interested). Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 16:15, 1 April 2011 (UTC)

Yep. You would need to show me something that mandates a requirement to meet WCAG accessiibility. In five-and-a-half years, I've seen nothing close to that. These are "style" guidelines as far as Wikipedia's MOS is concerned. Optional in almost cases. The Rambling Man (talk) 17:03, 1 April 2011 (UTC)

Well I appreciate Rambling Man's comments... but I wondered whether the stance is that unless its a GA or FA/FL then it doesn't need to adhere to MOS. Its concerning that on the one hand Access is becoming more prominent in the MOS yet there is stiff reluctance to adopt it... Essentially I'm asking for advice on how we can encourage editors to take up some of the access stuff... — Lil_℧niquℇ №1 ^[talk] 16:32, 1 April 2011 (UTC)

Good articles are not required to comply with this page, as you will see if you read the six GA criteria.

Complying with the MoS is recommended but not required for any article. FA has freely chosen not to award FA status to any article that doesn't comply with the MoS, but there's no requirement to attain FA status.

There are actually very few requirements on Wikipedia. They include: Do not violate copyrights, do not vandalize, and do not make threats. For these—if the community notices, at least—you'll get blocked. Beyond that, it's largely good advice, not "requirements".

In the instant case, you might like to read Wikipedia:WikiProject Council/Guide#Advice_pages, which addresses the issue of WikiProject 'guidelines' that contradict the community-wide guidelines. WhatamIdoing (talk) 16:38, 1 April 2011 (UTC)

It is simply a truth that certain corners of the wiki have become "walled gardens" where small groups can own articles and decide for themselves the content and the 'local style'. In the case of American Idol, I have tried to explain how the accessibility of all of our articles should be a concern for editors,[7] but sadly have been met with an attitude of "we always do it this way, so it's up to the developers of screen readers to accommodate us".[8] Lil's attempts to make progress are really commendable, but when that's countered by paranoid hostility and by personal attacks,[9][10], you probably have to give it up as a lost cause. Life's too short, I guess. --RexxS (talk) 17:51, 1 April 2011 (UTC)

What a discouraging conversation you link to at Talk:American Idol (season 10)#Tables_and_accessibility. It must be that feeling of anonymity on the internet. I hope that if he personally knew a blind person, he would not be so determined to prevent his own friends and acquaintances to read the article. It costs us so little to fix some of these problems.

On the practical side, the editor in question seems to use the "royal we", but I don't see any proof of involvement at Wikipedia talk:WikiProject Idol series. Perhaps it would be useful to explain the problems (in very simple terms) at the actual WikiProject page and inquire whether the project's actual members really are determined to make their articles less accessible to people who use screen readers, or if the editor in question is simply arrogating veto power to himself. WhatamIdoing (talk) 19:19, 1 April 2011 (UTC)

Actually, the results are not as bad as I paint them. Lil'unique has been steadfastly chipping away at the issue (kudos, Lil!), and when you look at the American Idol (season 10) page, you can see that the tables increase in accessibility with time! – as the good practice seeps into the editing. So all is not lost <grin>. There's still the minor issue of putting a number in the first column and marking up the name in second column as the row header – but it only causes problems for older screen readers that don't understand the markup (they just speak the contents of the first column as their choice of row header). It's not worth going to war over, and I expect time will solve these problems for us. Cheers, --RexxS (talk) 19:52, 1 April 2011 (UTC)

@Lil-unique1: I made a separate section to discuss the guideline you enforced at the talk page, as it played a significant role in this affair. To answer directly your question, some users will refuse part of the accessibility improvements we will advocate. In this case, it's important to not fight over it and to make the consensual changes first. From what I understand, you proposal - that contained other valid improvements like the addition of scope tags - was refused because of that number in the first column controversy. I suggest you remove this change in your proposal, and I bet you will have no more trouble to improve this article. Kind regards, Dodoïste (talk) 21:45, 1 April 2011 (UTC)

Number in the first column of a data table controversy

There was a significant controversy in Talk:American Idol (season 10)#Tables_and_accessibility about a guideline, among members of this accessibility project. We need to discuss this issue.

@Lil-unique1: To say it frankly, the case you are bringing up at American Idol (season 10) has little to do with WP:ACCESS compliance. There is no guideline in this manual of style - nor in the data tables tutorial - that support your claims at American Idol (season 10) talk page. You assumed that there should be absolutely no numbers in a row header, based on a guideline for a special kind of table. I tried to tell you, but somehow you stuck at your proposal.

Lil-unique1, it's good to have people like you here, enforcing accessibility guidelines. And you can make mistakes, just like everyone does. But since you're here to learn about accessibility guidelines, if someone with more experience on the topic says "you're wrong", you're supposed to reconsider and ask for explanations. I hope I'm not being too sharp here, because I really appreciate your participation. However, this is an important issue in our accessibility team. I hope we can fix this issue and move forward.

@RexxS: you supported the proposal about the numbers thing. Since there is no guideline about this case, we should discuss this guideline at the accessibility project. Discussing a guideline among editors that are supposed to apply it doesn't work, as it only add to the confusion. It's my mistake, I should have asked to discuss this issue at this WikiProjet immediately.

While you are right that it improves the situation for screen readers users, it makes it worse for sighted users. As you can see, the accessibility data tables tutorial does not mention this criteria. I moved it to the internal guidelines that are not meant to be enforced, for two reasons. Its priority is low, and I anticipated that enforcing it will produce such pointless conflicts. Yours, Dodoïste (talk) 21:45, 1 April 2011 (UTC)

You really need to refer to H.63 where there is an example given of this very case. Example 1: A simple schedule shows W3C's recommendation to mark up the cells in the second column as <th scope="row">. I think we all are in agreement so far.

But that W3C page has a link to Assistive technology reading tables which gives results of testing that sort of markup for HPR 3.02, Window-Eyes 4.5, JAWS 4.51, JAWS 7.1, and JAWS 8. It worth study because it shows quite clearly for example that Window-Eyes up to version 6 does not recognise the 'scope=row' set on cells in column 2.

So what should we recommend? I suggest that we should be encouraging/persuading editors:

to mark up column headers with ! scope="col" always;
to mark up row headers with ! scope="row" where possible;
to structure tables so that row header headers make up the first column if possible;
to learn about the different ways screen readers can render tables and how we can make their choices usable.

Now we all know that most of the time TH and SCOPE are not both necessary in HTML4, although for a header at least one is; but we already know that SCOPE won't be allowed on TD in HTML5 – and frankly it's clearer to advise TH SCOPE because it's never wrong to have both.

Column headers really ought to be compulsory, and are familiar enough to most editors that marking them up will rarely cause dissent.

Very small tables (e.g two-column) work just as well without row headers, so they are certainly not worth arguing about.

Larger tables benefit from having row headers marked up (whatever column they are in), so we should be aiming to educate editors in those benefits as a priority.

If we swap rows so that the row headers become the first column, we cater for viewers using older screen readers that don't recognise anything other than the cells in the first column as row headers. This is an issue that will diminish over time as viewers replace old software with newer versions. It would be nice if others were willing to go to the trouble to reorganise tables to help a small number of visually-impaired viewers, but I don't think it's a productive use of our time to fight those sort of battles, unless it is blatantly obvious that such changes could be easily accommodated (e.g. ! Title | Year | ... is far more sensible than | Year ! Title | .. for song releases).

Finally, there are pages like Tables with JAWS and MAGic and Accessible Data Tables which give detailed explanations of the different modes whereby JAWS can render data tables. --RexxS (talk) 03:02, 2 April 2011 (UTC)

I do not doubt that you are correct, in fact I believe you are more knowledgeable on this topic than me. However, you are missing the point. The issues I raised is:

Is it really such a high priority? The most important thing is for the column headers to be marked with scope=col. If there is no consensus for this edit, it's okay, don't push too hard. We're not in a rush anyway.

The accessibility issue was fixed at American Idol (season 10)#Males, using a scope=row in every row, but the header marked is in the second column. While standard and perfectly accessible, this will confuse editors. I think it's better if we can avoid it.

Another possibility is to merge the number and the name of the contestant. To merge the first and second column. What do you think about this idea? Cheers, Dodoïste (talk) 20:49, 3 April 2011 (UTC)

I think there will always be a tension between trying to make articles as accessible as possible and keeping advice simple. As you've said in the past, we should aim for what is achievable, not demand perfection – and I still agree. I don't want to see Lil'unique discouraged from improving accessibility in articles, but I don't want unnecessary conflict either. I suspect that time is on our side: a wiki improves incrementally, and all we need to do is nurture good practice and encourage good editors. As we might say about a wiki, "Plus ça change, plus c'est une meilleure chose." ;) --RexxS (talk) 23:41, 3 April 2011 (UTC)

Don't worry RexxS it takes more than this to discourage me... I know I only write song-related articles but all of my song articles use scope formatting where possible. Additionally the discographies I work on also use this formatting. :D That's my contribution. Hopefully people respect my small collection of GA articles and two years + experience to see to emulate the editing decisions i make when it comes to style. I wish the people over at American Idol would see that their entire project is a deviation from projects like The X Factor (especially The X Factor (UK series 7)) which is making an effort to become more Accessible. — Lil_℧niquℇ №1 ^[talk] 00:07, 4 April 2011 (UTC)

Good to hear that you will stay around here. :-) I can seem to be harsh sometimes, because I feel the need to speak honestly about the problems that arises. I mean it as a way to be constructive, and to enable us to move forward. I'm not sure if it produces the effect intended, however, and if you feel it doesn't help please state it clearly so that my little brain can understand. ;-) I'm able to hear criticisms about my behavior, and I even like it since it enables me to improve myself. Cheers, Dodoïste (talk) 04:16, 4 April 2011 (UTC)

^ One
^ Two

[1] One

[2] Two

[1]

[2]