Wikipedia talk:Manual of Style/Accessibility/Archive 10

Archive 5

←

Archive 8

Archive 9

Archive 10

Archive 11

Archive 12

→

Archive 15

Family of Barack Obama family tree

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

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

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

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

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

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

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

Familytree

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

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

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

	Elimelech 	
 
	Naomi 	
 
 	Boaz 	
 
	Ruth 	
 
	Mahlon 	
 
	Orpah 	
 
	Chilion 	
  
	Obed 	
 
	Jesse 	
 
	David 	

See also Wikipedia:Accessibility#Layout tables

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

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

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

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

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

New approach to family trees altogether

Folks,

I have had a go at an entirely different approach to drawing family trees.

If I could trouble you to have a look at User:Pee Tern/Sandbox/Template/Family tree chart/doc please ?

What do people think ?

Initial comments / suggestions / issues, here, please before I do much more work on it.

Also, for example, would "display:none;"s to give hidden column and row headings help ?

Please note that while definitely in the direction I think it should be going, it is still very much a work in progress !

Peet Ern (talk) 12:45, 11 December 2008 (UTC)

I don't have much time here, so here are some cursory comments. I don't like the way that each relationship is in its own table - I find it hard to read as it is. Does using a space for a table header work? I'd vastly prefer that to using CSS black magic. I'd ideally like to navigate family trees by using the arrow keys (navigate up and down to move between generations, navigate to the right and left to move between members of the same generation, or something like that). Those more familiar with HTML tables or family trees than I am might have more comments. Graham87 13:38, 11 December 2008 (UTC)

Thanks for the feedback. My use of the tables for each family was to try to automate the layout as much as possible, so that the editor could concentrate on the family structure, rather than the minutia of the layout. The strucuture is a recursive / nested one, and unfortunately the wiki parser does not provide a complete language to code in, and I cannot pass contextual information between families, etc. It is possible to do away with the tables for each family, but there would be a lot of calculating to be done by the editor, getting more and more complicated for each generation added to the family tree chart, it would go up the number of generations squared I think. But, I will think about what I can do. I need to ask though, is it better than the current approach? If not, then I will have to start from scratch again. I might be able to take the tables away from each relationship, but it will very difficult to take the tables away from each family.

Sorry for my ignorance, but does JAWS (and others like it?) read the HMTL markup, or just the rendered screen, because I might be able add more HTML markup, suitable for multimedia rendition, behind the scenes?

Are the vertical, that is parents above children, or horizontal, that is parents to the left of children, layouts better?

Peet Ern (talk) 12:09, 12 December 2008 (UTC)

Yes, it's better than the current approach. JAWS and other screen readers read the HTML markup, and read it basically linearly (with the exception of tables. I think having the parents placed vertically would be best. Perhaps family tree functionality would best be coded as an extension in JavaScript, so it can use all the facilities of a full programming language. Graham87 05:33, 13 December 2008 (UTC)

← I think the semantically-correct and more accessible way to do this may be via nested lists, with suitable styling, of course. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:10, 13 December 2008 (UTC)

I made a version of a Barack Obama family tree here. Any thoughts? ~Richmond96 t • c 03:22, 15 December 2008 (UTC)

It's on the right track. However, I don't like the empty cells as I find them confusing to read with JAWS. However, I realise that they're probably needed in a family tree. There need to be row and column headers as well. I'm not sure what the best way of signifying relationships is ... I found the table still a little hard to follow, and it took me a while to figure out that Madelyn and Stanley Dunham were grandparents of Barack Obama, and I had to read the article to figure out that they were maternal grandparents. It is better though, and if I got used to that format, I could probably use it to get a basic idea of a family tree. Graham87 13:40, 15 December 2008 (UTC)

Horizontal lists

Unresolved

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Heading structures

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

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

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

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

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

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

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

Headings in page template

Unresolved

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

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

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

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

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

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

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

Further info: WCAG says:

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

and:

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

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

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

←

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Where to put this

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

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

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

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

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

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

Template Documentation headings

Unresolved

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

Still unresolved. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:30, 23 August 2009 (UTC)

Succession boxes

Unresolved

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

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

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

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

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

and so on.

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

ALT text enabled

I have just noticed this:

* Images now take their alt text from their alt= parameter, if one is present. (r41837, bug 368)

in the Signpost archives. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 11:46, 23 November 2008 (UTC)

That's interesting that alt text was enabled so recently; L'Aquatique is on the cutting edge! Our accessibility guidelines don't mention alt text, do they? Should we add something to encourage editors to add alt text to their images and equations? That would seem to require someone like the original authors going through existing articles—esp. the FAs appearing on the main page—to add alt texts to their images and equations; I don't see how a bot could do that. Unfortunately, the authors of some FAs may have left Wikipedia or may be unable/unwilling. We could divvy up the leftovers among ourselves, although it's work to do even one article, as we now know from acid dissociation constant. But hey, I'm game, if you all are. Proteins (talk) 19:15, 26 November 2008 (UTC)

Sweeeeet... Yeah, let's do it. I see one of two ways to start: with FAs, there's something like a thousand of them (as opposed to two and a half million total). They would in theory be the hardest because they're more likely to have a lot of images. The other way we could do it that might be better is to start with the so-called vital articles. There are exactly 1,000 VA's- articles that are supposedly on the most important topics. Either way, we could each take one or two categories, i.e "Biographies" or "Arts and Humanities".

I am curious, though, before we do this. In what way is the alt-text feature different, technologically, from captions? Since this was apparently your beef, Proteins, (no pun intended) have you checked to see whether JAWS reads the alt text twice like it does captions? L'Aquatique[talk] 22:38, 26 November 2008 (UTC)

The caption feature is supposed to be a help to those who can see the image, while the alt text is there for people who can't see the image. The alt text isn't read twice in the current system. Graham87 23:29, 26 November 2008 (UTC)

Okay, but under the current system the captions still function as alt text when there is no alt text given, right? This isn't like, "zOMG all our images have no alt-text, fix it fix it fix it!" right? We can take our time working on this...? L'Aquatique[talk] 23:52, 26 November 2008 (UTC)

No. The captions don't function as alt text at the moment, but that can be easily switched by a developer. It's a tradeoff between having no alt text and having image captions read twice. I don't care which way we go, as long as it's possible to add specific alt text. Graham87 01:24, 27 November 2008 (UTC)

Well, it seems best to leave captions read except when alt text is enabled and slowly start to add alt text. L'Aquatique[talk] 05:58, 27 November 2008 (UTC)

OK, it sounds as though we're getting a consensus, although we should probably wait a week or so to let others chime in. Maybe we should also post a public message about the need for alt text, and that we're considering an addition to the accessibility guidelines? Once everyone's on board, we should contact the FA authors, which we can maybe do by working our way down WP:WBFAN. As you say, L'Aquatique, there's no rush but it'd also be a nice gesture. When we start adding them ourselves, I'm probably best suited for math-y and science articles, but I'll volunteer for anything.

I just noticed something odd. I'm not sure how long it's been going on, but my screen readers no longer read the caption twice. I've been tinkering with settings, so that might've done the trick, or it might be part of the bugfix that Andy mentioned. Are others having the same experience? I'm inclined towards the latter explanation, because I seem to remember that the caption was repeated in the image alt text, if you looked at the HTML source. That's how I'd been explaining to myself why screen readers read the caption twice: once for the alt text and once for the caption itself. But now the alt text seems to be an empty string unless you specify one. Proteins (talk) 14:37, 27 November 2008 (UTC)

Yes, the fact that captions are now spoken once is related to the bug fix that Andy mentioned. Graham87 06:30, 28 November 2008 (UTC)

Not having heard any opposition, I think we should be bold and add a requirement for alt text to the WP:ACCESS guidelines. To help people with that, perhaps we should update these instructions on writing good alt text for equations and images? Most editors will be unfamiliar with it, as I was, and we should make their learning curve as quick and easy as possible. I'll do my best with that, but most people here will know more than me — help would be appreciated! Proteins (talk) 14:17, 5 December 2008 (UTC)

I updated WP:ACCESS and MOS:IMAGES as best I could, but please check them over. I also re-wrote the leads to WP:ALT and WP:CAP, but not yet their bodies. I wrote this script to check whether the images on a page have alt text. Longer-term, we should also think about updating pages such as

• WP:EIS
• WP:PIC
• WP:IUP
• WP:IMAGES
• Help:Images and other uploaded files
• Wikipedia:Ten things you may not know about images on Wikipedia

but perhaps it'd be wiser to see how this initial round of edits goes over. Once the idea of image alt text has had a chance to percolate through Wikipedia and once the guidelines are worked out, it should be safe to contact people at WT:FA, WP:WBFAN and WP:WPM to make their works more accessible. Proteins (talk) 17:44, 5 December 2008 (UTC)

I've a small favor to ask, unrelated to alt text. Tim Vickers and I are giving a workshop on the 16th to a bunch of newbie scientists. Our goal is to have them editing a new article within 45 minutes; the whole workshop is only 2 hours long. We wrote this tutorial and I'm starting to make video tutorials such as this one. Advice and suggestions would be welcome - thanks! Proteins (talk) 17:51, 5 December 2008 (UTC)

Proteins- I'm free. What can I do? l'aquatique || talk 02:59, 12 December 2008 (UTC)

Image position

I have a query about the following guideline: "Images should be inside the section they belong to (after the header and after any links to other articles), and not just before the header." Is there any specific accessibility reason for this? Wikipedia:Manual of Style advises that editors should not "place left-aligned images directly below subsection-level (=== or greater) headings, as this can disconnect the heading from the text it precedes. This can often be avoided by shifting left-aligned images down a paragraph or two." However, sometimes for aesthetic reasons it seems better to place the image just before the subsection heading so that the heading and the text are in line. For example, if the subsection is short and has, say, only two or three paragraphs, placing the image lower down in the subsection can cause it to extend into the next section and create text alignment problems. — Cheers, JackLee ^–talk– 17:23, 27 November 2008 (UTC)

A screen reader user reads the page linearly - whatever is first in the wiki markup will be read first, no matter where its positioned on the page. So if an image is placed before a heading, a screen reader will read the image before the heading, thus not giving any context to why the image is there. Graham87 06:35, 28 November 2008 (UTC)

