# Wikipedia talk:Manual of Style/Accessibility

WikiProject Manual of Style
This page falls within the scope of WikiProject Manual of Style, a drive to identify and address contradictions and redundancies, improve language, and coordinate the pages that form the MoS guidelines.
WikiProject Accessibility
This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.
the Wikipedia Help Project (Rated B-class, Mid-importance)
This page is within the scope of the Wikipedia Help Project, a collaborative effort to improve Wikipedia's help documentation for readers and contributors. If you would like to participate, please visit the project page, where you can join the discussion and see a list of open tasks. To browse help related resources see the help menu or help directory.
B  This page does not require a rating on the project's quality scale.
Mid  This page has been rated as Mid-importance on the project's importance scale.

## Font size

I would like to add the following section under text:

The use of font size reducing markup or templates should be used sparingly. In no case should the resulting font size drop below 11px (85% on systems using 96 dpi display setting) to avoid illegible text. A common mistake is the use of smaller font sizes (using {{small}} or inline CSS) inside infoboxes and navboxes, which already use a smaller font size.

Comments? Edokter (talk) — 18:03, 4 January 2014 (UTC)

On second thought, it would be better served at Wikipedia:Manual of Style/Text formatting. Though a hatnote referring there would be appropriate. Edokter (talk) — 18:18, 4 January 2014 (UTC)
It should be here as it is an accessibility issue. I have problems reading smaller text sizes and have to increase the web browse size to read things. A hatnote should be at the Text formatting page.
This has been talked about before, but never implemented. It should be.
I'd only mention that it shouldn't drop below 85% or 11px, so as not to get too complicated.
Other places that reducing the size shouldn't be used is in image text, <sup>, <sub> and reference section that use {{Reflist}} or <references />... Anotherwords, wherever the font size is reduced, it should be avoided to reduce even more. Bugs me to no end that some reference sections are so small that I can't read the dang thing. Bgwhite (talk) 19:22, 4 January 2014 (UTC)

2nd draft:

The use of reduced font sizes should be used sparingly. Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. In no case should the resulting font size drop below 85% of the page fontsize (or 11px).

I think it may be important enough to include it in both pages. Edokter (talk) — 20:07, 4 January 2014 (UTC)

Looks good. Bgwhite (talk) 22:11, 4 January 2014 (UTC)
That's a good summary of the conclusions of several discussions that I remember, so I'd be in favour of adding that guidance to editors. I'd put it in both pages with a hidden comment on each pointing to the other page to help future synchronisation. --RexxS (talk) 05:04, 5 January 2014 (UTC)
As I said at Wikipedia_talk:Manual_of_Style/Text_formatting#Font_size, talking to editors about point sizes and pixel densities is pointless. Just provide guideance about what to do or not do in wiki source. Dicklyon (talk) 05:31, 5 January 2014 (UTC)
Is "Avoid using smaller font sizes in elements that already use a smaller font size" not enough? I could add a ref explaining 11px, or add an image to illustrate. But the core is already explained in that sentence. Edokter (talk) — 10:57, 5 January 2014 (UTC)
a good example of this problem can be found here. Frietjes (talk) 21:11, 6 January 2014 (UTC)
Seeing that has no objections, and apparently has been discussed before, I'm addin git to both pages. Edokter (talk) — 21:40, 6 January 2014 (UTC)
No objections? Why are you ignoring mine? Dicklyon (talk) 03:41, 7 January 2014 (UTC)
Was the objection to the inclusion of terms like "85% of the page fontsize" and "11px"? There are plenty of editors who understand what that means and could make good use of it. The guidance would be incomplete without a summary of what editors thought was an acceptable minimum size. Perhaps there's an article somewhere explaining those terms that we could link to? --RexxS (talk) 04:42, 7 January 2014 (UTC)
"85% of the page fontsize" should be mentioned, but not things like 96dpi. It does give a good limit of what is too small. It also gives a good limit for the Wikilawyers. I've argued over 65% being too small, accessibility page is a MOS page and my favourite, the examples given in the heading section do apply to them. Without a lower limit, it will be hard to tell someone that their text is too small.
However, 11px probably shouldn't be mentioned. WP:FONTSIZE and W3C's Accessibility Guidelines say not to use px, but instead a percentage (% or em). It makes text scale better when someone resizes the web page, especially on older versions of IE. Bgwhite (talk) 07:07, 7 January 2014 (UTC)
I understand perfectly well what 11px and 85% and 96 dpi mean, but have little or no idea how they relate to the wiki markup language. It would be better to point out what the small template does, and say if that's the limit, and not to use it in already-small contexts, or something like that in terms of wiki markup. Dicklyon (talk) 06:46, 7 January 2014 (UTC)
Good point. Marriage both statements to something like, "85% of the page fontsize, which is what the <small> tag and the {{small}} template reduces text by." Bgwhite (talk) 07:17, 7 January 2014 (UTC)
Avoid using smaller font sizes in elements that already use a smaller font size, such as infoboxes, navboxes and reference sections. The {{small}} template (or the <small>...</small> HTML tag) produces a font-size of 85% of its surrounding text. The resulting font size should not drop below 85% of the page fontsize: Text should never appear smaller then this.
Edokter (talk) — 12:08, 7 January 2014 (UTC)

