Wikipedia talk:Manual of Style/Accessibility/Archive 5

Archive 1

←

Archive 3

Archive 4

Archive 5

Archive 6

Archive 7

→

Archive 10

Let me just throw a suggestion out

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

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

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

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

2008 main page redesign

Copied from WP:VPT:

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

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

IPA in Jaws

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

• Getting JAWS 6.1 to recognize "exotic" Unicode symbols

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

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

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

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

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

Template 'Unsigned' - text too small.

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

Template for Line 1 of the Monterrey Metro

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

Style cat

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

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

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

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

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

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

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

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

A test

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

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

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

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

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

Fractions

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

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

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

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

Accessibility of NavFrame

I raised an issue at Wikipedia talk:NavFrame:

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

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

collapsible sections and accessibility for sight impaired folks

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

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

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

Help with a geometry article?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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