Wikipedia talk:WikiProject Accessibility/Archive 4

Archive 1

Archive 2

Archive 3

Archive 4

Archive 5

Archive 6

→

Archive 8

Template:Wikitext/help

Please can someone check the contents of Template:Wikitext/help, which currently renders (Subst:) as:

The term "wikitext" refers to Wikipedia's wp:wiki markup language. Formats: [[hyperlink]] or [[hyperlink|link here]] or [[expert]]ly    → hyperlink or link here or expertly [http://www.google.com external link]      → external link   (to an outside webpage) [[File:Example.jpg|thumb|55px|Caption]]      →   (shows image, see below) ==Header== → Header        ===Subheader=== → Subheader ''italic''   '''bold'''   '''''bold-italic''''' → italic   bold   bold-italic * bullet → • bullet       (or ":*" or "::*" to indent) Caption : indent →     indent   (or "::" or "::::::" to indent more) # numbered →   1.  numbered   ("#:" indents under numbered lines) #* bullet under number →   °  bullet under number [[Category:xx]] → (internal wp:category link). {{templt|aa|bb}} → (run "Template:Templt" with parameters "aa" & "bb") {{#expr: (5*10 + 3^2 +8)/2 }} → calculate expression: (5×10 + 32+8)/2 = 33.5 ~~~~ → signature     ~~~~~ → date/time (UTC) A related page is Help:Table, see: {{Wikitable/help}}.

particularly with regard to lists, for accessibility? I have concerns that it encourages bad practice, but am not sure what the best solution would be, given the necessity for brevity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 12:26, 9 August 2013 (UTC)

It's fine, as far as I can tell; there are no line breaks between the list items at any rate. Graham87 02:24, 10 August 2013 (UTC)

Ah, shouldn't ":*" and "::*" be "*:" and "*::"? Graham87 02:27, 10 August 2013 (UTC)

Section headings on peer review pages

Please see discussion at Wikipedia talk:Peer review#Section headings and accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:09, 14 August 2013 (UTC)

Accessibility of references

Hi all, bugzilla:38141 is looking at improving the accessibility of the citation linkbacks ↑ and I was wondering if some might have feedback or suggestions for appropriate labels. Some ideas:

• Jump up
• Jump back
• Jump to citation
• Jump to usage
• Jump back to citation
• Jump to usage of this citation

Anyone got a clue as to what would be best suited ? —TheDJ (talk • contribs) 14:07, 18 August 2013 (UTC)

I've commented at Bugzilla. Graham87 14:41, 18 August 2013 (UTC)

Wikipedia and the editor who is differently able

There is a discussion at WER which I started without knowing that the accessibility project existed. It seemed to me to be the best place I could find at the time. I have no particular interest in its staying there or migrating here, though I suggest strongly that all contributions be in one place, and there seems as valid as here :)

Please may I commend the discussion (there) to you and ask for contributions with a view to some form of embracing action? Fiddle Faddle 09:59, 3 September 2013 (UTC)

Bot request related to accessibility

I've recently done a write-up about accessibility problems on Wikipedia in the Signpost's tech report, and flowing from that, I've started a bot request discussion to fix some accessibility issues that I noted in the write-up. Any comments at the bot request discussion would be appreciated. Graham87 05:18, 7 September 2013 (UTC)

Discussion about collapsing music track lists

Dear All: There is a discussion about whether the track lists for Music of the SaGa series should be collapsed in the article at Talk:Music_of_the_SaGa_series#Collapsed_sections. Please visit the talk page and take a few moments to share your feedback on this issue. --Jax 0677 (talk) 01:33, 19 September 2013 (UTC)

Visual impairment - what settings, software, or other tools are used to compensate

If you have any degree of vision loss, I'd like to learn what general tools you use, and details of specific setups. Anything from the following list, would be ideal:

• zoomed-text settings or screen magnification levels (150% 200% etc)?
• only magnified-text, or magnified-images too?
• any specific typefaces/fontsizes?
• whether you copy text into alternate text-editors, or similar workflows?
• if you use custom style-sheets (eg WP:Style sheets for visually impaired users)?
• and anything else we ought to know about?

I've found a few threads in the archives here (eg. Vision impairment friendly skin option would help, General Accessibility) but not many mentions of specific settings. I found some related WP:Userboxes/Health#Vision, but I'm not sure where else to find folk. Please nudge anyone that you know, who might be able to help. Thanks! –Quiddity (talk) 06:34, 7 September 2013 (UTC)

Adding Wikipedia:Wikipedia Signpost/2013-09-04/Technology report just to get it on the list. I'll also add that using your browser's zoom function often breaks the formating of pages, but that's probably a different discussion. 64.40.54.181 (talk) 04:40, 10 September 2013 (UTC)

Wikipedia:Using JAWS is probably also worth checking out for anyone who has that. There are a couple of packages I use regularly for everyday tasks, such as word processing, web browsing and editing Wikipedia. I'm sure there'll be many other editors who use these, but I'll give a quick outline of them for anyone who's not familiar with them.

The first is SuperNova, a screen magnifier that enables text to be enlarged to a user's specific requirements, and even allows the text colour and background to be changed. I often reverse the polarity so that I have white text on a black background, which I find can be less straining on the eyes, so an option to do that on Wikipedia would be helpful. I usually set the text size to x5 or x6, depending on what I'm reading. The software will enlarge both text and images, but the downside is that I can only see a portion of the screen, and images can become distorted if they're enhanced too much. Reversing the screen polarity also changes image colour, so any program to do that on Wikipedia would need to address that. Having this software means I can edit Wikipedia, but I tend to have difficulty with anything that involves too much code, such as complex tables.

I have also used Windows magnification, but found problems when wanting to move the pointer to another part of the screen as that remains small and difficult to see regardless of the text size.

The other package I use quite a lot is Kurzweil 1000, a text-to-speech programme that can scan and read documents aloud. This is very useful when reading something lengthy. Kurzweil also provides direct access to articles from Wikipedia, Encyclopedia Britannica and a couple of other online publications. However, although it's possible to retrieve the current version of a Wikipedia article, pages cannot be edited via Kurzweil. In the past I have attempted to copy/paste, then modify documents in their bare format, but that has caused problems when they're transferred back to Wikipedia, since Kurzweil 1000 doesn't recognise some written languages (such as Russian) so will replace the characters with a series of question marks.

Hope this helps, and covers the sort of information you wanted to know. Give me a shout if you have any questions. Paul MacDermott (talk) 16:41, 20 September 2013 (UTC)

Much thanks Paul, that is exactly the kind of thing I was hoping to learn. Feel free to add more details anytime (I've watchlisted this page for years), and I might ask a few more questions later on.

Just FYI, I've had a little bit of experience with Orca on linux, but I need to spend some more time getting to understand how to test it more efficiently. TTFN, –Quiddity (talk) 18:28, 20 September 2013 (UTC)

Glad I could help. Just reading what others are saying below, I'll add a couple of other things. After upgrading to IE8 some time ago I found a glitch that prevented me editing protected articles when SuperNova was running, so had to switch to Chrome, then later found Opera which I prefer because of its drop down menus. Having recently upgraded from Vista to W7, things seem to be ok with the current version of IE (9, I think). Also, I'm still using the old Wikipedia format with the search bar to the left of the page. Changing to this might help anyone whose drop down menus are short of space because of larger text. Paul MacDermott (talk) 12:57, 21 September 2013 (UTC)

Monitor and Zoom - I have a 23-inch widescreen monitor and use both Firefox and Opera. My zoom on Opera is set with Trebuchet MS default font, and zoom is at 120%. Firefox default font is Microsoft Sans Serif. Firefox doesn't give percentage on the zoom, but it's zoomed up as large as it will go and still look like normal type face. Firefox zoomed larger makes everything look like it's on bold face, so I keep it one step below that.

Images - I do zoom images on Commons, but it's a matter of enjoying scrolling around and looking at all the details. If the images are older non-digital, and/or if there is text on the image, zooming is sometimes necessary.

Most annoying problem - Duplications or missing periods, commas, punctuation, coding diffs between bold, italics, etc. It is difficult to see those little things in the edit window, even with a lot of zoom. I catch most on a preview, but often miss them in the Edit window.

WikED - This is a necessity for me in the Edit window. I can do without it, but looking at the Edit window without WikEd is like looking at a big blob of text where nothing stands out to help my editing. And WikEd has some funky quirks that don't get solved, so I work around the quirks.

Colors - It would help if you had an associate on whatever you're working on about this who is over the age of 50 or 60. Colors start to go away, and people begin to have trouble distinguishing between colors in the red spectrum (orange, maroon, pink) . When blues are lightened up (like what has happened recently) on Wikipedia links, to an older person it doesn't even look like links are there. Probably all colors are involved, but those two come to mind.

Definition - People with normal eyesight see the world through crisp, clean digital lens. People with vision problems are often looking through something like a dirty window, images are softer or blurred, or there is a white or yellow film over what they see. It's the difference between Digital and a dirty window.

I hope I've offered you some help. Feel free to ask me other questions you might have. — Maile (talk) 20:44, 20 September 2013 (UTC)

Hello; you asked me to comment on vision problems. My eyesight isn't really bad, but reading small text is tiring, especially if the background is busy or coloured. I use Firefox, and I often zoom in one level (Control+) when editing. I also have Twinkle enabled, the Teahouse options, and then or course there's the new "edit source" tab, and I find that at that zoom level the tabs at the top of the screen won't fit and are shifted down and to the left, obscuring the name of the article. If I am doing something that requires switching from article to article, this means constantly zooming out to use the tabs, and in again to read the text. The obvious fix for this is to have the search box shrink when there isn't enough space for all of the tabs, and grow when there is. Another solution is to put items in the drop-down under the little triangle as Twinkle does when there isn't enough space. In fact, it seems to me that the interface used to do this, but of course I now can't remember under what circumstances. —Anne Delong (talk) 20:15, 20 September 2013 (UTC)

Maile and Anne, that is great feedback, with both specific details, and specific problems. Much thanks to you both. I'll try to mention or pass along all these points, to as my locations as I can think of. TTFN, –Quiddity (talk) 21:57, 20 September 2013 (UTC)

Category:Articles overusing colours

Category:Articles overusing colours, which is the tracking category for the templates {{overcolored}} and {{overcoloured}}, is under discussion at Wikipedia:Categories for discussion/Log/2013 September 21#Category:Articles overusing colours. --Redrose64 (talk) 14:39, 21 September 2013 (UTC)

WP Accessibility in the Signpost

The WikiProject Report would like to focus on WikiProject Accessibility for a Signpost article. This is an excellent opportunity to draw attention to your efforts and attract new members to the project. Would you be willing to participate in an interview? If so, here are the questions for the interview. Just add your response below each question and feel free to skip any questions that you don't feel comfortable answering. Multiple editors will have an opportunity to respond to the interview questions, so be sure to sign your answers. If you know anyone else who would like to participate in the interview, please share this with them. Have a great day. –Mabeenot (talk) 02:08, 18 October 2013 (UTC)

Line breaks

My eyesight and coordination are not great. I sometimes find it hard to position the cursor precisely using the mouse. I swap text around a lot when I start an article until I am satisfied with the sequence. I prefer to start new sentences on new lines. If the sentence is on a line or lines by itself I find it easier to select the sentence, then cut it and paste it somewhere else. I click at the end of the line, pull back to the start of the sentence, then CTRL+X, CTRL+V to move it. It is harder for me to select and move text that is embedded in a line or lines. Sometimes editors take the line breaks out. Is there a reason for this? Aymatth2 (talk) 03:09, 5 November 2013 (UTC)

See the fairly old essay Wikipedia:Don't use line breaks. I myself don't like them as a screen reader user because they make it harder to arrow through the wiki-markup. Graham87 06:16, 5 November 2013 (UTC)

That is awkward. Line breaks at the end of each sentence make it a bit easier for me to edit, but harder for you. Is it a lot harder, or just a bit harder? The essay is inconclusive and does not mention mouse coordination or screen reader issues. While an article is being created presumably the author's choice should be respected. After that, I don't know. I suppose I mostly care about keeping end of sentence line breaks while I am working on the article. Aymatth2 (talk) 14:49, 5 November 2013 (UTC)

Only a bit harder. Having them at the ends of sentences (thus in a predictable location) wouldn't be as bad as me as having them every fifty characters or so, as one editor did a very long time ago, inspiring me to write about it it in my first major post about accessibility. That admonition is still in the accessibility guideline, but I'm not that attached to it; it'd probably best to ask about it at the guideline's talk page as well. Graham87 04:03, 6 November 2013 (UTC)

Have you considered creating articles in your userspace, and not moving them to mainspace until you're mostly done editing them? No one is likely to mess with them overmuch while they're in userspace. Maralia (talk) 04:12, 6 November 2013 (UTC)

I would find that awkward. Once I have a fair start to a new article, I search for related articles and link them to the new one, then use "what links here" as a checklist for other aspects that should be covered. Once I have "finished" an article, it often has redlinks I want to turn blue. That process, starting new related articles, often turns up content that belongs in the earlier article - sometimes quite a lot. It is never clear when the article will be mostly done. "After it has been unchanged in mainspace for a month or so" maybe. I will raise the question on the accessibility guideline talk page. Aymatth2 (talk) 13:59, 6 November 2013 (UTC)

Hlist heads up

Problems reported at Wikipedia:Village_pump (technical)#Pages_inaccessible_using_IE8 have resulted in changes to the {{hlist}} template. I know some of you are interested in things like this, so there's a pointer if you want it. WhatamIdoing (talk) 22:50, 17 November 2013 (UTC)

The template hasn't changed, and nor has the underlying module. What has changed is MediaWiki:Common.css, where the white-space: nowrap; declaration has been removed from all rules which include the hlist class in the selector. --Redrose64 (talk) 11:21, 18 November 2013 (UTC)

wp miss (and more) nominated for deletion

wp miss and other redirects have been nominated for possible deletion. If you would like to participate in the discussion, you are invited to add your comments at the redirect's entry on the Misc. for discussion page. Thank you. XOttawahitech (talk) 16:16, 6 December 2013 (UTC)

Composition bar

Accessibility issues with {{Composition bar}} are being discussed at Template talk:Composition bar#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:31, 17 December 2013 (UTC)

Verison template

There are serious accessibility issues with {{version}} (and tables in articles using it as a legend), which relies on the background colours of table cells to provide information. Please discuss at Template talk:Version#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:21, 23 December 2013 (UTC)

Template:Start date

There is a discussion at Template talk:Start date#Minus sign in time zones which might interest this WikiProject; it concerns other matters besides the minus sign. --Redrose64 (talk) 23:24, 26 December 2013 (UTC)

RFC: spacing of mixed fractions

An RFC has been started at Wikipedia talk:Manual of Style/Dates and numbers#Spacing of mixed numbers in relation to the spacing between the whole number and the fraction in mixed fractions (e.g., 1+2⁄3). As this involves accessibility issues on the presentation of such numbers (for example, screen readers may have difficulty parsing the number correctly without a space), I have posted this here to invite further comments from interested Wikipedians. —sroc 💬 05:50, 28 December 2013 (UTC)

Complex infographics

Complex infographics giving a large number of facts, like File:Human Aquatic Adaptations.png, used in Aquatic ape hypothesis; and File:Human Running Adaptations.png in Endurance running hypothesis, are being discussed at:

• Talk:Aquatic ape hypothesis#Summary diagram
• Wikipedia:Village pump (miscellaneous)#‎Infographic use

Your comments would be welcomed. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:03, 31 December 2013 (UTC)

Page length

2013 in film is 332,397 bytes (without images). Please discuss whether or not to sub-divide it, at Talk:2013 in film#Length. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:29, 16 January 2014 (UTC)

RFC on left-aligned images

Hi. Please be aware that a discussion is going on at WT:Manual of Style/Images#Request for comment, asking whether the portion of the guideline advising against placing left-aligned images directly below level-3 subheadings ought to be removed. The consensus so far is overwhelmingly in favour of removing this recommendation, though some objections have been raised on accessibility grounds. People here who have insights on the accessibility ramifications of this proposed change might wish to go comment on the RFC. — Richwales (no relation to Jimbo) 18:05, 26 January 2014 (UTC)

Opendyslexic font?

Hello,

I suggested a few months ago to a dyslexic friend of mine (a Web accessibility expert, well known in France and Belgium) to have a look at the "opendyslexic functionality" that had been implemented. I suspect it was removed with the "universal language selector" (sorry, I can't remember the proper name).

She was a bit disappointed because the font did not correct her main concerns. She suggested to shorten the lines, to increase the line heights and spaces between the paragraphs. She was also complaining that the default font size required a zoom of 130% to become readable for her.

Where could I forward those informations to the devs?

Thank you! GChagnon (talk) 22:53, 10 February 2014 (UTC)

You could use the email address listed on the OpenDyslexic website, in case you haven't already done so. Graham87 02:01, 11 February 2014 (UTC)

DYK Nominations

I've raised a concern with the accessibility of the formatting used for "Did You Know" nominations; please see Wikipedia talk:Did you know#Formatting and bullets. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 15 February 2014 (UTC)

Watchlist's "green bullet" (page updated since last visit) feature inaccessible

a report has been loggged in the Village Pump's technical section which details the technical (and resultant end-user) problems posed by the use of purely visual indicators to denote the status of items which appear in document divisions marked class=mw-changeslist in the rendered document source for the Wikipedia Watchlist... the report was sparked by the following prose, which appears in the second paragraph of the introductory text for the Watchlist, immediately preceding the "Mark all pages as visited" button in the document's reading-order:

Pages that have been changed since you last visited them are shown with a green bullet.

the report details why this "feature" is inaccessible to the blind, as well as those with color vision deficiencies -- in particular: monochromacy, achromatopsia, red-green color-blindness, tritanopia and tritanomaly... it also specifies violations -- inherent in the feature's design and implementation -- of the W3C's Web Content Accessibility Guidelines and Wikipedia's own Manual of Style... this "feature" should never have been implemented on Wikipedia, and the clear and obvious problems identified in the report at the Village Pump should have been detected and corrected by those who construct and vet the templates for Wikipedia -- their failure to do so is inexcusable.... therefore, means of immediately rectifying the problem -- and preventing a recurrance of the mplementation such a "feature" in the future -- have been provided via the Village Pump technical report...

the "feature", as defined by the style rules contained in code conatined in divs marked class="mw-changeslist", cannot be made accessible with any existing (or emerging) technology, because images inserted using list-style-image are cannot currently be programmatically associated with textual equivalents, such as the use of the native HTML attribute alt or by use of ARIA's aria-label or aria-labelledby, and therefore needs to be re-engineered and replaced, either through the scripted, rather than a CSS-generated, insertion of an image into the document source to indicate that the listed item has changed since the user's last visit using the IMG/alt tandem oedipus (talk) 05:58, 16 February 2014 (UTC)

WP:TOC and ignoring accessibility

People are ignoring "If floating the TOC, it should be placed at the end of the lead section of the text, before the first section heading. Users of screen readers do not expect any text between the TOC and the first heading, and having no text above the TOC is confusing. See the last line in the information about elements of the lead section." They state this can be ignored for any reason and no consensus was ever had on this matter. A call for a RFC is at User talk:Bgwhite#TOCs. Bgwhite (talk) 23:23, 19 February 2014 (UTC)

Recent font change - type face

See Wikipedia:Village pump (technical)/Archive 125#Font size and style for more info.

To change back to the old style (sans-serif style in Vector).....

Go to Preferences → Gadgets → Vector classic typography (use only sans-serif in Vector skin)

-- Moxy (talk) 02:04, 4 April 2014 (UTC)

Moxy, the main reason for changing fonts was for accessibility. The font size and line height have been increased. Those with vision problems, like me, no longer have to increase the browser's font size. Also, the new style is what the end reader will see. If you are doing tables, images or other things to certain sizes or placements, the end reader will see something different than what you see. I keep running into that problem with editors. Bgwhite (talk) 04:42, 4 April 2014 (UTC)

As has been mentioned at the link above by many, readability has diminished because of the font style. Thus the reason for this notification. I aslo have vision problems and the style is a problem for me - size is good though. -- Moxy (talk) 05:05, 4 April 2014 (UTC)

RfC on use of plainlist

There is an RfC on whether to use the {{Plainlist}} template for lists in the infobox at Talk:Michaëlle Jean #RfC: Should the lists in the infobox use the Plainlist template?. As this is essentially a question of accessibility, I am placing a notification here as the relevant WikiProject. --RexxS (talk) 22:28, 15 April 2014 (UTC)

User warning for inaccessible sigs

I have created a level one warning template, {{Uw-sigdesign1}}, which reads:

Hello, I'm [Username]. I wanted to let you know that your signature ("sig") design might cause problems for some readers. This is because of low colour contrast, an unreadable font, or suchlike. If you think I made a mistake, or if you have any questions, you can leave me a message on my talk page, or take a look at our guidelines and policy on customising sigs. Thank you.

where "of low colour contrast, an unreadable font, or suchlike" can be replaced by |1= and "Thank you" by |2=.

I invite comment about its content and deployment, including the possibility of using it in twinkle, on its talk page. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:14, 18 April 2014 (UTC)

Abbreviations

The accessibility of abbreviations of "circa" is being discussed here. Your thoughts would be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:14, 19 April 2014 (UTC)

Background colours on templates

Wikipedia:Manual of Style/Accessibility#Color (WP:COLOR) states:

Some readers of Wikipedia are partially or fully color blind. Ensure the contrast of the text with its background reaches at least WCAG 2.0's AA level, and AAA level when feasible.

This is very sensible advice.

Some templates use background colours, e.g., to highlight discussions that have closed. For example, {{cfd top}} uses #bff9fc, {{sfp top}} uses #99ff99, {{sfp nocreate}} uses #ff9999, and so on (I am indebted to David Levy for researching these). This is not an issue when writing in black text, provided that these provide a contrast ratio of at least 4.50:1 as is required for "AA" level compliance. However, this can become an issue when using text in other colours, such as links (#002bb8) and formatting applied by templates such as {{xt}} (#006400) and {{!xt}} (#8B0000) where the contrast ratio falls below this level.

This has become an issue in a discussion at Template talk:Tq#RfC: Change the TQ template font colour where is it proposed to change the colour of the {{tq}} template (currently #008000) because of its similarity to the {{xt}} template, but it is difficult resolving on a specific colour because they all clash with background colours used on various templates.

I would suggest that templates should avoid using such background colours, except in a very light range, as this substantially restricts the ability to use font colours without breaking accessibility. For example, the {{sfp top}} template could use the bright green in the background of the header (where the predefined text is all black and red) and use the same colour for borders around the closed discussion, but leave the background behind the discussion as transparent (or a very light shade that would not interfere with any text colours) in order to preserve accessibility regardless of what font styles are used in the discussion.

Should this be introduced as a policy or guideline for all templates? —sroc 💬 06:47, 21 April 2014 (UTC)

Disability Access Issues with Wikipedia

Hello, I hope the question at Wikipedia:Village pump (idea lab)/Archive 13#Disability Access Issues with Wikipedia might be of your interest. Thanks···Vanischenu (mc/talk) 09:56, 1 June 2014 (UTC)

Unifying information about use of color in images

WP:COLOR redirects to Wikipedia:Manual_of_Style/Accessibility#Color, part of the official Wikipedia MOS realm. It talks in detail about use of color for text, but only mentions briefly the general principle for images. Category:Articles with images not understandable by color blind users has detailed information for images, including specific examples of sets of colors. It's the same set of principles and underlying issues to solve in all cases--the only difference is whether it gets implemented in a graphics editor or in wikitext/html. And now that we have {{pie chart}} and other on-the-fly graphics generation, that distinction is becoming fuzzy. While working on a template for #Tagging images for color problems, I could not find the tips and image guidelines anywhere except on the category page. It was especially surprising that I couldn't find it anywhere obvious in Category:Wikipedia style guidelines, which is where {{Cleanup image}} instructs readers to go for "image...quality standards".

Proposal: move the intro from the category page into the MOS so that both the guidelines and tips for implementing them are in a single, unified place. Then the cat (and other places that need to refer to accessible color use in any context) can just point to it. As the tools change, only one set of external links needs to be updated. DMacks (talk) 06:42, 20 June 2014 (UTC)

Tagging images for color problems

We have Category:Articles with images not understandable by color blind users, but that only identifies the whole article as having one or more problematic images. It would be useful to have an image-specific method, tagging the specific file(s) that are the problem. That way someone interested in fixing this sort of problem doesn't have to scan a whole article to figure out what images are problematic, and images that are used in multiple articles are tagged centrally. Perhaps a Category:Images not understandable by color blind users (as a subcat of Category:Images requiring maintenance) with a {{Cleanup image}} message displayed on the image description page? DMacks (talk) 17:04, 19 June 2014 (UTC)

Maybe a counterpart to Category:Articles with accessibility problems such as Category:Images with accessibility problems and maybe also Category:Templates with accessibility problems? John Carter (talk) 18:23, 19 June 2014 (UTC)

Here's a first attempt at the tag: {{Cleanup image accessibility}}. Category:Images with accessibility problems sounds nicer (no need to be more specific in its name for now). DMacks (talk) 18:47, 19 June 2014 (UTC)

With no further comments, I made {{Cleanup image accessibility}}. Category:Images with accessibility problems blue and will start using them. Obviously anyone is welcome to continue to adjust the wordings. See also the next section, where I ponder where the guidelines for color should actually be written... DMacks (talk) 13:59, 23 June 2014 (UTC)

Leaflet for Wikiproject Accessibility at Wikimania 2014

Hi all,

My name is Adi Khajuria and I am helping out with Wikimania 2014 in London.

One of our initiatives is to create leaflets to increase the discoverability of various wikimedia projects, and showcase the breadth of activity within wikimedia. Any kind of project can have a physical paper leaflet designed - for free - as a tool to help recruit new contributors. These leaflets will be printed at Wikimania 2014, and the designs can be re-used in the future at other events and locations.

This is particularly aimed at highlighting less discoverable but successful projects, e.g:

• Active Wikiprojects: Wikiproject Medicine, WikiProject Video Games, Wikiproject Film

• Tech projects/Tools, which may be looking for either users or developers.

• Less known major projects: Wikinews, Wikidata, Wikivoyage, etc.

• Wiki Loves Parliaments, Wiki Loves Monuments, Wiki Loves ____

• Wikimedia thematic organisations, Wikiwomen’s Collaborative, The Signpost

The deadline for submissions is 1st July 2014

For more information or to sign up for one for your project, go to:

Project leaflets
Adikhajuria (talk) 17:16, 27 June 2014 (UTC)

Removal of transcript from Signpost article

There is a discussion at Wikipedia:Wikipedia Signpost/2014-06-25/Exclusive about the removal of a transcript from a Signpost article featuring an audio interview. —Neotarf (talk) 16:41, 2 July 2014 (UTC)

Template:Color contrast ratio

I think there should be some few words in Template:Color contrast ratio template about the ratio - what ratio is good and what is bad (kinf of from x to y: AAA, d to f: AA, h to r: A, j to l: NO). --Edgars2007 ^{(talk/contribs)} 08:23, 19 July 2014 (UTC)

I've added a section including a somewhat simplified table to the template documentation. Hopefully it should be a help to editors in deciding what's usable. --RexxS (talk) 13:32, 19 July 2014 (UTC)

See also the table I added to Template:Color contrast visible/doc#HTML colors. Helder.wiki 18:08, 19 July 2014 (UTC)

Thanks! It looks good. --Edgars2007 ^{(talk/contribs)} 11:49, 20 July 2014 (UTC)

Images placed mid-sentence

I've highlighted an accessibility concern at Wikipedia talk:Manual of Style/Images#Splitting sentences. --Redrose64 (talk) 11:01, 27 July 2014 (UTC)

Linkdump - accessibility and usability

mw:Accessibility and usability cleanup - hopefully useful for any of us that engage in cleanup work over the coming [timespan]. I think it lists all the main pages, but please add anything I've missed. Quiddity (talk) 20:24, 27 July 2014 (UTC)

Accessibility improvements RfC at Infobox musical artist

At Template talk:Infobox musical artist an RfC has been created by one editor who has reverted the mention of flatlist as an accessible improvement over comma separated values. Despite the clear consensus established on this kind of issue at Talk:Michaëlle Jean#RfC: Should the lists in the infobox use the Plainlist template?, it seems that we have to re-state the guidance at Wikipedia:Manual of Style/Accessibility #Lists and Wikipedia:Manual of Style/Lists #List styles again. More eyes would be welcome. --RexxS (talk) 21:29, 31 July 2014 (UTC)

Feedback request (WPTC track maps)

A discussion pertaining to WP:COLOR is taking place at Wikipedia talk:WikiProject Tropical cyclones/Tracks#Wikipedia:Manual of Style/Accessibility#Color compliance. Feedback from knowledgeable or interested editors is welcome. -- Netoholic @ 02:01, 15 August 2014 (UTC)

Language template TfD

FYI

 – Pointer to relevant discussions elsewhere

Several {{Lang-xx-YY}} templates have been nominated for deletion. They are grouped together near the top of Wikipedia:Templates for discussion/Log/2014 August 13. Some respondents there have made accessibility (e.g. screen reader) arguments regarding such templates, so participants here may be interested in those TfDs, pro or con.  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:10, 19 August 2014 (UTC)

See also related discussion at Wikipedia talk:Manual of Style/Accessibility#Using "lang-x" template or simple wikilinking and formatting (which links further to more related threads).  — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼  07:20, 19 August 2014 (UTC)

Hi User:SMcCandlish. Thanks for creating a debate around this issue. I can't find "en-GB" in the official language subtag registry. If it's not a standardized subtag, I do not understand how it can be useful as a metadata subtag. Maybe I'm missing something? The discussion on that deletion proposal is veeery long, I did not read most of it. Dodoïste (talk) 17:24, 23 August 2014 (UTC)

@Dodoïste: Region subtags are actually a W3C recommendation arising out of RFC 3066 - you can find detail at:

• http://www.w3.org/International/articles/language-tags/#region

Hope that helps, RexxS (talk) 20:42, 23 August 2014 (UTC)

Thanks RexxS, it does help me to understand. :-) Dodoïste (talk) 15:13, 24 August 2014 (UTC)

Help with dark Wikipedia skins

An example of the sort of colour scheme I'm describing - maybe even a bit darker for the background

I need a dark background for reading and editing Wikipedia, because light backgrounds strain my eyes. A dark grey background with light-to-medium grey text is the most appropriate (white text hurts my eyes), with links that have a high lightness and low saturation (I'm using the words GIMP gives me - I hope they are describing what I mean correctly).

For context, this is the help desk query that brought me here.

So, looking at the current stage of support for various ways of getting this done, would I be able to request that somebody with the skills to do it create a skin (preferably for Vector) that fits my description? The other methods are not adequate for comfortable use of Wikipedia. It would be most appreciated.

If it was possible to invert everything except images, then lighten the resultant black background a bit and change the text colours, that might be one way to get around any problems with formulae and so on. Anyway, I'm sure I'm not the only user with this problem.

Thank you all for your help; and let's keep Wikipedia awesome! Thennicke (talk) 14:59, 17 August 2014 (UTC)

Hi. Yes there are other users who reported the same issue as yours. For example, User:Axl is using the green on black gadget.

Unfortunately, I think it's impossible to invert colours with CSS. Or at least it's beyond my abilities. The browser itself can do it as you know, but then the images get inevitably altered too...

Two years ago I helped to maintain the "green on black skin" gadget. I also thought that a light grey on dark gray skin would be much more pleasant.

The code for the green on black gadget that was pointed to you is here : MediaWiki:Gadget-Blackskin.css. It works on vector too, except for the vector-specific features... The "discussion, history, edit..." buttons at the top of the page, and the editing toolbar show in normal contrast.

We could use this code as a starting point. All we need to do is change the values of colours (replacing green with light gray, and black with dark gray), after all.

I also made a draft at the bottom of my own User:Dodoïste/vector.css for a vector compatible green on black skin. It's not very far from completion...

I really think you should file a MediaWiki bug. This problem is experienced by a very large number of readers. The website should offer easy to enable or disable other colour schemes for readers too. Dodoïste (talk) 19:56, 17 August 2014 (UTC)

If we're going to do a "light grey on dark gray skin", could you tell me the precise colours (Web colors#Hex triplet) you would like to have ? Dodoïste (talk) 20:00, 17 August 2014 (UTC)

Salut, Dodoïste! - I've made a start at reversing colours in css just to see how practical it is. The problem is that editors insist on coding background colours in-line, especially inside tables, so there are a lot of pages where this doesn't work well. But out of interest, Thennicke you could try copying & pasting the following into your Special:MyPage/skin.css:

body, div#column-content, div#footer, h1, h2, h3, h4, h5, h6, #searchBody, div#content, #bodyContent, div.mw-content-ltr, .mw-code, textarea, div.editOptions {
  background-color:#222; color:#BBB;
}

a, #p-personal li a {
  color:#CCF;
}

a:visited {
  color:#FCC;
}

where I've assumed a light grey (#BBB) on a dark grey background (#222) - make the numbers smaller for darker, or bigger for lighter (0-9, A-F). I've set the links as light blue (#CCF) or light red when visited (#FCC). You can preview what it looks like before saving, and change the values to suit your monitor and vision. I don't think I've caught all the elements on a page, but it's a start that can be built on if anyone is interested in trying it out. --RexxS (talk) 20:44, 17 August 2014 (UTC)

Bugs 64731 and 24070 are the two bugs for this issue that I could find on Bugzilla. Because the bugs are already reported, I didn't add another duplicate.

Thank you for your help, but because this feature is so poorly supported (the simple code provided above gave me a completely unreadable home-page, with light-grey text on white), I'm actually going to be better off using an unmodified Vector, and just lowering my screen brightness to try and deal with the issue. Because I am just your typical end-user, this is as far as I am going to go in this process; if anybody here who is more involved in development wants to notify people that there is a demand for this feature, please do. Once again, thank you to everybody who helped me out here. Hopefully in the next few months there will be a dark, grey-based Vector skin up and running for users like myself. Thennicke (talk) 12:01, 18 August 2014 (UTC)

Thennicke : Hey, no, don't leave ! We're going to do just that, a grey-based Vector skin.

But please understand that it will take several days and iterations. RexxS code just above was only a testcase for the color choices. It was nowhere supposed to be functional. We need to know if the colors chosen in RexxS's testcase are a suitable choice for you. If it is, we can develop a skin based on this set of colors.

Hi RexxS, nice to see you. I hope you're doing fine! ;-) Dodoïste (talk) 13:20, 18 August 2014 (UTC)

Hi RexxS, sorry you couldn't make it yesterday - next is 21 September.

All: here are two links that I often use when choosing colours. Colorizer allows you to choose colours in any of four different methods; you can type in values, pull the sliders about, or both. Unfortunately it doesn't calculate contrast or give a WCAG level, so I also use Snook's Colour Contrast Check - there are fewer ways of choosing a colour, but it does tell you if a combination is WCAG 2 AAA Compliant or not. From this, I find that for a purely greyscale screen, the lightest background that gives WCAG 2 AAA Compliance for white text is #595959 which looks like this and the darkest text colour that gives WCAG 2 AAA Compliance for black background is #959595 which looks like this. --Redrose64 (talk) 22:28, 18 August 2014 (UTC)

A test with the colours given.

Ok, if you all insist on being so helpful, here are some colours that I think work well for my eyes, based on some tests in a word processor:

• Background: #333333
• Text: #cccccc
• Link: #94bd5e
• Visited link: #6e9d30

These colours don't fit the contrast standards, but contrast is not what I'm after. These colours are comfortable to me. Do you require any others? (As far as I can see, Wikipedia only really has 4 main colours) Thanks.

Thennicke (talk) 07:22, 19 August 2014 (UTC)

Thennicke: Thanks, that's a good starting point. There is another colour, the links to nonexistent pages (red links). Do you wish to keep the red colour, or would you prefer another ?

The contrast for the chosen colors are fine for personal use. But visited links might be difficult to distinguish from regular links. Dodoïste (talk) 20:14, 19 August 2014 (UTC)

Something like #F39494 would probably be a good colour for redlinks. Also, I am aware of the difficulty with distinguishing the green links; I tried to play around with the visited link colour for a while, and it's still a way off. If you keep #49bd5e and change #6e9d30 to be more suitable, that would be cool. I don't know how you'd do it, but if you find the difference in lightness between Wikipedia's default link colours, you might be able to apply the same function to #94bd5e. Thennicke (talk) 07:41, 20 August 2014 (UTC)

Thennicke, I'm working on this skin, and I've done most of the job. I still need to work on specific areas such as the logo, left and top navigation menus, the revision history, diffs, the preferences menu, the watchlist, the notifications feature... My draft is at User:Dodoïste/vector.css. Dodoïste (talk) 20:49, 21 August 2014 (UTC)

I am following this development with interest. I use the green-on-black skin. It is somewhat garish, although I am used to it. More importantly, I am unable to view many diagrams properly—often the labels or lines do not appear. Also, I am unable to view the WP:GAN pages, and I have stopped undertaking GA reviews as a result. Axl ¤ [Talk] 10:53, 20 August 2014 (UTC)

Hi User:Axl ! :-) I'm focusing my efforts on the new skin currently, but I'll be glad to help you out once I'm done with this. However, I'm sure you could find many other people to help you solve specific problems such as the GA reviews pages. It's quite simple to do for people who knows CSS, and there are many such users in the Wikipedia community. Have you ever tried Wikipedia:Village pump (technical) ? Dodoïste (talk) 20:49, 21 August 2014 (UTC)

Thanks. No, I did not try Village pump (technical). I commented here in 2013, but one person who responded could not help. Axl ¤ [Talk] 22:11, 21 August 2014 (UTC)

@Axl: Looking at Wikipedia:Good article nominations/New Proposals for GAN, Part II#Axl, Aircorn seems to be unable to work out how you see green on black; but in that thread, I can't see any mention of the "Use a black background with green text" gadget. It's at Preferences → Gadgets, second from bottom of the "Appearance" section, but is only listed there if you have saved your preferences since selecting the MonoBook skin at Preferences → Appearance. --Redrose64 (talk) 23:29, 21 August 2014 (UTC)

Thanks, I realised that by following Thennicke's original link. I tried asking for help before and it didn't work out. (We are all volunteers here so I don't feel entitled.) I shall carry on contributing to Wikipedia in my own way. Axl ¤ [Talk] 09:24, 22 August 2014 (UTC)

Dodoïste, I tried out the skin, and it's looking really good so far! Lots of bugs pulled over from the base skin, of course, but a great start. I'm particularly liking the look of plain article text. Thank you so much for putting the effort into this. I noticed that external links are still light blue, and I'd propose a lighter green to replace them (#a9bd8e?).

By the way, I recently found this, which might be of interest to all. Thennicke (talk) 10:31, 22 August 2014 (UTC)

Thennicke : I'm pleased to hear that you like it! :-) It's almost complete now, I think you can start using the skin at User:Dodoïste/vector.css. Let's say the skin is in beta version, and you can start reporting bugs. By the way, I did not define a color for visited external links and visited interwikis. Do you wish to have one ?

What I still need to do:

1. Change the color background of current (selected) tabs at the top of the page (article, discussion, edit, etc.). The color should be the same as the main background color, to keep the same interaction design as Vector. The image is in base64, and I'm having a difficult time to change it.
2. Same problem with the preferences page.
3. Every new feature Vector has (there are several).

RexxS, could you help me with the tasks 1) and 2) ? I guess as a designer you have experience with base64 images ?

It is expected that some templates and fancy layout will stay in light background and dark text. Especially in the userspace and community space. We should create a task force to encourage Wikipedians to not specify text color and background color with inline CSS, and change these templates. It is a very long task. Dodoïste (talk) 20:44, 24 August 2014 (UTC)

Salut Dodoïste! I've not had much time to try things out, but a small grey image (4x4px #333333) is encoded as:

• background-image: url(data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAQAAAAECAIAAAAmkwkpAAAALHRFWHRDcmVhdGlvbiBUaW1lAFN1biAyNCBBdWcgMjAxNCAyMzowMTo0OCAtMDAwMCTOXR0AAAAHdElNRQfeCBgWAyhHDse1AAAACXBIWXMAAAsSAAALEgHS3X78AAAABGdBTUEAALGPC/xhBQAAABRJREFUeNpjNDY2ZoABJgYkgJsDAB7mAKE07xU1AAAAAElFTkSuQmCC);

So if you use that for #mw-page-base, #mw-head { , you get the same background heading all the way to the top of the page. Did you intend the same for the all the tabs? I'll have another look tomorrow.

There's a useful online resource for encoding images into base64 at http://webcodertools.com/imagetobase64converter/Create

It occurs to me that we normally only use the Data URI scheme for making gradients or complex backgrounds. I think you ought to be able to get the same effect by setting #mw-page-base, #mw-head { background-image:none; background-color:#3333; }, but I'll check later. Cheers --RexxS (talk) 22:51, 24 August 2014 (UTC)

Dodoïste, I've been using the skin for a few weeks now, and I've found 3 or 4 bugs on Wikipedia. On other projects, there are all sorts of clashes (see main page of Wikiversity for example). However, on Wikipedia, it's already suitable for my daily use. Well done! Here's a list of things that I've noticed, in rough order of importance:

• Block quotes are unreadable (e.g. Spanish Revolution)
• Mathematical formulae... I know these are tricky to fix, but they look horrible. (e.g. Pi)
• Gallery images have large blocks of white around them (e.g. Bombard#Gallery page)
• Chemical formulae are dark, though still readable (e.g. Triclosan)

Thanks! Thennicke (talk) 06:06, 7 September 2014 (UTC)

Animated gifs of text

Most if not all of the images in Template:Wikipedia-adnavbox are animated text adverts for wikiprojects. How should we respond? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:42, 9 September 2014 (UTC)

Simplest way is to set the alt text for the image to something sensible for screen readers and for those who have images disabled. I've made an attempt at that. Is that good enough? --RexxS (talk) 17:33, 9 September 2014 (UTC)

OMFG ! It happened. <blink> zombies are coming to get you, run for your life! Dodoïste (talk) 20:46, 9 September 2014 (UTC)

No, don't blink. --Redrose64 (talk) 06:52, 10 September 2014 (UTC)

Well... Per Wikipedia:Manual_of_Style/Accessibility#Animations, animated GIFs should not exceed 5 seconds. Or they should be equipped with control functions (play/pause). The most important thing is the ability to pause them, as it can be very distracting for some users...

I believe we should discourage the creation of animated adverts. I guess they will not like this answer, and it might be hard to convince them to stop... Dodoïste (talk) 20:57, 9 September 2014 (UTC)

I feel the same, but you know how folks can behave when they've invested time and effort into something. At least they supplied advice on how to turn the ads off - by putting the following into Special:MyPage/common.css:

.qxz-ads { display: none !important; }

Although that's unavailable to readers who are not registered editors; i.e. 99% of visitors will see the ads whether they want to or not. --RexxS (talk) 22:08, 9 September 2014 (UTC)

Thank you. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:31, 9 September 2014 (UTC)

It gets worse; see: {{Wikipedia ads}}. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 22:31, 9 September 2014 (UTC)

I first came across the {{Wikipedia ads}} template when I made this edit. It's not in my change: look below the "Revision as of 14:35, 8 September 2014" heading. --Redrose64 (talk) 06:52, 10 September 2014 (UTC)

Superscripted reference marks

At Wikipedia:Village pump (idea lab)/Archive 14#Easy copy and edit, there appears to be a user who has accessibility issues with the superscripted marks used for referencing. I might be entirely wrong though. --Redrose64 (talk) 18:07, 20 September 2014 (UTC)

COinS metadata

There may be an accessibility issue with the COinS metadata that is appended to citations emitted by the {{citation}} template as well as all the Citation Style 1 templates. See Wikipedia:Village pump (technical)/Archive 130#Spurious text on source links. --Redrose64 (talk) 22:56, 24 September 2014 (UTC)

Image positioning at Chihuahua (dog)

Could somebody deal with the gallery of images that is placed within running text in the appearance section of the Chihuahua article? It's after the text " Pet-quality Chihuahuas (that is, those bred or purchased as companions rather than show dogs) often range above these ...". The gallery is in a remarkably bad position for screen readers, which read pages linearly. Graham87 10:23, 25 September 2014 (UTC)

I moved the gallery out of the sentence into the next paragraph break. The captions seem to be related to the paragraph which it now precedes. --Redrose64 (talk) 11:52, 25 September 2014 (UTC)

Thanks, that's much better. And good to know there's an entry in the Manual of Style about it! Graham87 12:33, 25 September 2014 (UTC)

Comment on the WikiProject X proposal

Hello there! As you may already know, most WikiProjects here on Wikipedia struggle to stay active after they've been founded. I believe there is a lot of potential for WikiProjects to facilitate collaboration across subject areas, so I have submitted a grant proposal with the Wikimedia Foundation for the "WikiProject X" project. WikiProject X will study what makes WikiProjects succeed in retaining editors and then design a prototype WikiProject system that will recruit contributors to WikiProjects and help them run effectively. Please review the proposal here and leave feedback. If you have any questions, you can ask on the proposal page or leave a message on my talk page. Thank you for your time! (Also, sorry about the posting mistake earlier. If someone already moved my message to the talk page, feel free to remove this posting.) Harej (talk) 22:47, 1 October 2014 (UTC)

Web accessibility guidelines?

From a new editor (Mysticjeff), I got the feedback that "The site doesn't conform to web accessibility guidelines which would allow me as a blind person to easily work in the site." Could someone please respond to @Mysticjeff: (preferably by email)? Thanks! Jodi.a.schneider (talk) 14:11, 14 October 2014 (UTC)

Thanks for the note here. I've sent him an email. Graham87 15:53, 14 October 2014 (UTC)

Cheers Graham! Jodi.a.schneider (talk) 16:22, 14 October 2014 (UTC)

tooltips / rollover captions - input requested

At Wikipedia talk:In the news#Rollover / tooltip for RD entries we are discussing an idea to add a tooltip or rollover (image) caption to recent deaths entries (currently just a plain link) to give basic details. This discussion would benefit from input by those with knowledge and interest in accessibility issues. Thanks, Thryduulf (talk) 19:59, 30 October 2014 (UTC)

WikiProject X is live!

Hello everyone!

You may have received a message from me earlier asking you to comment on my WikiProject X proposal. The good news is that WikiProject X is now live! In our first phase, we are focusing on research. At this time, we are looking for people to share their experiences with WikiProjects: good, bad, or neutral. We are also looking for WikiProjects that may be interested in trying out new tools and layouts that will make participating easier and projects easier to maintain. If you or your WikiProject are interested, check us out! Note that this is an opt-in program; no WikiProject will be required to change anything against its wishes. Please let me know if you have any questions. Thank you!

Note: To receive additional notifications about WikiProject X on this talk page, please add this page to Wikipedia:WikiProject X/Newsletter. Otherwise, this will be the last notification sent about WikiProject X.

Harej (talk) 16:56, 14 January 2015 (UTC)

Applying MOS to filmographies, or not

We need a consensus at the filmography project regarding accessible tables with rowspan. Or removing rowspan from MOS...either solution would sit well with me. Xaxafrad (talk) 21:00, 14 January 2015 (UTC)

Awards arranged in two columns using tables for layout

Update: I've added a before-and-proposed-after example further down this thread that solves the accessibility issue while retaining a layout table. Thisisnotatest (talk) 22:35, 19 January 2015 (UTC)

I'm seeking Accessibility project assistance on an accessibility dispute over at the 87th Academy Awards talk page. The nominations table is laid out as a table, using table markup. I edited the page to convert to linear markup. My understanding is that table layout for non-tabular information is supposed to be accomplished through div tags and CC, not through table markup, per Wikipedia table inappropriate use guidelines for page layout, although I did not attempt to accomplish this, only to fix the accessibility violation. My edit was reverted on the basis that all awards are done as table markup and have been for several years. It was suggested I raise the issue here and that my change would require consensus. (Or most? I see the 31st Golden Globe Awards page uses a list for nominees. Anyway, all new ones seem to use tables for layout.) There are a number of issues here:

1. Is consensus needed to fix a fixable accessibility issue?
2. Does the person fixing the accessibility issue need to also come up with the alternate div/CSS code that provides the same look and feel before removing the accessibility barrier?
3. Is it appropriate to add the AccessibilityDispute template to multiple pages in the same series of pages if they all have the same accessibility issue?

I don't want to get involved in an edit war. It was suggested I bring this discussion here to the Accessibility project, so I am doing so. Thisisnotatest (talk) 01:21, 19 January 2015 (UTC)

I'm adding a description of the issue for the benefit of those not familiar with accessibility: Awards tables as they currently exist on Wikipedia don't make sense read left-to-right then top-to-bottom. A blind person having an Academy Awards nominations table read to them by software that reads the screen to them would hear two different award names before hearing the nominations for the first of the two categories. If they were aware of the table structure, they could read down the first column then read down the second column and not get anything out of sequence, but (1) they'd have to be able to figure that was how the table was arranged and (2) they would get the awards in a strange sequence, e.g., Best Actress about 10 categories after Best Actor. Thisisnotatest (talk) 01:47, 19 January 2015 (UTC)

This whole idea of accessibility (for blind people, for example) is an issue with which I am wholly unfamiliar. And I am hearing for the first time, after being an editor for 7-8 years. So, this is all "new" to me. I have a question. I read what your concerns are about the page being read left-to-right, etc. But doesn't that occur all the time (regardless of tables)? For example, InfoBoxes are usually placed on the right hand side of a page. (For example, see this page: Abraham Lincoln.) Doesn't that also get "screwed up" if the page is being read left-to-right? Or how about when there are photos, and the photos have a caption underneath? I have no idea. So, I thought I'd ask.Thanks. Joseph A. Spadaro (talk) 02:20, 19 January 2015 (UTC)

Thank you for asking. One of the challenges with making content accessibile is that often the issues are not obvious to a sighted viewer. In the case of InfoBoxes, they are structurally placed in a certain sequence in the underlying code. So they might be read aloud at the start of the article or the end of the article, but they won't get mixed up with the text that is beside them. Table cells, on the other hand, are structured left-to-right then top-to-bottom, cell by cell. This is why Wikipedia's guidelines say not to use tables for layout. They don't say you can't achieve a table-like appearance, only that you need to use div tags and CSS to achieve that look, not table/tr/td tags. Thisisnotatest (talk) 02:37, 19 January 2015 (UTC) (Added "cell-by-cell to the above". Thisisnotatest (talk) 02:41, 19 January 2015 (UTC))

Thanks. Well, therein lies the problem. For me, at least. I do not understand (nor do I wish to) all of that "computer lingo" that goes on behind the scenes. All of that computer code (or whatever it is). When you talk about "div tags and CSS to achieve that look, not table/tr/td tags", I have absolutely no idea what any of that means. But, yes, I see your overall point. Joseph A. Spadaro (talk) 02:45, 19 January 2015 (UTC)

And I see your point. Any solution depending on highly technical code mastery by editors is not likely to be adopted. This would seem to call for some sort of template that would provide both accessibility and attractiveness. The accessibility issue still remains, and we need to reach consensus on whether to make the content accessible now or wait until a more automated solution can provide both attractiveness and accessibility. I was trying to find any community discussion related to the original switching awards nominations from sequential to tables. This switch appears to have happened around 2009 and 2010 and appears to have been accomplished with manual edits by various editors. Unfortunately, the pages that the March 2009 edits occurred on have been merged with other pages, which seems to have obliterated the relevant talk pages. — Preceding unsigned comment added by Thisisnotatest (talk • contribs) 02:56, 19 January 2015 (UTC)

@Joseph A. Spadaro:, if you choose not to learn about "all of that "computer lingo" that goes on behind the scenes", taht#'s fine; tehre's nothing requiring you to do so. But in that case, pease take advice from those who have, and do not impede their work to make this encyclopedia more widely accessible. YOu have already ben referred to Wikipedia guidelines on layout tables. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:23, 19 January 2015 (UTC)

@Pigsonthewing:, what exactly are you talking about? How, when, and where did I impede anybody's work? How, when, and where did I make this encyclopedia less accessible? The only thing I did was to post a comment at the 87th Academy Awards Talk Page. Some editor changed the chart to a list. And I indicated that that was a bold move that probably needed consensus. So, once again: How, when, and where did I impede anybody's work? How, when, and where did I make this encyclopedia less accessible? I'd like specifics. Thanks. Joseph A. Spadaro (talk) 16:20, 19 January 2015 (UTC)

@Joseph A. Spadaro: I apologise; from the above, I jumped to the conclusion that it was you who reverted, and who objected to, the conversion from a table. I see now that I was wrong. Sorry. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:26, 19 January 2015 (UTC)

Apology accepted. I believe that the editor (User:Thisisnotatest) changed the chart to a list; I indicated on the Talk Page that it was a bold move requiring consensus; and that very same editor (after reading my suggestion) then went in and reverted himself/herself making the list back into a chart. That is what I believe happened. Thanks. Joseph A. Spadaro (talk) 16:30, 19 January 2015 (UTC)

The actual sequence is I changed the table to a list then 50.135.127.104 reverted it. Thisisnotatest (talk) 22:17, 19 January 2015 (UTC)

Thanks for the clarification on that. I wasn't entirely sure. Which is why I said that I believed it to be the case, in my above post. Thanks. Joseph A. Spadaro (talk) 02:43, 20 January 2015 (UTC)

The tables have been used for many years in many different articles. It looks so much better with a table. This is the first time I ever heard somebody complain about them. I really don't see a problem with them. JDDJS (talk) 03:54, 19 January 2015 (UTC)

Also the 1st Academy Awards article is a featured list.. with the tables included. Has their been any study on how many blind people use reading devices to browse wikipedia? Spanneraol (talk) 04:05, 19 January 2015 (UTC)

Wikipedia's Manual of Style on Accessibility says "We aim to adhere to WCAG guidelines 2.0 (a.k.a. ISO/IEC 40500:2012)" and "Avoid using tables for layout purposes only." I don't see any point in rehashing a Project consensus. Thisisnotatest (talk) 04:29, 19 January 2015 (UTC)

There is currently an implied consensus to use the tables, so by having this conversation rehashing a consensus anyway. JDDJS (talk) 05:01, 19 January 2015 (UTC)

Touché. So I will respond to your comment then so that I can (re)hash this issue (not sure it's actually been hashed although I saw a 2010 reference to a 2009 discussion that I can't find using Google). In response to your comment, I went searching and found (1) That I was mistaken in saying Accessibility was a policy; it's a guideline and (2) simply citing rules is not appropriate on Wikipedia anyway and (3) Actually, I may have been wrong in following the suggestion to bring the discussion over here (however, that suggestion did come from someone who appears at this time to be opposed to my proposal, so I'll just try not to do it in the future rather than moving it back to the 87th Academy Awards talk page). That said, I've described above how use of tables for layout makes the awards tables not accessible. So that leaves the question of how many blind people read Wikipedia. And I have no way to answer that. So where to proceed? The question seems to be, if we indeed have to choose between accessibility and attractiveness for awards nominations, which improves Wikipedia more? I feel that accessibility does, because if the content is not accessible, then blind people will not be able to use, edit, and verify the content; this is a matter of social justice as well as ensuring more people can help make Wikipedia better. I agree that the tables are prettier than the lists, but if the tables were not there and lists were, I would not miss the tables or notice that the page was less attractive than it might be. Some people might miss it - which might discourage participation - and I seem to recall reading that a professional look does increase trust in the content of a website, although I can't source it right now. Conversely, using tables for layout is considered unprofessional these days in the web industry, so at the same time use of layout tables could decrease trust in the technical abilities of its editors - which might discourage participation by a different group of potential editors; some of them could likely provide accessible and attractive layout not involving tables but they could reasonably fear that other people would accidentally break it. I have no idea how big any of these populations are. Ultimately, I would prefer social justice, that we code such that people with disabilities be able to use the website. Thisisnotatest (talk) 07:40, 19 January 2015 (UTC)

I've attempted to mitigate the Canvassing offense by cross-posting a reference at the Village Pump. Thisisnotatest (talk) 08:33, 19 January 2015 (UTC)

There may be an implied local conensus to use tables for layout; but that does not override the project-wide consensus not to. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:23, 19 January 2015 (UTC)

I'd wonder how many people participated in the discussion originally at this accessibility page? It seems like the sort of thing a very narrow group of people would be interested in. Spanneraol (talk) 13:18, 19 January 2015 (UTC)

Who said anything about "this accessibility page"? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 13:55, 19 January 2015 (UTC)

That the current discussion is taking place on this page is likely an error on my part, and I'm open to an admin moving it to the proper place if am correct that I was wrong. The original discussion likely took place at the Wikipedia Manual of Style: Accessibility talk page. Thisisnotatest (talk) 22:17, 19 January 2015 (UTC)

While I prefer the two column tables because it reduces the size of the page, what if we use single single column tables? It will allow the pages to be easily accessible to blind people, but looks better then just a list. JDDJS (talk) 19:50, 19 January 2015 (UTC)

It's an idea to consider. And it would seem to solve the accessibility issue. In terms of aesthetics and appearance, however, wouldn't that make the page awfully "long" (extending downward with a one-column table), and result in a vast amount of "dead" (empty) white space to the right of the table, all the way down the page? Joseph A. Spadaro (talk) 20:13, 19 January 2015 (UTC)

Proposed solution

Sometimes I focus on the problem so much that I miss the solution. In brief, I'm proposing a solution. It does involve some code, but not much more code than the original. It's just a different technique than is currently being used, but one which conforms with Wikipedia guidelines and is accessible if read aloud in sequence as a layout table.

On trying to find the original discussion, I realized that Wikipedia:Manual_of_Style/Accessibility#Layout_tables does in fact say "For simple layouts tables can be an option." Still, it also says "do not use any caption, row, or column headers" and "Do not use structural elements for presentation purposes." The current two-column layout tables do in fact fail accessibility because the names of the awards both use the header marker ! and are in separate rows from the nominees of those awards.

However, if the names of the awards were in the same cells, and styled there without the !, there would be no accessibility issue. So the question then becomes, how do you put the name of an award and the award nominees into the same cell and style them differently? So, here's a snippet of the current, non-accessible table:

Best Picture

Best Director

American Sniper – Clint Eastwood, Robert Lorenz, Andrew Lazar, Bradley Cooper and Peter Morgan Birdman – Alejandro González Iñárritu, John Lesher and James W. Skotchdopole Boyhood – Richard Linklater and Cathleen Sutherland The Grand Budapest Hotel – Wes Anderson, Scott Rudin, Steven M. Rales and Jeremy Dawson The Imitation Game – Nora Grossman, Ido Ostrowsky and Teddy Schwarzman Selma – Christian Colson, Oprah Winfrey, Dede Gardner and Jeremy Kleiner The Theory of Everything – Tim Bevan, Eric Fellner, Lisa Bruce and Anthony McCarten Whiplash – Jason Blum, Helen Estabrook and David Lancaster

Wes Anderson – The Grand Budapest Hotel Alejandro González Iñárritu – Birdman Richard Linklater – Boyhood Bennett Miller – Foxcatcher Morten Tyldum – The Imitation Game

The above table is not accessible because (1) !, a structural element is used to achieve centering and formatting and (2) a blind user will hear: "Best picture Best director American Sniper...David Lancaster Wes Anderson..."

Here is the same table re-cast as an accessible table:

Best Picture American Sniper – Clint Eastwood, Robert Lorenz, Andrew Lazar, Bradley Cooper and Peter Morgan Birdman – Alejandro González Iñárritu, John Lesher and James W. Skotchdopole Boyhood – Richard Linklater and Cathleen Sutherland The Grand Budapest Hotel – Wes Anderson, Scott Rudin, Steven M. Rales and Jeremy Dawson The Imitation Game – Nora Grossman, Ido Ostrowsky and Teddy Schwarzman Selma – Christian Colson, Oprah Winfrey, Dede Gardner and Jeremy Kleiner The Theory of Everything – Tim Bevan, Eric Fellner, Lisa Bruce and Anthony McCarten Whiplash – Jason Blum, Helen Estabrook and David Lancaster

Best Director Wes Anderson – The Grand Budapest Hotel Alejandro González Iñárritu – Birdman Richard Linklater – Boyhood Bennett Miller – Foxcatcher Morten Tyldum – The Imitation Game

Not exactly the same but attractive, IMO, and accessible. It's accessible because (1) formatting is achieved without ! markup and (2) the name of the award is at the beginning of the same table cell. A blind user will hear "Best Picture American Sniper...David Lancaster Best Director Wes Anderson..."

Thisisnotatest (talk) 22:19, 19 January 2015 (UTC) amended Thisisnotatest (talk) 23:16, 19 January 2015 (UTC)

That solution works for me... though i dont have the time or patience to try to go back and edit all the awards pages to conform. Spanneraol (talk) 23:21, 19 January 2015 (UTC)

I'm just trying to reach a consensus between accessibility advocates and attractiveness advocates so that if I were to go in and convert the pretty, non-accessible tables to pretty, accessible tables, that it won't just get reverted. Thisisnotatest (talk) 23:48, 19 January 2015 (UTC)

There is still the side question of which page or pages get the AccessibilityDispute template until this is resolved. I also flagged the 85th and 86th Academy awards, but the discussion is currently active around the 87th. I ask because the template was removed from the 86th and I reverted. Technically, it would be correct to mark all non-compliant awards pages, not that I have the patience to do that. The purpose would be to (1) Call attention to blind people that they may encounter difficulty with those pages and (2) Encourage editors with know-how to copy my code and patience to fix those pages to join in fixing the pages and (3) allowing them to find those pages easily at the AccessibilityDispute What Links Here page. Thisisnotatest (talk) 00:57, 20 January 2015 (UTC)

I've reviewed a few of these articles at FLCs. My first impression is that Thisisnotatest has provided an elegant solution above as it retains the aesthetics while fixing accessibility issues which are important. Cowlibob (talk) 23:19, 21 January 2015 (UTC)

I'm not sure how a table with no header row marked up is "more accessible". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:20, 24 January 2015 (UTC)

@Andy: I thought that at first. The answer is that header rows aid screen readers to navigate around a data table's structured information. These tables are being used purely for layout so that every other row is a header. No screen reader will gain any benefit from having them marked up. What is actually happening is that the headers should be the list headers for the list below (and we both know that element is missing from html, <grin>). The most semantic solution - and hence most accessible - is to closely associate the headers with the lists by putting them inside the same layout cell. That means screen readers, which will almost certainly read these tables linearly (i.e. left-to-right, then top-to-bottom), will announce the name of the award immediately before the list of nominees. The previous layout didn't do that and Thisisnotatest's changes to place the name of the award and the nominees in the same cell is an improvement. --RexxS (talk) 15:09, 24 January 2015 (UTC)

Replaced non-accessible table with accessible table over at 87th Academy Awards page. Thisisnotatest (talk) 09:11, 24 January 2015 (UTC)

Thank you RexxS for your assistance in templating this. I made some slight adjustments and have implemented it on the 87th Academy Awards page. Thisisnotatest (talk) 08:42, 25 January 2015 (UTC)

Tiny ping

The accessibility of {{Tiny ping}} is being discussed. Please make your views known there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:39, 31 January 2015 (UTC)

Imminent MediaWiki feature that will impact accessibility for screen reader users

Please see T18691 Section headings should have some clickable anchor for passing links, particularly my comment there. Graham87 15:05, 1 March 2015 (UTC)

Sports infoboxes

The accessibility of {{Infobox NFL player}}, and some other sports infoboxes, which do not use {{Infobox}}'s |label= parameters, is under discussion. Please join in there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:06, 21 March 2015 (UTC)

Template multiple images

Hi folks ! I have reported an accessibility issue at Template talk:Multiple image/Archive 1#Accessibility issues. This template is included in 14'000 articles and growing rapidly. It would be good to deal with before it gets out of hand. Could you share your thoughts there ? Thanks, Dodoïste (talk) 10:32, 24 March 2015 (UTC)