## Braille

I've created quite a few articles on braille, using either Unicode or images. It seems rather ridiculous that the blind can't read them because braille readers can't process Unicode braille. I wouldn't mind adding brackets or something to the braille so that the blind could distinguish between linear and braille script in the articles, but how do you make the braille itself accessible? Or do we simply need to wait for braille displays to catch up? (This is also a problem elsewhere; if you email a blind person in braille, they can't read it.) — kwami (talk) 19:43, 7 January 2014 (UTC)

Wavelength (talk) 20:07, 7 January 2014 (UTC)
Thanks, but I was hoping this had been addressed on WP, so we'd have some guidelines to follow. Because I don't have a braille reader to test things out on, I seriously doubt I'll be able to figure s.t. out that won't be full of bugs. And, frankly, if this isn't important enough to the blind community for people to have come up with something, I have other things to spend my time on. — kwami (talk) 20:14, 7 January 2014 (UTC)
There might be something useful in these search results for braille in the "Wikipedia" namespace. If not, then you can make a note on your calendar for similar inquiries each year.
Wavelength (talk) 20:38, 7 January 2014 (UTC)
This talk page has 173 watchers and has been viewed 63 times in the last 30 days. You might have more success at Wikipedia:Village pump (technical), which has 2,611 watchers and has been viewed 13,072 times in the last 30 days. Also, I know of one totally blind Wikipedian, User:Graham87, and he might know of others.
Wavelength (talk) 03:22, 8 January 2014 (UTC)
{{Braille cell}} is accessible withscreen readers because the dot patterns are in the alt text. Blind people never use the Braille Unicode points; they use Braille ASCII to get a Braille display to show whichever dot combinations are needed. Graham87 04:56, 8 January 2014 (UTC)

## Accessible exponentiation

Hi.

How can we have exponentiation in an accessible manner? i.e. in a manner that screen readers read 28 as "two power eight" instead of "twenty eight"?

Best regards,
Codename Lisa (talk) 13:58, 17 January 2014 (UTC)

How about [itex]2^8[/itex] which renders as $2^8$, an image with alt text "2^8"? It obviously depends on the context whether that is an acceptable solution, but 2<sup>8</sup> ( => 28) is never going to be a solution; semantically it's 28 and you're relying on a visual artifact (superscript) to convey information - that is bound to cause problems somewhere or other. --RexxS (talk) 16:58, 17 January 2014 (UTC)
As in the previous discussion ("Braille"), this question might be answered by User:Graham87.
Wavelength (talk) 17:14, 17 January 2014 (UTC)
JAWS reads it as 2 superscript 8 end superscript, which is good enough; I don't think other screen readers could process it properly. The "math" code is even better, accessibility-wise, but if there's a compelling reason not to use it, it shouldn't be used. Graham87 08:16, 18 January 2014 (UTC)

## An Example of Very Bad Contrast

I've found a page titled DUKEDOM OF GRAFTON which has severe contrast issues. The colours are set using <body text="#FF0000" bgcolor="#666633" vlink="#800080" alink="#000000">. In case you can't get to the page, and don't know what that HTML tag does, it means that  plain text is coloured like this , for a contrast ratio of 1.49;  unvisited links are coloured like this , for a contrast ratio of 1.57;  active links are coloured like this , for a contrast ratio of 3.51; and  visited links are coloured like this , for a contrast ratio of 1.58. Perhaps we should use it as An Example of Very Bad Contrast? --Redrose64 (talk) 20:44, 23 January 2014 (UTC)

## New proposal for toolbar redesign

There's a new proposal to re-design MediaWiki's toolbar, code-named Winter; comments about it are welcome at the proposal's talk page. Here is a prototype; I have already raised a few accessibility concerns about it. Graham87 10:30, 28 January 2014 (UTC)