Wouldn't the caption or text tip be sufficient to provide the necessary context, though, since the very next bit of text would be the subsection heading anyway? I'm just wondering whether the guideline ought to be so rigid. It seems to me that there isn't much difference if the image caption is read just before the subheading, or the subheading is read just before the image caption by a screen reader. — Cheers, JackLee ^–talk– 07:01, 28 November 2008 (UTC)

If it was a descriptive caption, it would give enough context. To me, it makes more sense semantically to have an image in the section that it illustrates, so the page structure is easy to understand. Most images are in the section they illustrate. I'm not so hung up on the issue to start lame edit wars about it, and I'd be interested in other opinions. Graham87 07:21, 28 November 2008 (UTC)

Thanks for the clarification. I asked because another editor relocated an image in an article on the basis of compliance with this guideline. I didn't think that the change was really necessary, but didn't object to it. Nonetheless, I wanted to find out the rationale behind the guideline. Yes, other views on the matter are most welcome. — Cheers, JackLee ^–talk– 07:52, 28 November 2008 (UTC)

Placing images within the section they belong to is also a formatting issue. If they aren't placed inside the correct section, they can end up rendering elsewhere on the page depending on screen size and resolution, divorcing the image from the portion of the article it illustrates. // roux   08:22, 28 November 2008 (UTC)

Perhaps, then, we should do away with the guideline stating that images should not be placed immediately after subsection-level headings. That rule and the rule regarding keeping images within sections place editors between a rock and a hard place when the subsection in question is short. — Cheers, JackLee ^–talk– 10:22, 28 November 2008 (UTC)

No we shouldn't, for the reasons already outlined. // roux   10:41, 28 November 2008 (UTC)

I understand Graham's "A screen reader user reads the page linearly ..." (06:35, 28 November 2008). It would have been helpful if roux had explained his(?) objection to images right after sub-headings.

At the same time, as JackLee says images taller than the associated text can cause real problems. I edit mainly paleontology and biology articles, and in these subjects a picture is often worth thousands of words, so I often encounter that problem, especially with a wide-screen monitor.

I've just done a little experiment and think this might be OK:

<div style="position: relative; top:-35px; float:right; width:auto;">[[Image:Cladocora.jpg|right|thumb|The fossil coral ''[[Cladocora]]'' from [[Pliocene]] rocks in [[Cyprus]]]]</div>

For example imagine this line is a heading and look at the position of the pic

The fossil coral Cladocora from Pliocene rocks in Cyprus

That way a screen reader still processes it in the "right" order but the CSS in the DIV tag moves the image up on a screen. Of course one has to be careful that it does not visually overlap preceding text, as the CSS overrides the browser's layout calculations. What do you think? --Philcha (talk) 11:33, 28 November 2008 (UTC)

I think no, because again: the image can show up away from the text it's supposed to be illustrating (and yes, this can happen on widescreen monitors anyway), which makes the use of the image pointless, as well as the difficulty of ensuring that text isn't overlapped. Jacklee also misunderstood the 'no img under subheads' thing; what it actually says is no left-aligned images under subheads, which is explained really clearly by the Access guidelines. All of this is really just a solution in search of a problem. // roux   11:41, 28 November 2008 (UTC)

Seeing how this was in response to an edit I made, I would have appreciated a note informing me of this discussion, but that's okay. I don't know enough about screen readers to make a comment about it, so I'll trust whatever Graham87 says. I made the edits in question for two simple reasons: Images should go in the most relevant section. Suppose there was the section "Style B" and an image of this style. The image should be within this section and not right above it in section "Style A". It's really simple: images should go in the section they are relevant to, not right above the section in a different, irrelevant section. If you want to edit the image and text of the same topic, they shouldn't be in different edit sections.

Second, it looks better. Images shouldn't be to the side of a header yet both above and below it; it just looks really bad, especially when there's extra white space below it.

I see the problem of having a left-aligned image right under a 3rd level heading, but I don't personally care. The image is still in the correct relevant section, and the header, although separate from the text, is on top of the image. That isn't a big deal for me, but images really need to be in their relevant section, not right above. Reywas92^Talk 17:37, 28 November 2008 (UTC)

Sorry, Reywas92, I figured you were watching "Wikipedia:Manual of Style" and so didn't require a specific notification. I'm not exactly sure what you mean by an image being "to the side of a header yet both above and below it" – are you referring to a situation where a left-aligned portrait-format image starts halfway in one section and ends halfway into the next section? I would agree that that generally does not look very good. However, if the image is positioned directly before the heading, it looks all right because the text in the section above is not disrupted at all. I also think that an image that is just above the heading is sufficiently closely associated with the section. As I mentioned above, I don't think it creates an accessibility issue for screen readers.

Roux, can you explain in what instances "the image can show up away from the text it is illustrating"? I'm not sure I have encountered this problem. But thanks for reminding us that the guideline only advises against placing a left-aligned image directly under a third-level heading. However, there are instances when the desirability of having a left–right balance of images in an article means that the image looks better on the left side of the screen. Ultimately, this may be one of those instances where on occasion it can be appropriate to ignore the rules. — Cheers, JackLee ^–talk– 19:30, 28 November 2008 (UTC)

It's not appropriate to IAR when it comes to matters of access for those who need to use alternate methods of accessing the project. As for 'showing up elsewhere', I've run into editors who place images elsewhere on the page because on their screen only the image then appears to render in the correct spot.

The guideline as it stands is nice and simple: put images in the sections where they belong. This satisfies accessibility, guarantees that in almost all cases images will render next to the text they describe, and ensures that when you go to edit an image in Section Foo, you don't have to hit your back button and edit Section Bar instead because someone put the image up there. // roux   20:58, 28 November 2008 (UTC)

Just a quick description of the problem for people coming in in the middle: when the image wikilink is placed just before a heading or subheading, which will in general render both as starting on the same line, there are problems. Graham, who relies on and who is widely relied on for matters regarding screen readers, considers it confusing to hear a caption just before hearing the section the caption belongs in, but now that "alt=..." in image links works (yay!), can't we solve this problem with appropriate alt text? There are two other concerns, but both are problems that will be fixed as soon as the devs fix them, and on general principles, I object to assuming in the style guidelines that dev problems will never be fixed and that we have to scramble to compensate. The first problem is that Wikipedia articles are of course saved in a database, and when you edit a section, you're editing just that record in the database; any image whose link occurs just before the heading will only be editable if you click the link for the "wrong" section, the one just above, even though to any reader, the picture appears to correspond to the section below. The second problem is one mentioned above, that on smaller screens, the picture can be badly displayed. Poorly designed screen displays are not a problem that copyeditors can fix, and we shouldn't be warping the style guidelines to compensate for the problem, because for all we know, it will be fixed tomorrow. - Dan Dank55 (send/receive) 20:13, 28 November 2008 (UTC)

I don't think alt text is the answer; you're still hearing the image description before hearing what the section is about. It wouldn't make sense to read things in that order, doesn't make sense to hear them in that order. // roux   20:58, 28 November 2008 (UTC)

Roux, you're not making sense to me. The technique I proposed above puts the image in the right place in the (X)HTML from the point of view of screen readers, and is not above the heading, so it does not look like part of the preceding section. I've just tested it by zooming in and out 3 sizes in Firefox and the image remained in the same place relative to the imaginary heading. You mentioned widescreen monitors, which make use of images more difficult because they reduce the height required by each para of text. Can you please explain what is wrong from a reader's point of view with moving the image up using the technique I suggested, and especially why it is nor better for readers than inserting {{clear}} or <br clear="all" /> and thus creating gaps in the text. --Philcha (talk) 21:47, 28 November 2008 (UTC)

Because your solution makes things it more difficult for editors. Which by definition makes things harder for readers, because you're proposing something relatively complex that not all editors will grasp. Even more to the point, we want readers to become editors--that means we should keep coding simple wherever possible. The guideline as it stands is simple, effective, easy to use. Nobody has adequately explained what is broken and why it needs fixing. Moreover, you yourself said there can be text overlap issues... why do we want to cause these? As I said before, this is a solution in search of a problem. // roux   21:55, 28 November 2008 (UTC)

What the guideline proposes is so obvious that it hardly even needs a guideline, putting an image outside the section it belongs to is nonsense, in my opinion, and I don't see how it would be useful, or at least useful enough to justify confusing the reader by having it outside the text it illustrates. FunkMonk (talk) 10:16, 30 November 2008 (UTC)

Unsuccessful test of Philcha's CSS

The fossil coral Cladocora from Pliocene rocks in Cyprus

Phil, on my fairly standard screen using Firefox, this image obscures the edit button, so that's no good. I've played around with the CSS before, and it's frustrating; there are various codes that give me exactly what I want in the preview, but then obscure the edit button on the saved page.

The fossil coral Cladocora from Pliocene rocks in Cyprus

For comparison

Here's what we get when the image wikilink comes just before the subsection heading. Note the edit button is pushed just to the left of the image. - Dan Dank55 (send/receive) 22:01, 28 November 2008 (UTC)

• It is naive to assume every image has just one "section it relates to" and this sort of thinking is the cause of many of the image placing problems on WP. Being right next to the most relevant text is often not the most important factor in choosing an image placement, depending of course on the subject. Johnbod (talk) 23:11, 28 November 2008 (UTC)

It is no such thing. In almost every case, an image is very directly related to a specific portion of text. // roux   00:49, 29 November 2008 (UTC)

While Philcha's CSS solution is well-intentioned, I too cannot see the "edit" link in the section (using Mozilla FireFox), and am afraid that it is too complicated for people not familiar with CSS. Having read the discussion thus far, I am coming round to the idea that the guideline as currently drafted is justifiable, though I still feel that in individual cases some flexibility can be shown. — Cheers, JackLee ^–talk– 03:57, 29 November 2008 (UTC)

I agree I pushed it too far up in that specific example. OTOH there's no problem about pushing it up where there's a {{main}} or similar item, provided pushing it up does not obscure the {{main}} or similar item in a window with a 4:3 aspect ratio (i.e. not widescreen). Sometimes that small adjustment can avoid the need for a {{clear}} or <br clear="all" />.

