Wikipedia talk:Manual of Style/Accessibility

From Wikipedia, the free encyclopedia
Jump to: navigation, search
WikiProject Manual of Style
WikiProject icon 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
WikiProject icon 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)
WikiProject icon 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. Or ask for help on your talk page and a volunteer will visit you there.
B-Class article 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.

English translations of Homer[edit]

any advice/help in cleaning up English translations of Homer is welcome. the lack of section headings is crazy, and the fact that the highest level table headings is all the way at the top of the article is also a mess. also, the width of the article is impossible on a narrow screen, not to mention the massive number of small tags. thank you. Frietjes (talk) 14:16, 4 October 2014 (UTC)

Unicode vs. marked-up ASCII equivalents (and HTML and entity codes)[edit]

I'd be interested in the accessibility arguments pro and con regarding:

  • E=MC² (with Unicode character for superscript-2), E=MC&#178; (with HTML code for same character), E=MC&sup2; (with character entity code for same character), E=MC{{sup|2}} (template), and E=MC<sup>2</sup> (the underlying markup behind the template, using HTML superscript). These render respectively as "E=MC²", "E=MC²", "E=MC²", "E=MC2", and "E=MC2".
  • 1⅔ (with Unicode two-thirds character), 1&#8532; (with HTML code for same character), {{frac|1|2|3}} (commonly used template), {{sfrac|1|2|3}} (alternative template), 1<sup>2</sup>&frasl;<sub>3</sub> (the underlying markup behind both templates, using HTML superscript and subscript markup, and the character entity code for fraction-slash), 1<sup>2</sup>⁄<sub>3</sub> (same but with Unicode fraction-slash), 1<sup>2</sup>&#8260;<sub>3</sub> (same but with HTML code for the fraction-slash), plain-text 1&nbsp;2/3, and plain-text with thin-space 1&thinsp;2/3. These render respectively as "1⅔", "1⅔", "1 23", "1 2/3", "123", "123", "123", "1 2/3", and "1 2/3". [The form "1-2/3" is sometimes encountered, but too easy to interpret as "1 minus 2/3", because the hyphen (-) is commonly used as a stand-in for the proper minus character (, not distinguishable from hyphen in most fonts), and has been intended to serve double-duty since the dawn of computing.]

My general impression is that the Unicode characters can often be problematic, their HTML and entity code equivalents a little less so (mainly from an OS and browser support, not accessibility, point of view).  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  03:22, 20 October 2014 (UTC)

As the guideline says, any character outside Latin-1 is highly problematic for screen readers. So your superscript character example was fine while your fraction one was not. Graham87 12:57, 20 October 2014 (UTC)
I think you missed an important aspect, editing. For the general editor, Unicode and HTML code would be harder to understand. Even the technical literate editor doesn't know what all the codes mean and would have to view the rendered page to know what it represents. For screen readers, listening to &#178; spelled out would be way harder to understand than hearing <sup>2</sup>. Bgwhite (talk) 21:57, 20 October 2014 (UTC)
We're supposed to use "Show preview" before saving non-trivial changes anyway, so "have to view the rendered page" is already an assumed step. It does seem at this point extremely odd that no major screen readers support Unicode, even common parts of it. Is this expected to change any time soon? One would think an open source project would be tackling this by now. Anyway, thanks for the replies. This confirms some of what I'd been expecting. Just to clarify, there's really no accessibility difference between Unicode and the &-codes from a reader perspective (they're both bad for screen readers if the character represented isn't in ISO Latin-1's character set), other than in editing mode the &-code version will be read out in a way that a sight-impared editor can tell what it is? This would seem to indicate that when we must use such a character, that it should be encoded, not given as bare Unicode. Exactly the opposite is the current general practice.  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  01:03, 30 October 2014 (UTC)
I highly doubt that anything will change on this front in the foreseeable future. The main problem is the memory required to store the spoken representations of Unicode characters ... not to mention Braille, which only has 255 combinations of dots to play with. The only times Unicode characters should really be used in the edit window in articles directly are when writing text in other languages and when writing IPA; using numerical character references in these cases would be extraordinarily inconvenient for editors. If a screen reader user really needs to distinguish between Unicode characters, they can figure oute the code point of a character of interest. Graham87 03:29, 30 October 2014 (UTC)
So, should we not be advocating the use of numeric character references for other cases, like em dashes, etc.?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  05:17, 30 October 2014 (UTC)
Ah, I forgot about Windows-1252, which screen readers will be able to handle fine (at least the em and en dashes which are present in that character set), so I've clarified the text a bit. Using HTML entities for those characters would clutter up the edit window, IMO. Graham87 14:56, 30 October 2014 (UTC)

CSS aural styles inline[edit]