I notice no-one has answered the question I asked above - why is adjusting the image position worse for readers than inserting {{clear}} or <br clear="all" /> and thus creating gaps in the text?

Re the technical CSS aspect, editors who are unhappy about layout issues but unfamiliar wth (X)HTML and / or CSS can always ask others to help out, e.g. by posting requests for help on the article's and / or Wikiproject's Talk page, or even at the Village Pump. --Philcha (talk) 16:33, 30 November 2008 (UTC)

Because there's nothing inherently wrong with some gaps in the text. More to the point, gaps will only show up on some screen resolutions. Always putting the image within its logical section ensures that there is consistency as much as possible in terms of article layout and accessibility for those who use screen readers. There is something wrong with a system that is not only orders of magnitude more complex for editors to implement, but also obscures links, and (again) means that the code for the image is not in the logical section one would expect when one clicks 'edit'. We want readers to edit, and making things needlessly complex and hard to find is not a good way to go about that. // roux   editor review16:58, 30 November 2008 (UTC)

TOCright considered harmful?

Someone recently edited a dab page to remove {{TOCright}}, with an edit summary consisting of just "WP:ACCESS".

In reading this page, it says "Avoid floating the table of contents if possible," which seems like less of a prohibition than just a quick and maybemisleading summary of the linked-to section on Floating the TOC, which includes the line:

• A left-floated TOC may affect bulleted or numbered lists. Where it does, float the TOC to the right, or do not float it.

Dab pages follow different formatting rules than articles in any event; floating or suppressing the TOC is common practice, as the TOC doesn't really do a whole lot of good, and does disrupt the list flow.

Is there existing consensus on how TOCs should be handled on a dab page to accommodate both accessibility and general usability? Thanks, NapoliRoma (talk) 17:21, 3 December 2008 (UTC)

There is nothing inherently harmful about {{TOCright}}, just where it is placed in the page. As long as there's no text between the table of contents and the first section, it is fine for screen readers. I'd favour just removing the TOC from most disambiguation pages, because it doesn't seem to be useful on tghem. Graham87 00:51, 4 December 2008 (UTC)

WCAG 2.0

Version 2.0 of the W3C's Web Content Accessibility Guidelines is now finished (see W3C Recommendation 11 December 2008; press release). It's very different to v1.0.

There is still no clear written policy (leastwise, none that I can find) mandating or recommending that those industry-standard guidelines should be followed, let alone to which level, on Wikipedia. I believe that there should be a clear policy that WCAG guidelines should be followed to a stated level; or at least that we should, as a body, strive towards doing so.

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

In principle, I'm all for this.

I haven't had a chance to review the recommendation yet. Given the limitations of Wikitext (like unavailable HTML elements), are we technically able to implement all of WCAG 2? Should we undertake to audit the recommendation and identify any difficulties which may arise? —Michael Z. 2009-01-03 22:10 z

I'll back-pedal a bit. Before it was finalized, WCAG 2 was somewhat controversial. Anyone know if criticisms were addressed in the final version?

I'm more familiar with WCAG 1.0 and the WCAG Samurai errata. —Michael Z. 2009-01-03 22:15 z

Yes; it's very different, and those I know who were involved and agin the first version are content now. Clearly, we cannot meet guidelines where the technology will not allow us to; but we should at least try, and meet those which we can. Do you have specific examples in mind? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 22:25, 3 January 2009 (UTC)

I'm thinking of To Hell with WCAG 2. I haven't been following the debates and any resolutions or lack thereof, so I'm neither objecting nor not objecting right now. But some of the points raised in that article seemed legitimate, and I plan to do some reading to better evaluate the current state of WCAGs. —Michael Z. 2009-01-04 00:07 z

So was I (and others like it); that article is coming up to three years old now; a lot has changed since then. My friend Jack Pickard charts the development of WCAG 2; you'll notice that he goes from (at the time of the article you cite) being firmly against to strongly for it; and he's not atypical. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:17, 6 January 2009 (UTC)

I'm not highly active here and I'm not presuming to give anyone advice. I have put off familiarizing myself with WCAG 2 until it was finalized, and I have just started to read about it. It is very large, and will take some time to understand. So personally, I won't commit to supporting it yet.

I have a reasonable understanding of WCAG 1 and the Samurai Errata, and I am comfortable working with them now. It is still possible to conform to 1.0, or both 1 and 2:

WCAG 2.0 succeeds Web Content Accessibility Guidelines 1.0 [WCAG10], which was published as a W3C Recommendation May 1999. Although it is possible to conform either to WCAG 1.0 or to WCAG 2.0 (or both), the W3C recommends that new and updated content use WCAG 2.0. The W3C also recommends that Web accessibility policies reference WCAG 2.0.

To this point we (en.Wikipedia) haven't officially committed to meeting any particular level of accessibility conformance (right?). I'd feel more comfortable launching an effort to evaluate articles' conformance levels—following any or all of these guidelines—as a way to gauge and improve accessibility. —Michael Z. 2009-01-06 06:20 z

My suggestion is that we we should commit to working towards WCAG 2. I must say, though that I was hoping more people would comment. I think I'll take this to VPT and elsewhere, to initiate that. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 08:17, 6 January 2009 (UTC)

Will WCAG 2-compliance actually increase accessability, or will it just result in a bunch of busywork leading to a marketing bullet-point? --Carnildo (talk) 11:14, 6 January 2009 (UTC)

It will lead to vastly-improved accessibility. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:17, 6 January 2009 (UTC)

So far we have some good general advice, but we don't really have the ability to state “this article is accessible”. We do need to establish a more systematic way to assess accessibility and identify needed improvements. I think it's a very big job to relate the complex standards to simple rules for Wikipedia editors, but this is the right path. —Michael Z. 2009-01-06 16:53 z

• I rewrote the CENT notice. Not sure if this was intended but most users wouldn't know WCAG from WLAN. Protonk (talk) 07:16, 7 January 2009 (UTC)

• I agree with Michael Z’s basic sentiment. I’d like to expand on that. It would be very nice to have an executive summary-like explanation (succinct bullet points for those like me with galactic-grade attention deficit) as to precisely what must change on Wikipedia in order to be WCAG-compliant. It would also be nice to know whether Wikipedia would be one of the few leading the charge, or would simply be falling in line with what is now a common industry practice. What I am trying to drill in on is whether or not significant change (which never seems to happen easy on Wikipedia) will be required, and if so, whether it is to get Wikipedia in line with what 95% of Web sites currently do, or whether doing so would put us in the position of trying to be the first 2% of Web sites. If the burden on editors isn’t at all onerous, the changes to Wikipedia very significant, and being compliant doesn’t detract in any significant fashion from the scope and quality of its content, there is no reason to not lead by example and hope the rest of the Internet falls in line. Unfortunately, I’ve seen an editor cite WCAG as a basis for the removal of automatic looping animations from Wikipedia. So it would be refreshing to finally have some facts upon which we can make rational decisions.

  So let me begin with these two questions (or set of questions in the latter case):

1. What percent of Web sites are in full compliance with WCAG now?
2. What sort of content will change? Will self-running, looping animations such as these found at Pi (number) and Vortex shedding, be OK? What else might change?

Greg L (talk) 02:57, 9 January 2009 (UTC)

I definitely agree with Greg L. All of this discussion is academic until there's a smallish comprehensible list of the most egregious violations from the spec that we currently have, and what it would take to fix them. Most people aren't inclined to wade through the whole spec just to be able to discuss it here — I know I'm not! --Cyde Weys 03:14, 14 January 2009 (UTC)

Having waded through part of WCAG 2, my recommendation is that we pretend it doesn't exist. The guidelines suffer from a bad case of second-system syndrome, and the authors don't seem to understand the boundaries between a webpage and the user-agent rendering the webpage: there are a number of guidelines where you can't say a webpage meets the guideline, you can only say that it doesn't actively interfere with meeting the guideline. --Carnildo (talk) 04:55, 9 January 2009 (UTC)

I agree that some of the material there is overdetailed (such as the part regulating just how much flashing is acceptable, when the simple Samurai statement is "none"), but to follow at least the intent of it is a positive direction to go. What part of it do you think inappropriate to us?DGG (talk) 19:29, 10 January 2009 (UTC)

If we set up a framework for assessing articles' accessibility, or for flagging accessibility problems, then it should accommodate any standard: WCAG 1, Samurai, and WCAG 2. Editors may choose whichever yardstick they like. What else is there: US section 508, UK guidelines?

We need a talk-page box for this info. —Michael Z. 2009-01-13 16:57 z

Using different, and sometimes deprecated, guidelines on different pages would lead to madness. It would also make the task of writing our own help-pages and policies for editors so much more complicated. We would end up with an MoS-WCAG2, an MOS-508, an… Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:49, 17 January 2009 (UTC)

WCAG 2.0 is “recommended” (see my longer quote above),[4] but WCAG 1.0 is not deprecated.[5] —Michael Z. 2009-01-18 04:22 z

We don't necessarily need an MOS for every standard. If somebody decides they want to evaluate articles according to their own government or school board-mandated standard, for example, we may as well give them a the opportunity. —Michael Z. 2009-01-18 07:56 z

ISO 3166-2 code tables

How does the main table in ISO 3166-2:GB render, in a screen-reader? Badly, I suspect, If so, we will need to find a better method for laying out the table (which currently has two lots of the same information, sorted differently), then ask for a bot to apply it to the many similar articles (see navbox at the foot of that page), one for each country. Would a simple, sortable table suffice? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 12:12, 14 December 2008 (UTC)

Yep, it renders badly. The table needs proper headers, for a start. Making he table sortable and making bots apply them to all the pages sounds like a good plan. Graham87 00:18, 15 December 2008 (UTC)

I'm on it... l'aquatique || talk 05:27, 15 December 2008 (UTC)

Done. I'll check the other pages tomorrow to determine whether it would be faster to program a bot or do it by hand. l'aquatique || talk 06:35, 15 December 2008 (UTC)

Any luck? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 17:26, 6 January 2009 (UTC)

Template:Xt

Template talk:Xt#Accessibility could use a third opinion about accessibility for this template. Thanks. —Michael Z. 2008-12-31 22:48 z

Image alt/caption confusion