Is there much/any support for these in real screen readers? I'm wondering if, for example, our code layout templates should be using style="speak-punctuation: code;". Also, a <dt> template like {{Term}} maybe should be using style="richness: 75;" and perhaps a slight pause-before and pause-after. Would such tweaks actually be helpful?  — SMcCandlish ¢ ≽ʌⱷ҅ʌ≼  02:21, 30 October 2014 (UTC)

Not really, except for Emacspeak. Graham87 03:11, 30 October 2014 (UTC)

Animated images[edit]

am I the only one who finds this excessive? Frietjes (talk) 20:38, 7 November 2014 (UTC)

It seems pretty but utterly useless. I took a look at it using Fangs Screen Reader Emulator. I don't read Arabic, but I doubt anyone who does could interpret it as fast as it is rolling. The image has no alt text, but the names are linked below. I don't see this as an accessibility issue though. --  Gadget850 talk 20:52, 7 November 2014 (UTC)
Oh dear, we have multiple discussions on this. Wikipedia talk:Manual of Style/Images#Animated images in sidebar templates is older. --Redrose64 (talk) 21:44, 7 November 2014 (UTC)
actually the oldest is Template talk:The Fourteen Infallible. Frietjes (talk) 21:48, 7 November 2014 (UTC)

FLC table question[edit]

At the List of Seattle bridges FLC, a question occurred to me as I was reviewing it: in List of Seattle bridges the table is using bold and/or italics to call out if a bridge is a national/city landmark. Does that work for screen readers, or does it need to be a dagger/* after the year instead? --PresN 03:09, 20 December 2014 (UTC)

Bold/italics would work, but the use of "*"/{{dagger}} would be better because it would be more easily recognizable (screen readers don't automatically read out formatting changes unless instructed to do so). Graham87 03:28, 20 December 2014 (UTC)

List marker types[edit]

I've reverted the bold addition of the sentence "Likewise, do not switch between list marker types (e.g. asterisks and colons), unless embedding lists starting at the highest level." partly because it was not discussed beforehand, partly because the last clause is ambiguous. --Redrose64 (talk) 14:43, 6 January 2015 (UTC)

For what it's worth, I'd approve of a change like that. I think the last part of the sentence refers to nesting lists; for example, using "*" and "*:" as the first and second levels, respectively, rather than "*" and "::". Graham87 14:55, 6 January 2015 (UTC)
[ec] If you find the wording ambiguous, please feel free to improve it, but there is no requirement to discuss edits before they are made (WP:BOLD and WP:DNRNC refer). Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 14:56, 6 January 2015 (UTC)
There was also no reason to revert me once I had started this thread (WP:BRD refers). You were WP:BOLD, I don't dispute that - I even acknowledged it early in my post above. I do dispute your call of WP:DNRNC because I didn't 'revert due solely to "no consensus"', see my post above. I didn't say so at the time, but I had noticed that you made your original edit six minutes after making this comment, which since WP:LISTGAP previously said nothing at all about "using asterisks below asterisks, and colons below colons", seems like altering the rules to suit your own viewpoint. TfD is a hostile place: please don't make it more so. Now, when it comes to list markup, I'm all in favour of accessibility - you will often find me removing blank lines in the middle of indented threads (as here) - but I don't see why a TfD discussion cannot be marked up as follows:
*'''Keep''' because etc.
*'''Delete''' because etc.
*:Comment on vote
*::Comment on comment
*'''Merge''' with X because etc.
This keeps the main list - a list of !votes each as a bullet - as a single three-item list; it has a sublist (which itself has a sublist) that although of a different type does not terminate and restart the main list. Graham87, are there accessibility issues with a discussion formed like that? --Redrose64 (talk) 16:23, 6 January 2015 (UTC)

──────────────────────────────────────────────────────────────────────────────────────────────────── There was no reason for you to revert me other than "discuss before adding", which means there was no reason for you to revert me.

The wording you removed specifically allows for nesting such as in your example ("embedding lists starting at the highest level"). The problem addressed is the broken nesting of lists, such as:

*'''Keep''' because etc.
*'''Delete''' because etc.
**Comment on vote
:::Comment on comment
*'''Merge''' with X because etc.

-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 6 January 2015 (UTC)

examples of layout tables[edit]

The link to the data table tutorial is useful, but there's no such link for layout tables. Do any examples exist anywhere? Xaxafrad (talk) 07:27, 10 January 2015 (UTC)

Xaxafrad : Hi! We do not currently have a tutorial or examples of best practices for layout tables. But it is a very good suggestion. If anyone is interrested in making a layout table tutorial please go ahead ! :-) Dodoïste (talk) 10:29, 20 January 2015 (UTC)