The "Images" section of this page states that images should have alt text (1) and that images should have captions (2). This gives me the impression that every image should have both alt text and a caption. At Wikipedia:Alternative text for images, it is stated, "Every image, including math-mode equations, should specify alternative text (alt text)", but then there is an entire section called "When alternative text is unnecessary", which says "Alternative text may not be necessary if the caption itself suffices to describe the image". So now it appears a caption may warrant removal of alt text. Then at Wikipedia:Captions, we have, "Not every Wikipedia image needs a caption" and "Regardless of whether you include a caption, all images should have alt text", so now maybe we can have alt text but no caption. Furthermore, many infoboxes such as {{Infobox VG}} have a "caption" parameter that displays text under the image (specified with the "image" parameter)—is this a separate case from a caption given in the [[Image:...|caption]] format, or is a caption a caption? I try to follow accessibility rules when I can, but this is extremely confusing and I would appreciate it if someone who is knowledgeable in this area can get these pages in sync so editors like me can tell what we're supposed to do. Pagrashtak 21:17, 2 January 2009 (UTC)

Theoretically, the caption is supposed to be there to provide extra information to those who can see the image, while alt text is supposed to provide information to people who can't see the image about what it contains (i.e. the blind, people who have images turned off in their browser, etc). In practice, the distinction can be fuzzy, and I'm not sure what the guidelines should say either. Graham87 08:49, 3 January 2009 (UTC)

If Graham's not sure what the guidelines should say, we have a problem. For images that are just eye-candy, as most are, I think the captions are enough. However some technical diagrams and some maps (e.g. battles) present important info that is too complex for an ALT tag. Would it be worth requesting a change to the Image code so that it can include a "link" parameter that jumps to the relevant section or {{anchor}} in the main text? This would have a similar function to the LONGDESC attribute of the IMG tag (could even be implemented as a LONGDESC), but without duplicating text, creating a separate page? etc. --Philcha (talk) 12:05, 3 January 2009 (UTC)

Yes, the best use of the ALT parameter is something we should all discuss, so that we can reconcile the inconsistencies on the policy pages in a stable way. It's natural that we should be confused since the alt tag was added only recently to the MediaWiki software. As Philcha suggests, we should also consider other technical solutions that might be more effective or more practical.

As a first step, can we agree that LaTeX-formatted mathematical equations should always have alt text? I think no one will disagree that they're important to understanding the article.

Turning to images, I disagree with the idea that most are "eye-candy" and also with the suggestion that images judged to be "eye-candy" don't need to be described to blind users and others who can't see them. I personally feel that we should make a stronger commitment to accessibility. I'm also troubled by a system in which rather subjective decisions are made about what information blind people can have. However, I'm open to hearing other perspectives.

I think we need more guidance on (1) what would be useful to include in alt text and (2) what people typically include for alt text in other educational materials. I'm sure that we aren't the first to encounter this problem!

Alt text was discussed recently at Wikipedia_talk:Manual_of_Style/Archive_106#ALT_text, with a specific example of a picture of Bertrand Russell's father. Proteins (talk) 13:34, 3 January 2009 (UTC)

Yes, all math equations should have alt text, otherwise MediaWiki will make up its own, the TX itself (ugh)! Now that I think about it, the ideal image situation for me would be to dispense with captions altogether, and just use alt text, and use longdesc or Philcha's suggestion about links. Using just <title> tags (which are used in image captions) as descriptive text isn't standard for most websites. Most sites have to grapple with the idea of what alt text should be included, but not many sites distinguish between alt text and image captions in practice. Graham87 14:01, 3 January 2009 (UTC)

The Perfect Article

Wikipedia has a checklist called "The perfect article".

Here is a discussion on whether or not an inaccessible article can be called "perfect", where it has been suggested that WCAG guidelines "aren't appropriate for Wikipedia". Please feel free to contribute. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:37, 3 January 2009 (UTC)

Thanks Andy. Also see WT:MOS#Eyes needed. - Dan Dank55 (send/receive) 02:48, 4 January 2009 (UTC)

Ongoing hidden content discussion

Talk:Alexander Alekhine#Hidden solutions in diagrams: a number of articles on chess players and chess tactics include 'problems', where a chessboard is shown midway through a game, there being an optimal set of moves for one or other side thereafter. The captions on these pseudo-images include the sequence of moves, but hidden inside collapsible sections (eg). I removed the hidden styling citing both accessibility and 'not censored' concerns, but was reverted. Comments are appreciated. Happy‑melon 21:35, 6 January 2009 (UTC)

You were correct to do so; both for accessibility and in comparison to the removal of "spoiler" notices from articles about cinema films. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 23:30, 6 January 2009 (UTC)

Weather templates

There's a discussion at Template talk:Infobox Weather#This template or template:Climate_chart about the use of {{Infobox Weather}} vs. {{Climate chart}} which both present the same kind of data but in completely different formats (one is a table of numbers with different color backgrounds to indicate coldness to hotness where the other is a bar chart). If there are accessibility reasons one of these should be preferred over the other please comment (there, not here). Thanks. -- Rick Block (talk) 03:35, 9 January 2009 (UTC)

scrolling boxes ... ?

Hi, do the scrolling box things (see here) cause accessibility problems? Thanks Ling.Nut ^{(talk—WP:3IAR)} 05:22, 14 January 2009 (UTC)

MOS:SCROLL (which is linked from Wikipedia:Accessibility#Scrolling lists) says they and show/hide boxes cause readability, accessibility, and printing issues. Are you looking to verify the accessibility part of this applies to scrolling lists? -- Rick Block (talk) 06:01, 14 January 2009 (UTC)

Writing as someone who uses no assistive technology, just a regular web browser, they suck for accessibility. They force me to use another control to scroll, reduced the scrolling area by half, and make it impossible to easily flip between different parts of the page. What's the point, saving paper? —Michael Z. 2009-01-14 06:09 z

I was just looking for a yes/no answer, which i have rec'd. Thanks! Ling.Nut ^{(talk—WP:3IAR)} 11:15, 14 January 2009 (UTC)

Evaluating WCAG 2.0 conformance

One thing I do like about WCAG 2 is that its Conformance section is very specific (although a bit complex). Before we can evaluate specific articles, we need to determine the baseline provided by the WikiMedia software, and its implementation in Wikipedia, and set some goals.

1. Conformance is for full pages. This means that we need to first evaluate the conformance level (and any failures) of a blank article page, and this would represent the best level that any article could meet (until problems are fixed). We should then fix what we can here at Wikipedia, and submit the remainder as bug reports in Bugzilla. Of course, even if we can't conform to a certain level, factors beyond our control do not prevent us from continuing to work on improving other accessibility checkpoints which we do control.
2. As far as I can tell, WCAG 2 also requires that we decide whether we rely on our CSS and JavaScript for accessibility of the HTML. I guess the ideal would be to conform both with and without either of these optional technologies (am I interpreting this correctly?).
3. Conformance for the process of editing is a separate, tougher requirement than for reading individual articles. Once we get rolling, the priority should be articles for Version 1.0 and/or featured articles. We should review and tag templates too, as their output can affect many pages. Candidates for evaluation also include pages in the Help, Wikipedia, and Talk namespaces.

Checklists are available for WCAG 1 (sorted by priority),[6] and WCAG 2.[7]. —Michael Z. 2009-01-18 07:36 z

I've begun a WCAG 1 audit of the page template at User:Mzajac/Accessibility/WCAG 1.0. This doesn't yet consider the capability of Wikitext or page content. —Michael Z. 2009-01-20 20:23 z

By the way, it appears that the current version of MediaWiki software can't quite conform to any level of WCAG 1.0, although the fixes required are pretty minor. So far I have only evaluated the HTML, and not the JavaScript. —Michael Z. 2009-01-21 01:17 z

Two issues that don't seem to be covered anywhere else

Are screen resolution and browsers without JavaScript. As far as I'm aware, the current consensus is that our pages should look acceptable on 800x600 (but no lower) and that all content should be accessible to users without JavaScript and CSS, although it is accepted that it may look inferior. However, these guidelines are not really laid out anywhere properly, this page seems the natural place to do so. This ties in well with MOS:SCROLL, which has always seemed rather out-of-place to me on the main MoS page when it's largely an accessibility issue. If that section were moved here (and the shortcut updated) it could be made clearer and more extensive without bulking up the main MoS page.

Largely to kickstart some discussion, I'll throw out some proposed wording. How about replacing the #Style and markup section with this:

“

Styles and markup options

In general, articles should use wikimarkup in preference to the limited set of allowed HTML elements. In particular, do not use the HTML style tags <i> and <b> to format text; it is preferable to use Wiki markup '' or ''', or logical style tags. Of course there are natural exceptions: it may be beneficial to use <u></u> tags to indicate something like an example of an unclickable link. The <font> tag should also be avoided in article text; use logical style tags like <em>, <code>, or <strong> to emphasise semantic differences. Use <small> and <big> semantic tags to change font size, rather than setting it explicitly with the font-size= style attribute.

In general, styles for tables and other block-level elements should be set using CSS classes, not with inline style attributes. This is because the site-wide CSS is more carefully tested to ensure compatibility with a wide range of browsers; it also creates a greater degree of professionalism by ensuring a consistent appearance between articles. Deviations from standard conventions are acceptable where they create a semantic distinction (for instance, the infoboxes and navigational templates relating to The Simpsons use a yellow colour-scheme instead of the customary mauve, to tie in with the dominant colour in the series) but should not be used gratuitously.

Users with limited CSS/JavaScript support

Wikipedia articles should be accessible to readers using browsers and devices which have limited or no support for JavaScript or Cascading Style Sheets. At the same time, it is recognised that it is impossible to provide the same quality of appearance to such users without unnecessarily avoiding features that would benefit users with more capable browsers. As such, features which would cause content to be hidden or corrupted when CSS and/or JavaScript is unavailable must not be used. This includes techniques such as the hiddenStructure method for hiding table content – which produces incomprehensible output without CSS – and some implementations of the NavFrame collapsing code – which can make content inaccessible without JavaScript support. However, consideration for users without CSS or JavaScript should extend mainly to making sure that their reading experience is possible; it is recognised that it will inevitably be inferior.

To accomodate these considerations, test any potentially-disruptive changes with JavaScript and/or CSS disabled. In Firefox, this can be done easily with the WebDeveloper extension; JavaScript can be disabled in IE in the 'Options' screen. Be particularly careful with inline CSS effects, which are not supported by several browsers, media, and XHTML versions.

”

Adding this to the #Tables section:

“

Scrolling and collapsible sections

Scrolling and collapsible sections in tables or other block elements can be useful to save space and conceal at first-sight potentially superfluous information. However, such techniques must be used with caution, as this content can become inaccessible in a number of situations. Printers and screen-readers will both output only the content that is immediately visible on the page, and these structures are more likely to exhibit undesirable behavior on certain browsers. As such, these methods should not be used in the article body. This includes reference lists, image galleries, and image captions; they especially should not be used to conceal 'spoiler' information (see Wikipedia:Spoiler). Collapsible sections are useful in navboxes and infoboxes and are widely used outside the article namespace; in these instances, care should be taken to ensure that the content will still be acessible on devices which do not support JavaScript and/or CSS.

”

Integrating the resolution point is a bit trickier, there isn't really anywhere obvious to add it on to. I'd propose the following text, but am open to suggestions as to where to put it.

“ Wikipedia articles should be accessible to readers using devices with small screens, or to readers using monitors with a low resolution. The lowest resolution that it is considered possible to support without adversely affecting other users is 800x600; all articles should look acceptable at this resolution without excessive horizontal scrolling. This is sometimes an issue in articles with multiple images on both sides of the screen; although lower resolutions will tend to stretch paragraphs vertically, moving images apart in that direction, be careful not to add images or other floating content on both sides of the screen simultaneously. Large tables and images can also create problems; sometimes horizontal scrolling is unavoidable, but consider restructuring wide tables to extend vertically rather than horizontally. ”

I think this covers most of my concerns; as I say, this is all standard practice already, so it's not instruction creep to codify it. Thoughts? Happy‑melon 17:39, 25 January 2009 (UTC)

Sounds good to me. The suggested changes just codify standard practice, as you said. The only time I ever need to use HTML instead of wiki markup is to make proper HTML lists, like at Diabelli Variations, so maybe that can be mentioned. Graham87 08:09, 26 January 2009 (UTC)

Accessibility icon

Access icon

Hi. I'd like to suggest adopting the Gnome icon to represent accessibility issues in Wikipedia. Please discuss at the WikiProject. —Michael Z. 2009-01-25 19:17 z

JAWS and Section Titles

Hi, in this article it says that earlier versions of JAWS can't read links in titles. How early? Are any of those versions still used? Spinach Monster (talk) 20:12, 31 January 2009 (UTC)

If I remember right, versions below JAWS 7.1 have this problem. They are still occasionally used, even though JAWS 10 is the latest version now. I can check if you want to know the exact details, but it takes a while to download and install each JAWS version to check them. Graham87 04:39, 1 February 2009 (UTC)

I was just curious how many people still likely use 7.1 or below. Spinach Monster (talk) 16:48, 1 February 2009 (UTC)

I would say about a third of JAWS users still use these old versions, but it's just a rough guess. Upgrading costs money, and many blind people can't afford to upgrade. Now that I think about it, there's not much of a problem with links in heading titles, because of the way the edit links in headings have been positioned since October 2006 (see Bug 11555 which should be fixed at some point). Users of older JAWS versions will hear "edit" or "left bracket" when they navigate between headings. I have heard other reasons for avoiding links in section titles, but I can't remember what they are, or if they have anything to do with accessibility. Graham87 01:05, 2 February 2009 (UTC)

It was probably because they used to break the section links found in some edit summaries, but I think the bugs related to that have all been corrected. Of course we still don't want to use templates or images or html tags or any of the various other crap people put in section titles. — CharlotteWebb 22:52, 21 February 2009 (UTC)

Colours on time zone maps

I've raised on issue at WP:TIME where Andy has suggested I post here too. I've got red-green colour-blindness and I find some colours on the CIA World Factbook maps used on a number of timezone articles difficult to distinguish. For example, on the map File:Timezoneswest.PNG used in North_American_Central_Time_Zone, I find it hard to distinguish between the green and brown colours used for the two central time zones in North America. The caption where the image is including in the article contains a colour block which, to my eyesight, doesn't obviously match any of the colours on the map. Are people here able to provide guideines to the WP:TIME people on colour use and make changes themselves if necessary?--Peter cohen (talk) 00:51, 4 February 2009 (UTC)

Well, the brown color appears to match to me, but that's not the point. Can you see the red lines, or would you be able to see them maybe if they were thicker and the green and brown were not so dark? — CharlotteWebb 22:56, 21 February 2009 (UTC)

Sorry I missed this reply. I can on that map but with File:Timezones2008.png, I need to peer closely to notice that the national borders are in different coloours depending on whether they are a zone border or not, and when it is embedded in an article, I really wouldn't know.--Peter cohen (talk) 13:06, 17 June 2009 (UTC)

Plan to reduce heading-example box

17-Feb-2009: In the section named "Headings", the example-box showing 3 columns about Correct, Random or Skipping has been too wide to fit beside the infobox on 800x600 width windows. I suggest reducing to just 2 narrowed columns (total width=63%) as "Correct" & "Random/skipping" so that the narrowed box could fit beside the infobox on 800x600 resolution windows. See comparison below:

  Wide box of 3 columns (version of 16-Feb-2009):

Correct	Random/chaotic	Skipping levels
[Article lead here] ==Section== [level 2] ===Sub-section=== [3] ==Section== [2] ===Sub-section=== [3] ====Sub-sub-section==== [4] ==Section== [2]	[Article lead here] ====Section?==== [4] ===Section?=== [3] ==Section?== [2] ==Section?== [2] ====Section?==== [4] ===Section?=== [2]	[Article lead here] [Level-2 section missing here] ===Section?=== [3] ==Section== [2] [Level-3 sub-section missing here] ====Sub-section?==== [4] ==Section== [2]

  Narrow box (proposed):

Heading use (and misuse) examples

Correct	Random/skipping
[Article lead here]   ==Section== [level 2]   ===Sub-section=== [3]   ==Section== [2]   ===Sub-level3=== [3]   ====Sub-level4==== [4]   ==Section== [2]	[Article lead here]   ====Section?==== [4]   ===Level 3=== [3]   ==Section?== [2]   ==Section?== [2]   [Level-3 heading skipped]   ====Level 4==== [4]

People sometimes forget to test the appearance of tables using the 800x600 screen-width that was the majority of user-screens in 2005, so tables are often formatted as assuming people want to display in wide windows. By combining the examples of Random & Skipping (into a single column), those prior 2 columns can be reduced to 1 column. If there are no objections, I suggest replacing that 3-column table ASAP as 2-columns, by copying the 2-column table coding from inside this message. -Wikid77 (talk) 10:28, 17 February 2009 (UTC)

W3C WAI-ARIA suite

Using the W3C WAI-ARIA suite link WAI ARIA Overview simplifies interaction for the blind and enhance keyboard navigation. To define landmarks/regions in the Wikipedia interface (MediaWiki) would enable user rapidly jump from one logical section to another. Furthermore an ARIA-based formatting toolbar in the editing page would simplify interaction via screen reader. Maribu2009 (talk) 22:52, 18 February 2009 (UTC)

This page mainly concerns accessibility in article content, and presents guidelines for content editors. You might also be interested in the general behaviour of the MediaWiki software which runs Wikipedia – the website is at mediawiki.org. —Michael Z. 2009-02-19 00:42 z

Transparent layers

I think that transparent layers should not be used in wikipedia images as this mixes the content of an image with the colour of the web page. I browse the web with the browser and operating system set to white text on a black background, and this means that many images with transparent layers are unviewable. Also the keys to maps becomes invisible. Images would be accessible if they use the full colours that the images are supposed to represent instead of using transparent layers which rely on the web page background colour.

For discussion of this see: Wikipedia:Village pump (proposals)#Transparent backgrounds in images. Charvest (talk) 17:44, 22 February 2009 (UTC)

Flag icons and accessibility

In WP:WikiProject Flag Template, we made sure that flag icon images (e.g. {{flagicon|UK}} to render ) have the alt attribute set, per WP:Accessibility#Images. But is that actually desired? For example, I've seen comments where tables or lists such as:

• France
• Brazil
• etc.

are not good examples for accessibility because a screen reader will say "Flag of France France" and so on. Not being a screen reader user, is that the case? Is it any better if {{flag}} is used instead of {{flagicon}}, such as:

• France
• Brazil

Looking for guidance on how these templates should render these icon images. Thanks — Andrwsc (talk · contribs) 20:33, 25 February 2009 (UTC)

It'd be better if the flag templates had the alt images. What would be even better is if the flat templates could be imagemaps, so all a screen reader user would here is "flag of France", and when someone presses enter on that link they get taken to the France article. As a screen reader user, I find flag templates distracting, so I think they should be used sparingly. Graham87 05:03, 26 February 2009 (UTC)

{{flagicon}} already works that way, using Mediawiki image syntax (link=) instead of imagemaps. Click on to go to the France article. — Andrwsc (talk · contribs) 05:12, 26 February 2009 (UTC)

That template sounds good then. Graham87 06:07, 26 February 2009 (UTC)

Request for Input

I just created a post that is of prime relevance to the issue of accessibility: Wikipedia_talk:WikiProject_Medicine#Medicalization. I would like to request other editors to come to this page and give their input into this topic. Cazort (talk) 02:58, 1 March 2009 (UTC)

This talk page is for discussing ways of making Wikipedia more accessible to people with disabilities (e.g. vision impairment, dyslexia, motor disabilities). Your notice is more appropriate at Wikipedia talk:Make technical articles accessible. Graham87 05:04, 1 March 2009 (UTC)

MOS:SCROLL duplicated shortcut

Just noticed that MOS:SCROLL claims to be the shortcut for WP:ACCESS#Scrolling and collapsible sections but actually links to Wikipedia:Manual of Style#Scrolling_lists. Which should it be? Am also posting this at WT:Manual of Style#MOS:SCROLL duplicated shortcut as I don't know where the best place for the discussion would be. cheers, Struway2 (talk) 22:38, 3 March 2009 (UTC)

imagemaps

It has come to my attention that certain articles require the reader to "hover" over parts of an image to know what is pictured in it, as opposed to reading a caption, cf [8], [9]. Apparently this was achieved by stuffing the complex image map code into the latter part of the "name" parameter of the infobox, rather than as an image. I don't know why anyone would want to do this but it makes a mockery out of accessibility concerns. — CharlotteWebb 12:45, 22 March 2009 (UTC)

The captions for the image maps do read with screen readers. For example I can hear "Reverend D'Ewes Coke", "Daniel Coke M.P.", "Hannah Coke", "Plans for the new house?" and so on. At least it doesn't use {{Click}}. But I bet it'd be hard to find the descriptions using screen magnification software, and there are probably other accessibility issues. But, like you, my main question is ... why would anyone want to do such a thing? It also should be implemented elegantly, not with a hack through the name field. Graham87 13:57, 22 March 2009 (UTC)

OK, {{Click}} is accessible now. My main objections still stand though. Graham87 13:59, 22 March 2009 (UTC)

I didn't think about that.. I've been asked a number of times to provide image mapping in a number of "List of tallest buildings in <name of city>" Featured lists; List of tallest buildings in Atlanta is one of them. List of universities in Nova Scotia is another. Graham, in what way can these be improved? Matthewedwards (talk • contribs • email) 18:37, 28 March 2009 (UTC)

It would be nice if Template:Image label begin contained space for a caption for screen readers, or some alt text. the tallest buildings in Atlanta list works fine with screen readers, but near the end I hear "File:Atlanta Skyline from Buckhead.jpg" instead of a proper caption. I'm not sure how the imagemaps work with other accessibility devices though; I assume that they do work, because they're so common. Graham87 03:28, 29 March 2009 (UTC)

Teitur Þórðarson

Hi. There's a discussion at Talk:Teitur Þórðarson over whether the article should be retitled Teitur Thordarson. I'm wondering about the accessibility aspect of this question. Thanks in advance for any reply. -GTBacchus^(talk) 15:00, 28 March 2009 (UTC)

Images that toggle

Recent experience indicates that I should preface this question with a disclaimer. What I am about to ask about, I do not consider to be a good idea. I seek technical knowledge of why it's not a good idea. Perhaps there is no technical reason, and the badness of the idea rests entirely on other grounds. That is what I wish to learn.

That said... Is there a specific accessibility issue regarding an image in an article that is placed in a toggle box, so that readers may toggle between two aspects of an image, such as "hide/show" or even something else? Would those pose any problem for screen readers, which presumably are already set up to handle images of the static variety? Thanks in advance for any information. :) -GTBacchus^(talk) 15:16, 28 March 2009 (UTC)

I suspect that it's easier for those who use screen readers to answer when they have an example to process through the screen reader:

• User:Ferrylodge/HideImageInInfobox
• Autofellatio

SandyGeorgia (Talk) 15:21, 28 March 2009 (UTC)

There are no accessibility problems with my modern screen reader. However, the image won't show for people with browsers that don't support CSS and/or JavaScript. Graham87 04:37, 29 March 2009 (UTC)

I just tried out the hide/show box in a couple of non-CSS browsers, and the only issue is that the image won't hide. --Carnildo (talk) 07:15, 29 March 2009 (UTC)

Okay. I guess that means that there's no accessibility problem. Thanks for checking.Ferrylodge (talk) 17:30, 29 March 2009 (UTC)

Check for accessibility?

I've been working on a mathematical article, Euclidean algorithm, and it's now at FAC. I think it's accessible, but I'd appreciate any suggestions for improving it. Thanks! Proteins (talk) 17:35, 30 April 2009 (UTC)

Great work - it sounds good here. However, proper headings should be used where possible, rather than semicolons. Also, I'm concerned about the use of exotic unicode characters - JAWS reads both "γ" and "−" as blank characters or question marks in its default configuration. Graham87 04:04, 1 May 2009 (UTC)

Thanks, Graham, I'm glad you liked the article. By "proper headings", I guess you mean the places where I converted a subsubsection to the beginning of a definition list using a semicolon? I agree, and originally I wrote them as subsubsections. But I became aware of the FAC criterion that tables of contents must not be "overwhelming", and I was concerned that the article would be dinged for that reason. The FAC reviewers seem to take such matters seriously, so that's why there are now only sections and subsections. If the article passes, then I think we can restore the subsubsections without risking an FAR, far from the madding crowd. I'll also make an audio recording, although that won't have convenient navigational links. (Is that possible?)

Do you know of a list of HTML entities that aren't translated by JAWS? If so, I could go through the article and try to find substitutes. I'd like to keep Greek letters such as γ to suggest how different the quaternions are from everyday numbers (which I've depicted with upper- and lower-case Latin letters), but there are likely good alternatives, such as using boldface type or something. Your suggestions would be very welcome! Proteins (talk) 15:17, 1 May 2009 (UTC)

The number of levels of section heading appearing in the table of contents can be limited using {{TOClimit}}, as described at Help:Section#Limiting the TOC, if that would help at all on the subsection headings problem. cheers, Struway2 (talk) 15:26, 1 May 2009 (UTC)

Yes, that would be an acceptable solution to the TOC problem for me. As for unicode characters, I don't know of a full list, but any characters in Windows-1252 will be read by default, as well as some odd astericks and quotes, and, for some reason, all the letters in the Arabic alphabet. Using bold to indicate the differences between the quaternions and other numbers would be a good idea, as long as you indicate the purpose of the bold font in the text. Graham87 15:52, 1 May 2009 (UTC)

Super scripts

I have only mild presbyopia as do most seniors. I have a lot of trouble with superscripts such as in m² and m³. These things appear in may articles. The authors of the {{convert}} template were thoughtful enough to use HTML superscript like m² and m³. I find this much easier to read. Though it means that many articles would need to be edited it is not an impossible task. A bot could do the job unattended. --droll [chat] 19:25, 9 May 2009 (UTC)

I believe WP:MOSNUM discourages the use of the harder-to-see unicode superscripts. Whenever I see them, I change them to the HTML version. Agree that a bot run on these would be helpful. Dabomb87 (talk) 23:51, 2 June 2009 (UTC)

Could someone take a look please

Over at WP:CYC we are trying to establish a template for articles on races. A habit has emerged over using coloured backgrounds in tables to indicate holders of the various jerseys used to denote honours and competition leadership. See, for example 2008 Tour de France or 2008 Giro d'Italia, and especially the Jersey progress sections of each. I believe that we should indicate far more clearly a key for the significance of these colours, but I come here in search of your expertise on the suitability of these background colours for those with colour perception difficulties. If you give any observations here I will post them across to our discussions: if you wish to post directly, we have started the discussion at User_talk:Nosleep/Style_guide/Short_stage_race. Many thanks, Kevin McE (talk) 06:55, 12 May 2009 (UTC)

I'm totally blind, and can't see anything at all, let alone colours. I believe that a textual hint should be provided to accompany the colour coding, for people like me. Also the images of the Jerseys in the progress section could do with alt text, like "yellow jersey", "white jersey", etc. Just some preliminary thoughts. Graham87 14:11, 12 May 2009 (UTC)

Using flagicon in section headers?

Does using {{flagicon}} in section headers compromise the accessibility of articles in any way? Refer to 2008 IIHF World Championship rosters. Dabomb87 (talk) 23:52, 2 June 2009 (UTC)

Yes, it makes a section title read as for example "Flag of Denmark Denmark" for screen reader users. Section titles have been messed up since October 2006 (see T13555); the flag icons inside headings make the problem even worse. Graham87 01:29, 3 June 2009 (UTC)

Resolution

The article currently says the minimum resolution should be 800x600 and from a discussion above and looking at the history, I see this was added relatively recently (January) with the claim it's the current consensus. While I respect that this was done with the best intentions, I have to disagree with it and the claim it has consensus. I have taken part in multiple discussion on this particularly with regard to the failed redesign of the main page and I've never seen any evidence for any real consensus other then the allegation made via poor sources that less then 1% of users have 640x480 (which ignores a wide variety of things like SDTVs with 720x576/720x480, resolutions of 800x600 without a maximised window, people using large text sizes meaning that even with a resolution of 800x600 or larger, the aiming for 800x600 could easily cause problems). More to the point, I've also seen no clear explaination or examples as to the harm of aiming for 640x480 as a minimum. If there's been some very wide reaching discussions that I've missed or if there are a large number of pages which don't work at 640x480 then I would be willing to accept it's a consensus that I've missed but if not, then I would dispute the notion there is any consensus and would suggest we bring this down to 640x480. As far as I'm aware, this is the resolution many pages, e.g. the current main page, set as their minimum during design and while this may be a while ago, I don't see any reason to change that without strong evidence for harm or necessity. Being VGA mode, it's also the minimum you're likely to use for the vast majority of normal displays, including old ones like 14 inch CRTs which may not be that uncommon in the developing world as well as should have some support with any resonable GUI. Nil Einne (talk) 21:00, 3 June 2009 (UTC)

N.B. The only survey/poll I've come across so far is this one relating to the main page redesign Wikipedia talk:2008 main page redesign proposal/Survey and perhaps the multiple discussions in the archives Wikipedia talk:2008 main page redesign proposal#Technical considerations, Wikipedia talk:2008 main page redesign proposal/Archive 2#Elements (several brief discussions), Wikipedia talk:2008 main page redesign proposal/Archive 2#Background color, Wikipedia talk:2008 main page redesign proposal/Archive 2#Survey results, Wikipedia talk:2008 main page redesign proposal/Archive 3#640x480 Nil Einne (talk) 21:35, 3 June 2009 (UTC)

An additional point which I've realised from rereading the discussions and considering recent developments, with the rise of netbooks, and similar devices with small screens and resolutions commonly between 800x480-1024x768, as well as things like the OLPC (resolution 840x630) and the Starter editions of Windows with a 800x600 maximum this mean that frequently made (although IMHO lacking in examples) claim that ensuring support for 640x480 will harm the large majority with significantly larger displays may in fact becoming less of a factor (and of course it always ignored the fact that someone with a large screen may not have a maximised window) since even though none of these are 640x480 they clearly are not going to benefit from something optimised for a large window. And of course, with these devices with ~800x600, we also have the consideration of an unmaximised window (I appreciate that you probably don't want too many background tasks and in fact with Starter editions of Windows you can't but it doesn't mean people will never have an unmaximised window). Also when rereading about the OLPC I remember another thing. It's possible to use the OLPC in horizontal mode. I presume it's also the case with some netbooks and especially tablet devices or will be in the future. While this is probably not so much of a concern with main page viewing, it is a concern with articles. This means we could easily end up with 630x840 for the OLPC (and the horizontal i.e. 630 is what we really care about) and e.g. 600x800 or 768x1024 with netbooks and tablets. In other words, the more I think about it, the worse an idea it seems to be for use to ignore 640x480 Nil Einne (talk) 22:02, 3 June 2009 (UTC)

Tooltip template

I've just been reading List of Hannah Montana episodes and came across a template I've never seen used before: {{explain}}, a redirect to {{tooltip}}, used for explanatory text when the cursor hovers over the word. How does this works with JAWS and other screen readers on an ACCESS level, and also, wouldn't it be better to use explanitory footnotes instead? Matthewedwards :  Chat  18:49, 6 June 2009 (UTC)

It doesn't work at all with JAWS; at least I can't figure out a way to use the example at the tooltip template. Yes, it'd be better to use footnotes. Graham87 05:00, 7 June 2009 (UTC)

Thanks. I'm going to go through Special:WhatLinksHere/Template:Tooltip and convert them to footnotes and take the templates to TfD. There's no point keeping something that doesn't work when there is a perfectly good system in place that does. Matthewedwards :  Chat  00:32, 8 June 2009 (UTC)

Proposal to mention alt text in featured-article criteria

Should the Wikipedia featured article criteria require alt text for images? I've raised this issue in Wikipedia talk:Featured article candidates #Alt text in images; if you're interested, please follow up there. Eubulides (talk) 23:01, 23 June 2009 (UTC)

Collapsible boxes

FYI: Rules were recently added to MediaWiki:Print.css to expand boxes on printing; this of course does not apply to those that are classed as nonprintable such as navboxes. ---— Gadget850 (Ed) ^talk 11:30, 25 June 2009 (UTC)

Excellent, thanks! -Philcha (talk) 13:25, 25 June 2009 (UTC)

Pictures as symbols?

Is the usage of images as symbols as seen at List of cardinal-nephews compliant with WP:ACCESS? Dabomb87 (talk) 17:36, 3 July 2009 (UTC)

No, it'd be better if they used alt text. Graham87 04:36, 4 July 2009 (UTC)

Template:Infobox Football biography

The tables in {{Infobox Football biography}} need to be subdivided so that each line occupies its own table-row (examples: 'Senior career' and 'teams managed' in Andy Preece). I seem to recall a project specifically looking at such issues, can anyone tell me where that is, please? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:31, 23 July 2009 (UTC)

It's at Wikipedia:WikiProject Usability/Infobox accessibility. Graham87 01:06, 24 July 2009 (UTC)

Many thanks. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 06:27, 24 July 2009 (UTC)

Accommodations for photosensitive epilepsy

Somehow I ended up in a discussion at WP:IHC about potential "involuntary health consequences" from Wikipedia content. While I opposed that proposal, there does seem to be fairly widespread concern about the potential for flashing images with regularly spaced stripes to cause trouble in some viewers. The issue has previously been raised on this talk page at Wikipedia talk:Accessibility/Archive 1#Animated Picture of the Day, Wikipedia talk:Accessibility/Archive 1#Blinking text Wikipedia talk:Accessibility/Archive 4#Moving images, and Wikipedia talk:Accessibility/Archive 7#Animated image in essay. It is also discussed at [10]. I think it may be time for something to be written in the policy to reflect all this discussion.

Some of the images mentioned in those discussions include Image:Strobe.gif, Image:Tablet press animation.gif, File:Translational_motion.gif and Template:POTD_protected/2007-05-14. One of the most famous triggers for photosensitive epilepsy was the famous Dennō Senshi Porygon broadcast, for which animation is available at the article page.

The guidelines discussed in the archive are based on the Web Content Accessibility Guidelines against flashing text. This is referenced in the WP:IHC proposal as section 2.3.2 (AAA)[11], which says that no part of the Web page should flash more than three times. This is a stringent criterion that may exclude useful graphical illustrations for many articles. A much looser standard has been used by the British ITC (The Harding Test[12]) which restricts the percentage of the screen taken up by flashing patterns, especially those made up of regularly spaced lines.

My general feeling is that this can't really be solved with Wikipedia policy because most people who create these images won't have the faintest idea that they could be a problem. However, in fairness, accessibility guidelines could try to limit the hazards posed by the most troublesome images.

I'd like to propose an advisory guideline to be inserted just before "Keyboard shortcuts", which I've written in a non-binding way:

Photosensitive epilepsy

It has been reported that users with photosensitive epilepsy can use modern computer monitors set to a refresh rate of 75 Hz or above safely without risk of seizure. Nonetheless, certain flashing images, particularly those containing regular patterns of lines, pose a risk to these viewers.

Those susceptible are strongly urged to take precautions on their own computers to protect themselves from such triggers. Some pages (such as Horse gait) display animations which play directly upon loading unless the user's Web browser settings prohibit it. Many potential editors will not think about epilepsy when adding animations to an article.

Web Content Accessibility Guidelines Section 2.3 discourages the use of text or images which flash between bright and dark values more than three times per second. Guidelines established for other media, such as the ITC Guidance Note for Licensees on Flashing Images and Regular Patterns in Television, have advised caution when displaying regular striped patterns over more than 40% of the screen area or flashing striped patterns over 25% of the screen area. Wikipedia editors can improve the safety and accessibility of Wikipedia by considering these recommendations.

I welcome your comments. Mike Serfas (talk) 02:14, 4 August 2009 (UTC)

Removing alt text requirement for featured articles

There's an active discussion in Wikipedia talk:Featured article candidates about whether we should remove the requirement that featured articles have alt text to help visually impaired readers. In that discussion, please see the sections Alt text in images through Alt text for portraits, particularly the wording changes being proposed in Where things stand. I am interested in feedback about the claims in this discussion that alt text does not help visually impaired readers. Eubulides (talk) 17:51, 5 August 2009 (UTC)

Unicode characters and screen readers

A recent edit added this text:

'Do not use Unicode characters as icons, use an icon with alt text instead. For example, a character like "→" can not be reproduced into useful text by a screen reader. Concerning the footnotes, "^" should be replaced by an icon with appropriate alt text, such as "back to text".'

So I'm curious: what does a screen reader typically do when it's given text with unusual characters? Here are three examples: (1) "→"; (2) "^"; (3) "²".

Also, I don't agree with the proposal to replace "^" with an icon. Let's put it this way: the "^" is not an essential part of the article and doesn't need heavyweight support. Or another way: it's just as confusing for sighted readers as for the visually impaired, so there's no WP:ACCESSIBILITY argument for using an icon. Eubulides (talk) 00:28, 22 August 2009 (UTC)

When JAWS encounters an uncommon character, it will always read it out if it knows how to. JAWS recognises all Windows-1252 characters and some Unicode characters by default, but it's possible to add text for all Unicode characters - see this FAQ from the Freedom Scientific website, for example. When it encounters a character which doesn't have text defined for it, it reads the character as a question mark. So it says your first example as a question mark, your second example as "caret" (pronounced like "carrot", and your third example as "superscript two". I've encountered the ^ character for most of my computing life - I've always loved talking calculators. But now that I think about it, I wonder if many blind people would be confused by the similarity between the word "carrot" and the pronunciation of the symbol "^"? It's not a common character after all.

I don't really agree with the proposal to replace the "^" with "back to text" if the "^" is just as confusing for sighted readers as it is for screen reader users. Graham87 15:39, 22 August 2009 (UTC)

I have similar footnotes and "return" links on this West Midland Bird Club page, but numbered for uniqueness, and with title attributes. I'd be grateful for your comments, and thoughts on how they might work on Wikipedia. I've also thought of using the "abbr" element. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 19:25, 22 August 2009 (UTC)

• I've run into similar problems when doing alt text for math. For example, for the square root of the discriminant formula "${\sqrt {b^{2}-4ac}}$", plausible alt texts include:

• "√(b²−4ac)". That is, render the formula into Unicode text as accurately as possible, using fancy Unicode characters.
• "sqrt(b**2 - 4*a*c)". That is, render the math into a FORTRAN-like ASCII notation.
• "\sqrt{b^2-4ac}". That is, just copy the AMS-LaTeX input into the alt text! This solution is the simplest and most general but it requires the visually impaired reader to grok LaTeX.

Graham, do you prefer any of the above solutions? Now that I've thought about it, I'm starting to lean towards the last proposal, as it handles any kind of formula whereas the other methods tend to fail with advanced math.

• Another issue is images that contain unusual characters. For example, File:Yuan character (1st century).png is an image of a Chinese character, and the most concise alt text is something like "The Chinese character '袁'". Most likely this renders as "The Chinese character '?'" in your JAWS installation, but perhaps we should just leave it at that. As I understand it from the Freedom Scientific FAQ you cited, people who care about Unicode will install the full Unicode pronunciations and get something useful for that character, while people who don't care that much will hear a question mark which is perhaps the best we can do concisely anyway.

Eubulides (talk) 21:37, 22 August 2009 (UTC)

Or "square root of (b squared, minus four times a times c)". Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 21:43, 22 August 2009 (UTC)

Andy Mabbett, your solution is pretty good for non-blind users, 'cause "return to point 1" will be displayed in a tooltip when the mouse is over it. Concerning visually impaired users, the answer is unclear and pretty complicated, but of course it's better than nothing. For now, assistive technology does not support title attributes in links. But be aware that assistive technology is in development, and improves as demand expand. So provinding title attributes in links is not a bad idea at all. See H33: Supplementing link text with the title attribute, techniques for WCAG 2.0.

"JAWS 7.0 and above will speak the value of title attributes depending upon a JAWS setting. This setting can be changed temporarily or permanently within JAWS." I have a question for Graham87: do you use JAWS 7.0 or above, and did you decided to have JAWS speak the value of the title attribute ?

Eubulides, it is hard to know if it is as confusing for sighted user as bling users. Does a blind user knows the symbol "^" points upward? The symbol shows clearly to a sighted user that the link will take him back upward, which implies it will take hib back to the text. Yours, Dodoïste (talk) 22:12, 22 August 2009 (UTC)

When I first saw the "^" I thought it was meaningless noise. I didn't find out until later that it often (but not always) has a function. I'm just one data point, of course. Eubulides (talk) 04:23, 23 August 2009 (UTC)

I use JAWS 8.0. It allows me to read the link titles, but I don't have it set to do that and it always reads the screen text of links by default. Unfortunately there's no easy way to read a link title by using keystrokes.

As for alt text in math images, if the images involve simple arithmetic like "1 +1 =2", then use that as the alt text. I prefer the use of LaTex for the discriminant formula; I'm not a fan of option 1 and I can only read option 2 because I'm an experienced programmer. Graham87 08:10, 23 August 2009 (UTC)

Thanks, that sounds like the best suggestion for math alt text so far, and I'll try to work that into WP:ALT. Eubulides (talk) 08:28, 23 August 2009 (UTC)

Also, there are some types of equations that sound hideous in LaTeX but are easy to put into words. "7 choose 4" for binomial coefficients and matrices are things that come to mind. For matrices, I would suggest having alt text like this: "(3, 4, 8). (5, 6, 0). (9, 8, 11), where parentheses indicate the start and end of each row - the right parentheses should be followed by a "." for readability. The columns should be separated by commas. A system like that would make reading some articles much easier for me. Graham87 15:51, 23 August 2009 (UTC)

Hmmm, the "R choose N" examples don't sound as bad in LaTeX as I thought they did. Still, IMO they're an easy case for alt text. Graham87 15:55, 23 August 2009 (UTC)

Just for informational purposes, my wife, who has a severe visual impairment, uses a screen enlargement/reader combination program called ZoomText. In its current configuration, it ignores unicode entirely when in screen-reading mode. -Dewelar (talk) 00:21, 23 August 2009 (UTC)

Yeouch. For information, which version of ZoomText and Windows is she using? and which browser? KB#124 says that ZoomText doesn't support Unicode on Windows 9x and ME unless you install something else from Microsoft. I would expect newer software versions would work, though one may have to adjust a setting. A recent blog entry by a Penn State accessibility expert says that Unicode text is better than images for zooming math text, but she's assuming of course that zooming works. Eubulides (talk) 04:23, 23 August 2009 (UTC)

She uses version 9.01 (the version before the current one) of ZoomText, Windows XP Home (SP3) and Firefox 3 (IE7 for some things). -Dewelar (talk) 05:13, 23 August 2009 (UTC)

Math formulas and images with text

Following up on the above discussion, I added two sections to the alt text guidelines. WP:ALT#Math discusses math formulas and follows Graham's suggestion in saying that simple formulas are an easy case for alt text, whereas complex ones may be better rendered as the LaTeX. As it happens, if you don't specify alt text for a math formula, it defaults to the LaTeX, so that simplifies matters. WP:ALT#Text discusses images containing prominent text, Unicode, etc. I had the most fun writing the suggestion that alt text say "Spiral staircase" rather than "꩜ ▁▂▃▄▅▆▇█"; that latter quote is valid Unicode but it doesn't even render correctly on my browser, which is the latest Firefox. Further comments here (or at WT:ALT) are welcome. Eubulides (talk) 17:10, 31 August 2009 (UTC)

Thanks, sounds good. Graham87 01:18, 1 September 2009 (UTC)

Calendar pages

How might we improve the accessibility of pages like Common year starting on Saturday? Leap year starting on Sunday which uses {{Year3}}, seems better, but barely so. Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 13:03, 31 August 2009 (UTC)

First of all we need to use an accessible table, like the following example. Dodoïste (talk) 14:23, 31 August 2009 (UTC)

January

	Mo	Tu	We	Th	Fr	Sa	Su
Week 1						1	2
Week 2	3	4	5	6	7	8	9
Week 3	10	11	12	13	14	15	16
Week 4	17	18	19	20	21	22	23
Week 5	24	25	26	27	28	29	30
Week 6	31

Indeed - but sureley that also needs <abbr> elements for the day-names? Andy Mabbett (User:Pigsonthewing); Andy's talk; Andy's edits 14:38, 31 August 2009 (UTC)

Oh, thanks for showing me, I didn't know that. It seems to be very useful, but unfortunately MediaWiki doesn't know what to do with it. See, if I type "<abbr title="Monday">Mo</abbr>", the result is Mo... Should we fill a bug at bugzilla about it ? Dodoïste (talk) 15:04, 31 August 2009 (UTC)

First, that abbr should be an attribute of the th element, no? That is, "<th abbr="Monday"...>Mo</th>". Second, those "Week 1" row headers are a big distraction to the sighted reader; shouldn't they be made invisible? Eubulides (talk) 17:19, 31 August 2009 (UTC)

Eh, it's getting a little complicated for me. :-) Please go ahead, I'll learn while observing. Dodoïste (talk) 18:06, 31 August 2009 (UTC)

Sorry, I don't know how to do either thing under the Mediawiki constraints. Perhaps a real expert can step in? It may require fixes to the .css or to Mediawiki itself. Eubulides (talk) 18:56, 31 August 2009 (UTC)

← Visually, this may be better:

January

Week	Mo	Tu	We	Th	Fr	Sa	Su
1						1	2
2	3	4	5	6	7	8	9
3	10	11	12	13	14	15	16
4	17	18	19	20	21	22	23
5	24	25	26	27	28	29	30
6	31

Yes, thanks, that is better. Still, the week column must go (i.e., it should be made invisible to the sighted reader). Eubulides (talk) 19:31, 31 August 2009 (UTC)

I'm not very familiar with the table for now. So here are a few references on topic, pointed out by an accessibility expert in a french manual he wrote to make accessible table. It might be helpful.

1. H63: Using the scope attribute to associate header cells and data cells in data tables
2. H39: Using caption elements to associate data table captions with data tables
3. H43: Using id and headers attributes to associate data cells with header cells in data tables
4. H73: Using the summary attribute of the table element to give an overview of data tables

Dodoïste (talk) 21:49, 31 August 2009 (UTC)

I like the second table the best because it's briefer - the row headings can sometimes be distracting. Braille and large print calendars are very popular with blind people, so reading accessible calendars on Wikipedia shouldn't be hard for them; I don't think many people would use the <abbr> element. It'd be nice if we could avoid redundant rows; most months only need five rows, and some Februaries only needs four. In English-speaking countries, calendars have Sunday first, not Mondays as is true in European countries IIRC. Graham87 01:15, 1 September 2009 (UTC)

Rejoice : abbr element is now implemented in MediaWiki!

January

Week	Mo	Tu	We	Th	Fr	Sa	Su
1						1	2
2	3	4	5	6	7	8	9
3	10	11	12	13	14	15	16
4	17	18	19	20	21	22	23
5	24	25	26	27	28	29	30
6	31

The abbr element was implemented in the last MediaWIki update! That's great news See bugzilla:671, the community was asking fot that element since 2004. So I just made a new table using the abbr element. See H28: Providing definitions for abbreviations by using the abbr and acronym elements, Techniques for WCAG 2.0, W3C for further information.

By the way, the abbr attribute in a td element does the opposite of the abbr element : it is made to display an abreviation of a long header content to the screen reader. "When table header content is repeatedly rendered by the user agent, the content of the abbr attribute should be rendered in place of table header content." See the ABBR attribute for TH elements, WAI, W3C for further details on how to use it. Yours, Dodoïste (talk) 20:43, 28 September 2009 (UTC)

Yay! :-) This should be more widely used. JAWS expands the abbreviations in the table above correctly. However I wish it would let the user know if there was an abbreviation, because by default it completely ignores the <abbr> element unless you tell it otherwise, at least with my copy of JAWS 8. That's not a MediaWiki problem though. Graham87 13:54, 29 September 2009 (UTC)

I changed Template:Circa to use <abbr> instead of a Wikilink. That is, "{{circa|1100}}" used to output "c. 1100"; now it outputs "c. 1100". This is better for sighted readers as it uses the more-common mechanism for abbreviations; I hope it's OK accessibility-wise. Eubulides (talk) 16:34, 29 September 2009 (UTC)

Sounds good to me. Graham87 04:59, 30 September 2009 (UTC)

Wikipedia talk:Lead section#Elements in the lead: where should the protection template go?

Please see and comment. Thanks, –xeno^talk 14:55, 31 August 2009 (UTC)

Left-aligned images under subsection headers and image squeezing

Please clarify at [13]. Thanks, Dabomb87 (talk) 13:32, 13 September 2009 (UTC)

As a result of that discussion, the requirement was removed from the MoS, so I've just now removed it from here, to maintain consistency. Eubulides (talk) 04:55, 16 September 2009 (UTC)

Images in section headers

Resolved

Is it a problem to use images in section headers, such as Wikipedia:WikiProject Lancashire and Cumbria? Dabomb87 (talk) 22:11, 16 September 2009 (UTC)

I guess so: From the Images accessibility section: "Images should be inside the section they belong to (after the heading and after any links to other articles), and not in the heading." I think you were right to remove them. Rambo's Revenge (talk) 22:14, 16 September 2009 (UTC)

That excerpt surely applies to article to prevent images from becoming dissociated with the relevant text? In this instance, images were being used as decoration on a WikiProject page so I don't think that applies. I must admit though that accessibility isn't something I had thought about when the images were added to the start of the section headers. What kind of problem do people envisage? The Lancashire and Cumbria project isn't the only one to use images in such a way, I'd always just assumed it was ok. Nev1 (talk) 22:24, 16 September 2009 (UTC)

If they're purely decorative (as is clearly the case here), then they should be marked with |link= as per WP:ALT #Purely decorative images. I did that. I don't see an accessibility issue once this is done. You might want to let other projects know about |link=, if they use this style. Eubulides (talk) 22:36, 16 September 2009 (UTC)

OK, thanks to everyone for the clarification. Dabomb87 (talk) 22:45, 16 September 2009 (UTC)

I've already done it for one project and will do it for the others I know about. Thanks for the help. Nev1 (talk) 22:51, 16 September 2009 (UTC)