Wikipedia talk:WikiProject Accessibility/Archive 6

WikiProject Accessibility/Archive 6
WikiProject Accessibility/Archive 6
Date	First Sunday following 5 January

WikiProject Accessibility/Archive 6
WikiProject Accessibility/Archive 6
Date	First Sunday following 5 January

This is an archive of past discussions about Wikipedia:WikiProject Accessibility. Do not edit the contents of this page. If you wish to start a new discussion or revive an old one, please do so on the current talk page.

Archive 1

←

Episode lists with alternating color rows

Suggest that when we encounter pages with episode lists that have alternating row background colors (e.g., List of Fifth Gear episodes and List of Top Gear Australia episodes), we convert them to templates (e.g., List_of_The_Simpsons_episodes#Episodes. The latter seems to be the most common way of listing episodes and now that Category:Articles using Template:Infobox television season with invalid colour combination is cleared out we can be sure the color combos are adhere to WP:COLOR.

On a related note... I'd love to see the series overview sections converted to a template so that they can be tracked with the categories. Most seem to use plain wiki table code. Is this something we could get a bot to handle perhaps, or a script? EvergreenFir (talk) Please {{re}} 20:42, 27 August 2015 (UTC)

A template exists, once again courtesy of Alex {{Series overview}}. - Favre1fan93 (talk) 21:50, 27 August 2015 (UTC)

And those two examples you linked should definitely use the standard ep table format, without the color alternating rows. - Favre1fan93 (talk) 21:52, 27 August 2015 (UTC)

Thanks. I'll change them when I see them. EvergreenFir (talk) Please {{re}} 21:56, 27 August 2015 (UTC)

More colour tracking categories

There's no end in sight, is there? Alakzi (talk) 19:08, 28 August 2015 (UTC)

If there were a end in sight, somebody would edit the background to make sure we couldn't see it. --RexxS (talk) 00:09, 29 August 2015 (UTC)

You've got to wonder, just what were they thinking? Alakzi (talk) 00:21, 29 August 2015 (UTC)

But colors! ~ Rob^Talk 00:23, 29 August 2015 (UTC)

After having laid my poor eyes on Great North Run (that's Great North Run), I've decided to improvise. Alakzi (talk) 00:26, 29 August 2015 (UTC)

Rather than going such an extreme route, which will almost certainly be reverted and probably should be, have we considered maybe gaining wide consensus on how WP:COLOR violations in infoboxes should be dealt with? I bet it would be very easy to get consensus at an RfC to template the talk pages of violations and then change the template to disallow invalid color combinations 14 days later after editors have a chance to address the issue. Standardizing the procedure on how to do this would avoid having to seek consensus on how to implement this dozens or hundreds of times as we uncover more and more templates with frequent violations. ~ Rob^Talk 01:09, 29 August 2015 (UTC)

Consider discussing this at WP:VILLAGEPUMP, where individual WikiProjects won't feel as threatened or be as likely to defensively protect their territory.—Bagumba (talk) 01:22, 29 August 2015 (UTC)

I could handle an AWB bot to template those talk pages, by the way. ~ Rob^Talk 01:11, 29 August 2015 (UTC)of

Maybe consider excluding those which have no text on the background colour. They simply have a short bar of colour. All the best: Rich Farmbrough, 01:44, 29 August 2015 (UTC).

That was just Alakzi's improvisation I guess.

How about this? (Using the tools you guys have already made to automatically chose black or white text.)

All the best: Rich Farmbrough, 02:19, 29 August 2015 (UTC).

That's what we usually do, but we're still going to have to fix the AA's. Alakzi (talk) 08:06, 29 August 2015 (UTC)

First category clear. Alakzi (talk) 08:49, 29 August 2015 (UTC)

BTW 4.5 is fine for 18pt or 14pt bold. I created the poorly named {{Ensure AA contrast ratio}} for this reason. Guess I should move it to {{Ensure 4.5 contrast ratio}}. All the best: Rich Farmbrough, 14:36, 29 August 2015 (UTC).

The specification defines 14 pt as "roughly equivalent to 1.2 ... or to 120% ... of the default size for body text (assuming that the body font is 100%)". The headers are 15.4 pixels in size, where the default is 16 pixels, and thus roughly 96% of the "default size for body text". Alakzi (talk) 14:43, 29 August 2015 (UTC)

IS that a vector thing? Because for me, in Monobook, the headers are twice the body text. All the best: Rich Farmbrough, 17:48, 29 August 2015 (UTC).

Nominally 15.8833px vs 12.7px = 1.2506535433071. All the best: Rich Farmbrough, 17:55, 29 August 2015 (UTC).

(BTW [1] this editor seems to have made some of the odd changes of colour.) All the best: Rich Farmbrough, 00:31, 30 August 2015 (UTC).

AWB now removes blank lines between a list

Just added to the development version, AWB will now remove blank lines between unordered lists per WP:LISTGAP. This will be available in the next stable release of AWB. Bgwhite (talk) 17:03, 4 September 2015 (UTC)

Cool! How about lists separated by image markup? Graham87 06:26, 5 September 2015 (UTC)

Magioladitis has added it to his todo list. It will be added as an alert instead of AWB moving the images. Moving image could get tricky. Bgwhite (talk) 07:33, 6 September 2015 (UTC)

Color palette of Wikimedia projects to comply with WCAG 2.0 AA

Hi,

I'm in contact with M Galloway (WMF), alias violetto. She is working on the following task :

Listing the different uses of color across Wikimedia projects
Establish a new color palette and a list of contrasts to be used on WIkimedia projects - WCAG 2.0 AA Compliant : https://phabricator.wikimedia.org/T109915
Merge several pages on the topic into a single page, aimed at developers and Wikimedia volunteer editors : https://phabricator.wikimedia.org/T110727

This project could be really useful for accessibility. I've noticed a few other projects from her that aims to improve accessibility, she seems to be doing a good job. She contacted me asking for my opinion, I've offered a collaboration. And I recommeded user:RexxS to her, he might be more active than me ?

I'm just keeping you updated on what is currently happening. Not much you can do to help at this point. Cheers, Dodoïste (talk) 14:35, 16 September 2015 (UTC)

Please see a discussion

You are invited to comment at Wikipedia talk:Manual of Style/Accessibility#Colour. BethNaught (talk) 16:00, 20 September 2015 (UTC)

Baseball template colors discussion

The discussion at Wikipedia_talk:WikiProject_Baseball#Proposed_color_changes may be of interest to members of this WikiProject, as it's delving into contrast issues. ~ Rob^Talk 01:13, 24 September 2015 (UTC)

Accessibility of the... Wikiproject menu !

Hi there,

When the Wikipedia:WikiProject Accessibility/Navigation menu was standardised trough the Sidebar template, some of its qualities were lost in the process.

Notably, color contrast. The foreground color #0144AC of the [show] / [hide] links in the blue background #DDDDFF was AA compliant but not AAA. And the layout was terrible.

So I've improved this menu a little. I believe the WikiProject itself should be a good example of its own guidelines. :-) Cheers, Dodoïste (talk) 22:04, 29 September 2015 (UTC)

Content color blindness accessibility

I'm drafting a grant application for a color blindness detector at meta:Grants:IEG/Color blindness content checker. Only a 6 month process for 2 weeks worth of work. — Dispenser 17:22, 4 May 2015 (UTC)

On a related note there's a TTS proposal. I find it a silly idea. — Dispenser 17:47, 4 May 2015 (UTC)

I forgot to mention it here, but you might be able to still sneak a support under the wire at m:Grants:IEG/Alt text tools. — Dispenser 12:27, 30 September 2015 (UTC)

Web Accessibility - topic for November 10 Tip-Of-The-Day

Greetings! On November 10, the Tip-Of-The-Day is about the web accessibility. The tip is Editing articles for web accessibility and includes a link to Wikipedia's web accessibility page.

This November 10 tip was recently added at the TOTD Schedule Queue and is also posted at the Tips library. Regards, JoeHebda (talk) 23:30, 30 September 2015 (UTC)

Thanks a lot ! I replied at the talk page Wikipedia talk:Tip of the day/November 10. Dodoïste (talk) 00:04, 3 October 2015 (UTC)

Frequently asked questions and misconceptions

Hi,

I've been wanting to write this page for several years : Wikipedia:WikiProject Accessibility/FAQ and common pitfalls. I've just started with one example.

Do you have any ideas of FAQ or common misconceptions to share ? My imagination is lacking. :-) Dodoïste (talk) 22:29, 29 September 2015 (UTC)

Yes; it's a misconception that AA is "good enough". Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 00:21, 30 September 2015 (UTC)

What Andy said, basically. Policy requires us to meet AAA "wherever feasible". Since color is never essential to navigating the site (except in actual images, where we need an accurate representation of reality), it is always feasible to meet AAA in things like templates, and therefore required by policy. ~ Rob^Talk 00:40, 30 September 2015 (UTC)

Thank you, Rob. I've reused your wording in the above document, Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:41, 30 September 2015 (UTC)

Your answers are really interesting. I think I was right to bring this topic to discussion. As it turns out, some things have evolved since 2010 and I needed an update too.

I think we can all agree that the most important requirements are A level requirements because they are the most critical and they have the most impact. Meeting only A level requirements is "not enough". We should at least achieve AA level. I guess saying that AA level is "good enough" was a really bad way to put it. Some AAA level are easy to achieve and have some impact. But at the same time, aiming for AAA level without prioritization or distinction between the criterias is a really bad idea.

What do you people think about the current level of accessibility on Wikipedia ? Do you think we meet all A level requirements ? Should we not ensure that we already meet A level requirements before aiming for AAA level ?

It also raises the question of the benefit of meeting AAA level requirements. If I recall correctly, some AAA level guidelines are not adequate for all websites. Each website has to weight the cost / benefit to meet AAA level requirements.

I believe Wikipedia should aim for AA level consistently, plus all Level AAA guidelines we can reasonably meet. But not all AAA guidelines.

Here are some sources :

Why do we need WCAG Level AAA?, Whucag, February 10, 2015 by Luke McGrath
Understanding WCAG Level, karlgroves, May 20, 2013

Dodoïste (talk) 13:31, 30 September 2015 (UTC)

"Should we not ensure that we already meet A level requirements before aiming for AAA level ?" No; if page X fails "A", but fixing it will be difficult (either technically or, say, because of a lack of consensus as to how to proceed) and page Z fails "AAA", but can easily be fixed, page X is not a reason not to fix page Z. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:02, 2 October 2015 (UTC)

Sure. :-) I feel like I'm really having a hard time to express my thoughts clearly. I'll try differently.

My point is that I have the feeling that several people might insist a lot about reaching AAA level - even when it's a difficult case. For example, reaching AAA color contrast is often really difficult for several WikiProjects that use a particular color scheme. But some people might insist that AA level is not good enough, we have to be perfectly accessible. Thus spending a lot of energy on a particular case, without looking at the big picture. There might be more crucial accessibility problems to fix. And aiming to reach AA accessibility level is already a very difficult challenge given the nature of Wikipedia. Dodoïste (talk) 00:16, 3 October 2015 (UTC)

Bolded Japanese characters

Bolded Japanese characters appear to be quite hard to read for those with 20/20 vision, let alone those who have impaired vision. As many templates that may include Japanese characters apply bold font weights automatically, this could affect a large number of articles without editors even intending to use the bolded text. I've started a discussion on how we might go about fixing this at Wikipedia_talk:WikiProject_Japan. I encourage you to take a look at the discussion and participate. ~ Rob^Talk 01:39, 30 September 2015 (UTC)

These bolded characters might indeed be difficult to read. And I think you are right. I just want to inform you that this has nothing to do about accessibility. It's about readability. Dodoïste (talk) 13:34, 30 September 2015 (UTC)

Why do you think that readability is not part of accessibility? --RexxS (talk) 12:48, 1 October 2015 (UTC)

Because it impacts all users regardless of disability. There is no discrimination.

For example, imagine that someone would seal the entrance of a building with a wall of bricks. Sure, disabled people would not have access to it, but noone would. There is no discrimination in that. Dodoïste (talk) 23:01, 1 October 2015 (UTC)

But that would still reduce the accessibility of the building, wouldn't it? Let me make this clear: The International Organization for Standardization defines accessibility as the "extent to which products, systems, services, environments and facilities can be used by people from a population with the widest range of characteristics and capabilities to achieve a specified goal in a specified context of use." (ISO TC 159). It is a mistake to think that accessibility only applies to people with disabilities, and we have a duty to ensure that the content of our website "can be used by people from a population with the widest range of characteristics and capabilities". Readability is very much an integral part of of accessibility and is clearly in the scope of this WikiProject. --RexxS (talk) 19:42, 2 October 2015 (UTC)

There are several definitions for "Accessibility". One refers to most of the "normal" population being able to access the building - omitting people with disabilities. One refers to people with certain disabilities being able to use the building - omitting "normal people". The definition you wrote would rather refer to universal accessibility.

I'm not opposed to broaden the scope of this WikiProject. But so far we have followed W3C's Web Accessibility Initiative approach and guidelines. Their definition of accessibility is only about people with disabilities... All of our guidelines are about the disabled. We haven't written anything regarding "accessibility for normal people" or universal accessibility so far in this project. Dodoïste (talk) 23:50, 2 October 2015 (UTC)

The following guidelines in WP:ACCESS wholly or partly contain guidance aimed at improving accessibility for readers and editors not normally considered as having a disability:

so I'd say that the scope of the project is broadened already. WAI does indeed have a mission to improve accessibility for people with disabilities, but that doesn't mean it has to monopolise our concerns for accessibility. WAI says nothing about making our websites fully available to people in developing countries who are not disabled, but may have old technology, low bandwidth, small screens, or a combination of those. Nevertheless, they still need our attention to their needs. Similarly, being old is not considered a disability by WAI, but older viewers still need to be able to read our content, which, for example, effectively sets a lower limit on the size of text that we can use. It is fortunate that the changes to increase accessibility for people with disabilities will usually increase accessibility for others as well - as WCAG notes on its opening page. I'm not advocating any special treatment for those other groups, but I do firmly believe that if we don't concern ourselves with readability issues here, we can be pretty certain they won't be addressed anywhere else. --RexxS (talk) 01:37, 3 October 2015 (UTC)

Fair enough. :-)

These parts, especially the one about screen resolution have always disturbed me. They are important but they are not based on a source or anything. Which makes it difficult for us to handle as volunteers. I believe these are topics that the Wikimedia Foundations team of designers would need to address one day and make an official statement about what they recommend.

Until that happen, okay, fine with me. :-) Dodoïste (talk) 23:36, 5 October 2015 (UTC)

Adjectival format and Google Search speech-to-text

A report here refers to Panama Canal which starts with the following (simplified):

The Panama Canal is a {{convert|77.1|km|mi|0|adj=on}} ship canal

The Panama Canal is a 77.1-kilometre (48 mi) ship canal

The report says that Google's text-to-speech (after a search) says "seven seven point one dash k-i-l-o-m-e-t-r-e". Is there anything wikitext can do to workaround that issue? Johnuniq (talk) 22:43, 9 October 2015 (UTC)

As it said in the original discussion, that's Google's problem, not ours ... and the only way I could think to solve it would degrade the experience for mainstream users (replacing the hyphen with a space). Google's screen-reading products (especially those related to browsers) aren't widely used by blind people. Graham87 10:35, 10 October 2015 (UTC)

Thanks Graham, that makes sense. Johnuniq (talk) 01:58, 11 October 2015 (UTC)

Accessibility of new notification icons

I have raised concerns about the accessibility to those with poor eyesight of the new, paler, notification icons (mentions, talk page messages, etc) at Wikipedia talk:Notifications#Notification icon colours. It would be appreciated if knowledgeable people could comment there. Thryduulf (talk) 02:40, 20 November 2015 (UTC)

Broken subtitles

Hey All. I've just discovered that a lot of subtitles for audio and video files don't work properly. You can see (what I think is) the full list here if you want to help. You can fix them by putting them into SubRip text file format. Thanks. Brustopher (talk) 15:32, 30 October 2015 (UTC)

For users interested in this, I recently wrote a Quora answer that details how to write Wikipedia subtitles using amara.org. —TheDJ (talk • contribs) 11:10, 27 November 2015 (UTC)

Discuss: 'Back to contents' template

Greetings, Recently I added the {{Back to contents}} template to Wikipedia talk:Tip of the day at each of the 12 monthly Tip maintenance sections. Then at Template:Back to contents I noticed this template is being discussed for deletion at Wikipedia:Templates for discussion/Log/2016 January 13#Template:Back to contents. Wondering if keeping the template would be useful for accessibility purposes? Please send your responses to the above deletion discussion link. Regards, JoeHebda (talk) 15:48, 18 January 2016 (UTC)

Content donation of Audio Descriptions

Hi, VocalEyes has recently donated 40 audio recordings of audio descriptions of London landmarks, scripted for blind and partially sighted people. You can find them here on Commons https://commons.wikimedia.org/wiki/Category:Files_donated_by_VocalEyes Matthewcock (talk) 16:50, 18 January 2016 (UTC)

Help with alt text for Infobox oganization template

{{Infobox organization}} lists in the /doc a parameter for logo_alt but when editing a page with this included the server complains: "unknown parameter 'logo_alt'. If someone experienced with editing these things (I don't want to break it) could include the logo_alt feature so visually impaired individuals have access to same visual information that would be very helpful. -- dsprc ^[talk] 21:05, 25 January 2016 (UTC)

I see no reason that the template should be complaining. The text includes

| image2 = {{#invoke:InfoboxImage|InfoboxImage |image={{{logo|{{{organization_logo|{{{Non-profit_logo|}}}}}}}}} |size={{{logo_size|}}} |sizedefault=250px |alt={{{logo_alt|}}} }}

which clearly indicates it should be usable. Might be something wrong with Module:InfoboxImage. --Izno (talk) 22:04, 25 January 2016 (UTC)

It has been fixed.[2]; was simply left out of supported params. -- dsprc ^[talk] 22:12, 25 January 2016 (UTC)

Extended WAI-ARIA attribute support

The MediaWiki version to be deployed next week (1.27.0-wmf.12) whitelists the following attributes for all HTML elements:

aria-describedby
aria-flowto
aria-label
aria-labelledby
aria-owns
role (all values, not just presentation)

Now's a good time to brainstorm. I can think of a few possible uses for this. role="note" at Module:Hatnote, for example. Any other ways these attributes can help? Matt Fitzpatrick (talk) 22:32, 28 January 2016 (UTC)

role="note" is live on Module:Hatnote. Doesn't make a difference in Orca over Firefox. If someone could make sure that JAWS is announcing it properly, I'd be grateful. Matt Fitzpatrick (talk) 22:44, 12 February 2016 (UTC)

@Matt Fitzpatrick: Yep, it's working well on JAWS. I've had ... rather interesting experiences with Orca, and I wouldn't recommend using it for testing things. NVDA or even the JAWS demo on Windows would be better for that. Graham87 05:35, 13 February 2016 (UTC)

CSS overflow accessibility

See Wikipedia:Village pump (technical)#CSS overflow accessibility — Dispenser 06:09, 22 February 2016 (UTC)

Section numbering

How important from an accessibility point of view is the advice on maintaining a consistent set of section levels, as at WP:BADHEAD? Some wikiprojects, such as WP:BIRDS and more recently WP:PLANTS, have been adding coloured bands to the section headings on their project pages. To do this they don't use Level 2 section headings, instead having Level 3 as the lowest (and even then not always keeping the levels in order). As someone concerned with the semantics of mark-up I don't like it, but does it matter for accessibility? Peter coxhead (talk) 09:38, 19 February 2016 (UTC)

Moderately, I'd say ... it makes it easier to navigate headings if they're in a hierarchical order. On a scale of 1 to 10, I'd give it about a five. Graham87 11:43, 19 February 2016 (UTC)

Wikipedia:WikiProject Birds/Section header, for example? I think it can be improved. Matt Fitzpatrick (talk) 23:17, 22 February 2016 (UTC)

@Matt Fitzpatrick: Although the edits to Wikipedia:WikiProject Birds/Section header work great at moving the section titles to H2 tags, unfortunately it causes further problems with the section headings on mobile. At this time I get the impression that modifying section headings will almost always have unintended consequences, such as causing problems for mobile devices, possibly screenreaders, and rendering edit links inoperable.--MCEllis (talk) 01:28, 23 February 2016 (UTC)

@MCEllis: Doh, forgot to check mobile. Yeah, mobile skin was doing something to the h2's. Should be a little better now. Matt Fitzpatrick (talk) 05:11, 23 February 2016 (UTC)

Accessibility workshop Saturday February 27

Wikimedia DC is running a accessibility workshop tomorrow in Washington, DC. User:Harej had asked me some questions about missing alt text (covered in my IEG request) and in a few hours I prototyped the AltEdit tool. — Dispenser 19:44, 26 February 2016 (UTC)

LISTGAP

See the bot request for approval at Wikipedia:Bots/Requests for approval/BG19bot 9 for the discussion to approve a bot to remove blank lines between list items, per WP:LISTGAP. – Wbm1058 (talk) 13:25, 5 February 2016 (UTC)

Example

BEFORE

Wikicode:
* a

* b

* c

HTML:
<ul>
<li>a </li>
</ul>
<ul>
<li>b </li>
</ul>
<ul>
<li>c </li>
</ul>

Spoken by a screen reader as "List of 1 items, a, list end; List of 1 items, B, list end; List of 1 items, c, list end"

AFTER

Wikicode:
* a
* b
* c

HTML:
<ul>
<li>a </li>
<li>b </li>
<li>c </li>
</ul>

Spoken by a screen reader as "List of 3 items, A, B, C, list end"

To add spacing between items

HTML comment trick

Use the "HTML comment trick" to add a blank line between items in the wikicode to avoid editor confusion. This is done with a commented-out line:

* First item<!--
                                                 -->
* Second item

This doesn't produce unwanted visible spacing or bad list code in the rendered page like adding a plain blank line would:

First item
Second item

Extra * trick

A line containing just a "*" leaves a visible gap in the edit box, but produces a list item that is neither displayed, nor announced by screen readers because it has display:none set.

* long item a
*
* long item b

produces:

long item a
long item b

Questions

What's the best way to address people reverting this bot? ɱ (talk · vbm · coi) 13:40, 10 March 2016 (UTC)
- Was there an edit message or talk page post explaining why the single list should be split back to multiple lists of one item each? If not, maybe refer to WP:LISTGAP and give 'em an opportunity to unrevert? Matt Fitzpatrick (talk) 05:15, 17 March 2016 (UTC)

RfC on alignment of template headings

FYI

– Pointer to relevant discussion elsewhere.

Please see Template talk:Collapse top#RfC: Heading centered or left by default?, for a discussion that would affect the default text-align of the headers/titles of various content-box templates. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 13:43, 19 April 2016 (UTC)

RfC on replacing pseudo-headers

FYI, Talk:Glossary of video game terms#RfC: Replacing pseudo-headers. --Redrose64 (talk) 11:22, 27 April 2016 (UTC)

Template:Paragraph break at TFD

WikiProject Accessibility members may be interested in Wikipedia:Templates for discussion/Log/2016 May 17#Template:Paragraph break. --Redrose64 (talk) 19:18, 17 May 2016 (UTC)

I've given up on that discussion, since EEng is clearly out to discredit me no matter what. My question to this WikiProject is: does Template:Paragraph break assist with accessibility, or does it create accessibility problems, or is it accessibility neutral? Be honest, but please comment on that TfD, not here. --Redrose64 (talk) 20:13, 25 May 2016 (UTC)

Possible line break accessibility issue

Could you take a look at the pastcoaching parameter of the infobox at Marvin Lewis? Is this a MOS:VLIST issue? The coaching positions do go with the individual entries on the list, but I'm not sure if they break the list structure. It's certainly not a "best practice", but is this worth fixing with a bot? ~ Rob^Talk 16:46, 31 May 2016 (UTC)

This is fine and one of the reasons you might validly use . You could also use a , but this case could probably go either way. --Izno (talk) 16:58, 31 May 2016 (UTC)

Agreed. I would go so far as to say it's an exemplary use of   - it improves the visual display without causing any problems for screen readers that I'm aware of. Semantically I'd much prefer it to using ... to do the job in this case - the coaching position is too tightly related to the location in my mind for them to be in separate paragraphs. Just my opinion of course. --RexxS (talk) 00:00, 1 June 2016 (UTC)

Yep, sounds fine to me, as a screen reader user. Graham87 08:34, 1 June 2016 (UTC)

Thanks for the correction! ~ Rob^Talk 15:41, 6 June 2016 (UTC)

Accessibility issues in an infobox template

{{Infobox AFL biography}} has some bad issues with accessibility for those using screen readers. Please see here for more information and to participate in the discussion. ~ Rob^Talk 23:15, 19 June 2016 (UTC)

Module:Portal bar

I've proposed changes to Module:Portal bar (sandbox) that may affect accessibility. The two relevant changes are:

The container is a "portals navigation region" (JAWS default announcement) instead of nested tables.
The decorative icons are unlinked, with empty alt attributes.

See testcases for examples. Please leave a message at the template talk page if this can be improved in any way. Matt Fitzpatrick (talk) 20:26, 20 June 2016 (UTC)

@Matt Fitzpatrick: Please do not unlink "decorative" icons if they are licensed CC BY or CC BY-SA - under the terms of the license, attribution is required on each use, and a link to the file description page is an acceptable means of providing that attribution. Delinking (as you did here) is thus a breach of license terms. --Redrose64 (talk) 22:04, 20 June 2016 (UTC)

@Redrose64: Relinking for now. The links introduce a lot of useless noise, though. Images that can go unlinked are probably more appropriate for this use. Matt Fitzpatrick (talk) 22:24, 20 June 2016 (UTC)

Images that can go unlinked are those that don't require attribution. Mostly these are images that are licensed CC-0, or are explicitly public domain. Note that some PD images do require attribution - for example, images licensed {{PD-NASA}} require that "NASA should be acknowledged as the source of the material". --Redrose64 (talk) 22:45, 20 June 2016 (UTC)

You're right, better not to mess with links or attribution in this module. And thanks for the reminder, by the way! The second bullet point above is no longer applicable and can be ignored. Even if the images are unlinked later on a case by case basis, that's a job for a different module. Matt Fitzpatrick (talk) 01:42, 21 June 2016 (UTC)

Inaccessible small text in Template:Infobox single

See here for an ongoing discussion on the widespread usage of small font within {{Infobox single}}, resulting in WP:FONTSIZE issues. ~ Rob₁₃^Talk 20:43, 12 July 2016 (UTC)

Use of Flatlist and Hlist in infoboxes

A discussion regarding the use of {{Flatlist}} or {{Hlist}} in various music infoboxes is ongoing at Template talk:Infobox album#Harmonization with other music templates. Comments regarding their benefit are welcome. —Ojorojo (talk) 13:23, 2 August 2016 (UTC)

French talk page format

Following a discussion at Wikipedia talk:WikiProject Medicine #Color coding of talk pages, it was suggested that I should post the way that French Wikipedia formats its talk pages in case it might be of interest to anyone here. It will produce the same effect as for example, fr:Discussion Wikipédia:Accueil principal; you can scroll down that talk page to see if the lines and colours help to make the threading any clearer.

If you'd like to try it out, put the following into Special:MyPage/common.css:

.ns-talk .mw-body-content dl, .ns-talk .mw-body-content dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl dl dl dl dl dl {background:#f5faff;}

.ns-talk .mw-body-content dl dl, .ns-talk .mw-body-content dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl dl dl dl dl, .ns-talk .mw-body-content dl dl dl dl dl dl dl dl dl dl dl dl dl dl {background:white;}

.ns-talk .mw-body-content dl {border-top: solid 1px #a7d7f9; border-left: solid 1px #a7d7f9; padding-top:0.5em; padding-left:0.5em; margin-left:1em;}

Of course, you only have to remove the above to return your talk pages here to normal. HTH. --RexxS (talk) 01:07, 31 August 2016 (UTC)

@RexxS: That's a great improvement - thank you! Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 10:55, 31 August 2016 (UTC)

There was an error in the color specification there. I corrected the example. —TheDJ (talk • contribs) 10:59, 31 August 2016 (UTC)

Well spotted, TheDJ. Thank you. --RexxS (talk) 12:20, 31 August 2016 (UTC)

Can we get this into a gadget? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:47, 31 August 2016 (UTC)

Using math extension for simple symbols and chemical reactions

Hi! I came here from pl.wiki, as we neither have WikiProject related to accessibility issues nor even a help page. There is a small discussion about using math extension to write simple in-line symbols and chemical reactions. At this moment we're using {{chem}}/{{chem2}} for writing chemical reactions and don't have any guidelines regarding whether to use math or wikitext to write in-line symbols (like in this example taken from Concentration: "The mass concentration ${\displaystyle \rho _{i}}$ is defined as..." or "The mass concentration ρ_i is defined as..."). Are there any diffrences between these two options for people with disabilities? Are the symbols in math extension readable using screen readers or other software? Do you have any guidelines in en.wiki related to this problems? I would be very grateful if you could clarify these issues. Wostr (talk) 22:17, 7 September 2016 (UTC)

I don't think we have any guidelines on this issue, but yes, the symbols in the math tag are readable with screen readers. In fact, now that MathML is the default, they're very easy to use. Graham87 05:01, 8 September 2016 (UTC)

Thank you for answer. I didn't know that math tags are readable. Wostr (talk) 18:38, 16 September 2016 (UTC)

Color schemes for tables

Is there anybody here who is experienced at putting together attractive, contrasting color schemes for tables which meet the WP:ACCESSIBILITY criteria, and perhaps is willing to help out at Talk:Motion_picture_rating_system#Color_coding. It affects a family of four articles. Every few weeks somebody comes along and changes the scheme on a personal whim, usually reducing the contrast between the categories to enhance the aesthetic look. I concede it's not pretty to look at (I didn't select it) but I am concerned that reducing the contrast between categories could have implications for color blind people etc. I'm not that fussed about individual colors (there are a couple I would like to retain for intuitive reasons) and would like to put together an attractive, contrasting color scheme that poses no accessibility problems. If anybody is prepared to help us out then I'd be grateful. Betty Logan (talk) 08:51, 2 October 2016 (UTC)

Honestly? We should just put a blanket ban on using anything other than the styles provided in the core style sheets, with rare exception (perhaps especially for templates). --Izno (talk) 13:21, 2 October 2016 (UTC)

I have read the sections about tables and accessibility and cannot find much helpful advice, only Wikipedia:Manual_of_Style/Accessibility/Data_tables_tutorial#Color, which doesn't offer much guidance. If there is a standard pallette then could you link to the relevant page please? Betty Logan (talk) 19:42, 2 October 2016 (UTC)

There is some useful information at Category:Articles with images not understandable by color blind users - which is a daft place to put it... Basically, you can use black, white, yellow, and one from blue and purple, and one from Red, Green, Brown and Grey. If you're trying to cover the common color blindness conditions, then it is pretty much impossible to cover more than five categories with different colors alone. You need to either add something like cross-hatching or make distinctions in the label of the text.

There are a few (free) online tools available. VisCheck seems to be permanently down..., but Colorblind Web Page Filter seems to work well. You can enter a url in the box, select the color filter from the drop-down list, and press "Fetch and Filter! ...may take a minute" and wait for the results - it's actually quite quick. I had a quick look at the old and new versions mentioned at the motion pictures talk page and the results are scary!

I did some work quite a few years ago on colors for user interfaces (and also in manuals that might get printed in black and white). I'd like to help out. It would be useful to have a few palettes that could be used in tables and figures. Robevans123 (talk) 20:11, 3 October 2016 (UTC)

@Robevans123: Thanks for those links Rob. The color blind filter is especially illuminating. I had already sussed out there was a problem with the blue/purple and red/brown combos using a contrast checker, but it transpires from your links there is a problem with our green and red combos too. Another editor has joined the discussion at the article but doesn't seem to fully appreciate the accessibility aspects and is more concerned with making it look nice and we seem to be going in circles. I think maybe we need a fresh start at the discussion with this new information and if you wish to take an active role in helping design a new color scheme at the article you would be very welcome. I certainly think Wikipedia needs to provide more guidance/suggestions for color combinations and I think the comparison table would be a good test case. Betty Logan (talk) 10:30, 6 October 2016 (UTC)

I have proposed a new color scheme and started an RfC at Talk:Motion picture rating system#RfC: Should the comparison table in the article use a color scheme accessible to color-blind users?. If members of this project could spare a few minutes to share their observations on the accessibility aspects of the options it would be much appreciated. Thankyou for your assistance, especially Robevans123 who brought a potential solution to my attention. Betty Logan (talk) 05:41, 10 October 2016 (UTC)

Method of indenting comments in discussions under discussion

FYI, please see Wikipedia:Village pump (idea lab)/Archive 21#Use of colon ":" for indenting comments in discussions should be deprecated and the use of star "*" encouraged. --Redrose64 (talk) 22:50, 12 October 2016 (UTC)

Color contrast accessibility issue/discussion

See the edit history on Atlanta United FC, involving the use of colors failing to meet AA compliance. Members of this WikiProject may wish to be involved in the discussion that will be held on the article's talk page. ~ Rob₁₃^Talk 07:24, 17 October 2016 (UTC)

List gap help

@Graham87 and RexxS: I've been trying to explain to The Banner why list gap and bad coded nested lists are not good for accessibility. I given MOS, given examples linked on this talk page. I've given and explained code, but they refuse to read it. They only want... "Is there any outside research done in the matter?" Can somebody explain why list gap is bad and why nested lists that act like list gap is also bad. Bgwhite (talk) 06:41, 24 October 2016 (UTC)

And you act as if I am evil... but when something is good or bad, there should be some outside evidence to prove your point. The Banner talk 07:07, 24 October 2016 (UTC)

@Bgwhite and The Banner: Well, I've been removing line breaks to make proper HTML lists for a very long time indeed. (I think I started doing it even further back, once I got a version of my screen reader that made broken lists important, as far back as March 2007, but I can't remember what edit summaries I used then). Suffice it to say that if I, a screen reader user, have been trying to fix broken HTML lists consistently for the past eight or nine years, then it must mean that I believe they're very annoying and fixing them is very important for me. There wouldn't be much outside research on this problem because only wikis allow random people on the Internet to go in and create malformed HTML lists (whether nested or otherwise). However I do know of another blind person who has mentioned that broken HTML lists are problematic; I'll let him know about this discussion if you want another view on the matter. Graham87 08:32, 24 October 2016 (UTC)

@The Banner: Why should there be outside evidence of a problem caused by misuse of Wiki-markup? The problem is confined pretty much to Wikipedia, so why do you assume that outside sources will have examined it? I've been spending time explaining the problem to those who are prepared to listen for quite some time. See User talk:RexxS/Archive 19 #Threaded discussion for an example from 2012. If you're not interested in listening to those who have looked at the problem, then you can always install a screen reader on your computer and listen to how it sounds for yourself. What more "evidence" could you want? --RexxS (talk) 18:32, 24 October 2016 (UTC)

Further: having looked at Talk:List of state leaders in the 10th century, I can see that problem is a little more subtle. The argument is whether to use ** or :* to nest an item inside an unordered (bulleted) list, as in this markup:

* first item
** first sub-item
* second item
** second sub-item

compared with

* first item
:* first sub-item
* second item
:* second sub-item

The answer is simple: the first markup produces bulleted sub-lists within a single bulleted list; while the second markup produces four separate lists - two bulleted lists and two definition lists with a bulleted list inside each one. You can see that we give the advice to start each line with the same list markup at Help:List #Common mistakes. Although each markup looks the same to a sighted reader, a screen reader would read out four separate lists, which is not what was intended, nor is it desirable for the visually impaired as they hear the screen reader announce something like: Ordered list: two items ... each time a new list starts. To make it obvious, check what happens if we do the comparison using ordered lists instead. This is the resulting display:

first item
1. first sub-item
second item
1. second sub-item

compared with

first item

first sub-item

second item

second sub-item

In that case, it's also obvious to a sighted reader that mixing the list style as in the last example produces separate lists because the numbering is restarted. Hope that helps. --RexxS (talk) 19:20, 24 October 2016 (UTC)

List formatting RfC

FYI, Talk:Star Trek: Discovery#RfC on "Cast and character" formatting. --Redrose64 🌹 (talk) 21:07, 3 January 2017 (UTC)

Using the Wikidata interface with keyboard

Our colleagues at Wikidata are seeking comments from people who navigate using a keyboard more than a mouse. If that applies to you, and you have used Wikidata (as an editor or to look up factoids), please comment there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:26, 3 January 2017 (UTC)

Interview with Graham Pearce

In case you missed it, the Signpost has a great interview with Graham Pearce (Graham87), who is totally blind and uses JAWS to edit Wikipedia. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 23:46, 17 January 2017 (UTC)

@Pigsonthewing: Thanks for the note here ... I've fixed the link to the interview. Hope you don't mind. Graham87 02:35, 18 January 2017 (UTC)

Color description

Please see Talk:Deseret alphabet § Color sample description. It discusses an issue about using colored backgrounds to add information to table entries and possible ways to improve it.

Please {{Ping}} me to discuss. --Thnidu (talk) 06:36, 31 January 2017 (UTC)

Language tagging of Gaeilge terms widely used in English

I've just started a discussion at Wikipedia talk:WikiProject Ireland § Language tagging of Gaeilge terms widely used in English, as a result of a conversation at User talk:Bastun § Language tagging, about the use of {{lang|ga|...}} around terms originating from Irish Gaelic — such as An Post, Dáil, Taoiseach, Seanad Éireann, An Garda Síochána, gardaí — that are now routinely used in Irish English. — OwenBlacker (talk) 22:30, 2 April 2017 (UTC)

Abbreviations for exempli gratia, id est, etcetera

Hello, people of WikiProject Accessibility. There is a discussion at Wikipedia talk:Manual of Style#'e.g.', 'i.e.' and 'etc.' vs 'eg', 'ie' and 'etc' which may interest you. Only one person has mentioned screen reader software in that thread, but I think that it deserves more comment from those who actually use such aids. --Redrose64 🌹 (talk) 06:59, 17 April 2017 (UTC)

Expert opinions requested on accessibility of tennis performance timeline data tables

Hello, I am trying to implement a template to represent tennis player performance timelines. WikiProject Tennis has a guideline on how the current table should be formatted. However, I suspect that header rows in the tables in the guideline might not meet MOS:DTT criteria.

To address the potential accessibility problems, I made several adjustments in my implementation of the template, so the tables will be as shown in Template:Tennis performance timeline/Novak Djokovic, which I believe meet the criteria. One adjustment that appears irritating to some members of WikiProject Tennis is that I am including a tooltip explaining the abbreviation in every cell, without which I believe makes the table inaccessible.

So, I would like your expert opinions on whether the existing tables have accessibility issues, and whether a compromise can be made to reduce the use of tooltips in the new tables while maintaining accessibility. If you can chime in at Wikipedia talk:WikiProject Tennis#Template:Tennis performance timeline, and identify yourself as accessibility experts, I'll appreciate it. I'll also monitor this section. Thanks for your help. Chinissai (talk) 23:52, 29 April 2017 (UTC)

Single-cell headers spanning the full width of a table

There is a discussion at Talk:2017 World Rally Championship#Guidelines which is relevant to this WikiProject, because (amongst other things) it concerns the accessibility of an extra header row in a table, this extra row containing a single cell that spans all columns. --Redrose64 🌹 (talk) 13:58, 7 May 2017 (UTC)

Disability listed at Requested moves

A requested move discussion has been initiated for Disability to be moved to differbility. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 16:00, 9 May 2017 (UTC)

To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject.

Accessibility problem with Hanging indentation of refbegin

Hi, because the usage of : for indentation of references in {{refbegin}} is an accessibility problem, I'm proposing a new site wide class to fix the problem, so that we can go back to using unordered lists (*) for these types of usage. Feedback is welcome. —TheDJ (talk • contribs) 16:04, 9 May 2017 (UTC)

Disability listed at Requested moves

A requested move discussion has been initiated for Disability to be moved to handicap. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 22:44, 11 May 2017 (UTC)

To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject.

Popular pages report

We – Community Tech – are happy to announce that the Popular pages bot is back up-and-running (after a one year hiatus)! You're receiving this message because your WikiProject or task force is signed up to receive the popular pages report. Every month, Community Tech bot will post at Wikipedia:WikiProject Accessibility/Archive 6/Popular pages with a list of the most-viewed pages over the previous month that are within the scope of WikiProject Accessibility.

We've made some enhancements to the original report. Here's what's new:

The pageview data includes both desktop and mobile data.
The report will include a link to the pageviews tool for each article, to dig deeper into any surprises or anomalies.
The report will include the total pageviews for the entire project (including redirects).

We're grateful to Mr.Z-man for his original Mr.Z-bot, and we wish his bot a happy robot retirement. Just as before, we hope the popular pages reports will aid you in understanding the reach of WikiProject Accessibility, and what articles may be deserving of more attention. If you have any questions or concerns please contact us at m:User talk:Community Tech bot.

Warm regards, the Community Tech Team 17:15, 17 May 2017 (UTC)

Template:History of China

I'm no designer, so I don't know how best to handle it, but Template:History of China doesn't appear to be compliant with the guidelines respecting colour contrast. Would someone be able to take a look? Additionally, might it be worth creating a message box for use when non-article pages aren't compliant with MOS:COLOUR? 142.160.131.202 (talk) 02:35, 8 July 2017 (UTC)

Global Game Jam Accessibility Diversifiers

Please consider reviewing the (COI) edit request at Talk:Global Game Jam#Accessibility Diversifiers (Suggested_References) if anyone has time. jd22292 (Jalen D. Folf) (talk) 03:46, 11 July 2017 (UTC)

Need help adding citations and information

I am a person with disabilities, namely rheumatoid arthritis. I have days when my hands are problematic. Can someone help me add citations to an article so i can avoid what is becoming a really ongoing and unpleasant hassle?Janemcclure (talk) 13:47, 15 August 2017 (UTC)

@Janemcclure: Have you tried using the VisualEditor? It helps you make citations using forms rather than hand typing each thing into the edit screen. --Izno (talk) 14:11, 15 August 2017 (UTC)

Color tables

I have created tables of CSS colors by contrast-with-white ratio, currently at User:Mandruss/sandbox2. I conceived this as an aid to editors who customize their signatures with choosing colors compliant with the recommended minimum 4.5:1 contrast ratio specified at WP:SIGAPP. The tables would save significant time and effort and I think would increase compliance in custom sigs. As such I had planned to add the tables at Wikipedia:Signature tutorial. But I wonder if they would be better placed at WP:SIGAPP or WP:COLOR (probably collapsed), as a new page or subpage to be linked from various other applicable pages, or somewhere else. Any suggestions? ―Mandruss ☎ 21:28, 27 August 2017 (UTC)

COLOR or a subpage of COLOR seems best. --Izno (talk) 21:45, 27 August 2017 (UTC)

COLOR is not a page, so there can't be a subpage of it. Did you mean a subpage of Wikipedia:Manual of Style/Accessibility? ―Mandruss ☎ 21:49, 27 August 2017 (UTC)

Of course. --Izno (talk) 23:51, 27 August 2017 (UTC)

Wikipedia:Colour contrast nominated for deletion

Wikipedia:Colour contrast has been nominated for deletion. Please comment at Wikipedia:Miscellany for deletion/Wikipedia:Colour contrast. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:03, 29 August 2017 (UTC)

Withdrawn due to incoherent procedures. ―Mandruss ☎ 14:59, 29 August 2017 (UTC)

So incoherent that neither yourself nor Andy Mabbett closed it properly (this edit is only a small part of step 6 of WP:MFD/AI). I've finished the job. --Redrose64 🌹 (talk) 19:15, 29 August 2017 (UTC)

Not being adminstrators I guess it's forgivable that we didn't read a page titled "Administrator instructions". If I had read it, I don't know why I would have deduced that it applied to my actions. Incoherent. But thanks for the cleanup. ―Mandruss ☎ 20:12, 29 August 2017 (UTC)

Is there an accessibility issue here

Have a look at this version of Wikipedia talk:Talk page guidelines#Anchors (Version 3?). Search for the phrase "In a long discussion, it is hard work to follow the threads at the best of times". Now, without checking the page history, can you tell who wrote the paragraph that begins with that phrase? I haven't called "accessibility" yet, other than in the matter of WP:INDENTGAP elsewhere on the page. Please comment at the original talk page please, I don't want to be had up for WP:FORUMSHOP. --Redrose64 🌹 (talk) 07:39, 4 September 2017 (UTC)

@Redrose64: I'm in a really weird mental state due to jet lag right now, but I don't understand the last sentence of your message at all ... if you don't want to be done for forum shopping, wouldn't it be better if I avoided commenting on that thread? (Which seems to be a good idea for my sanity) ... but, FWIW, sometimes I'm OK with interleaving, but in the example you pointed out it got ridiculous ... I couldn't tell who made the comment you mentioned. Graham87 14:03, 4 September 2017 (UTC)

What I mean is that I wish to avoid discussion on two different pages. The original page is bad enough with its multiple subsections. If matters are discussed here, and then I go back to Wikipedia talk:Talk page guidelines and say "we have had a discussion at WT:WCAG, and the outcome was such-and-such", that would be a forum shopping breach. So I want to keep it all together. --Redrose64 🌹 (talk) 07:18, 5 September 2017 (UTC)

Aha, understood. I've added a brief comment over there with the gist of what I said here. Graham87 14:37, 5 September 2017 (UTC)

Thank you --Redrose64 🌹 (talk) 23:22, 5 September 2017 (UTC)

Accessibility versus convenience in indentation (RfC at VPPOL)

FYI

– Pointer to relevant discussion elsewhere.

Please see: Wikipedia:Village pump (policy)#RfC: Accessibility versus convenience in indentation
— Preceding unsigned comment added by SMcCandlish (talk • contribs) 13:39, 3 December 2017 (UTC)

Alternative text for images

I moved WP:Alternative text for images to WP:Manual of Style/Accessibility/Alternative text for images, where the rest of the MOS:ACCESS supplement pages are. All links and shortcuts to it work, it just now isn't lost in the vast sea of the "Wikipedia:" namespace, but is consolidated with the related material. Also fixed the old WP:ALTPDI and MOS:ALTPDI shortcuts to work (they'd lost their anchor point when the "Purely decorative images" heading went away). — SMcCandlish ☏ ¢ >^ʌⱷ҅_ᴥⱷ^ʌ< 23:54, 20 December 2017 (UTC)

Accessibility of Geological time footers

There is a discussion about the accessibility of certain page footers at Wikipedia talk:WikiProject Geology#Proposal to convert eon, era, and epoch boxes to navboxes. Please feel free to join in the discussion. —hike395 (talk) 05:52, 3 January 2018 (UTC)

Wikipedia red link on wikipedia standard navbox title violates WCAG 2.0

I have been testing various color combinations using the Snook color contrast tool. I discovered, to my surpise, that the standard red link color (#CC2200) on the standard navbox title color (#CCCCFF) violates the WCAG 2.0 color contrast guidelines for accessibility (for text below 18pt). See the output of the tool. In practice, this means that if a navbox does not have a talk page, then people with visual impairment won't be able to easily click on the "T" link.

What should we do about this? —hike395 (talk) 06:58, 3 January 2018 (UTC)

@Hike395: Honestly, there are hundreds of smaller issues like these. I personally don't think this one is a major problem, as the majority of people will never even be able to figure out what V T E even means to begin with (much bigger accessibility issue) and once you know what it does, then you'll be able to find and use it. Consider that WCAG rules like these are general rules for standard situations. You refer to a check for readability but this isn't really standard text you have to read, it's the consistent placement and form of the 'widget' which gives you more information than the text does. To me this is one of those issues, where I say yes, technically, it doesn't pass, but practically does it really make a difference ? —TheDJ (talk • contribs) 09:37, 3 January 2018 (UTC)

(edit conflict) There was an RfC in October 2015 which resulted in consensus that the colours should conform with the guidelines, though there was no follow-up to change the colours because the participants didn't like the lighter shades of purple. Unfortunately, the dark (header) shade of purple proposed in the 2015 RfC was already the darkest shade of purple possible under AAA, but either changing the purples to the darkest AA-compatible shades or adding a different background colour under the V · T · E links could work. Alternatively, we could create all of the talk pages. Jc86035 (talk) 09:49, 3 January 2018 (UTC)

There's already a guideline at WP:EXISTING which discourages redlinks inside of navboxes. We could extend it to encourage editors to start talk pages for new navboxes. —hike395 (talk) 10:08, 3 January 2018 (UTC)

Containing what? The word "Hello"? A transclusion of {{talk header}} - which would violate the template's own documentation? No, leave them red until there is something useful to put in a talk page, such as suggestions for better organisation of the navbox groups and lists. --Redrose64 🌹 (talk) 11:55, 3 January 2018 (UTC)

As most navboxes are related to a specific topic, most of them will fall within the scope of a particular WikiProject, so the relevant WikiProject banner would be appropriate. A banner for Wikipedia:WikiProject Navigation templates could be applied on any navbox. --RexxS (talk) 15:37, 3 January 2018 (UTC)

Layout on a mobile device

I attempted to start a conversation at Talk:The Laird o' Cockpen but was told to ask elsewhere. does anyone here have any ideas? Frietjes (talk) 15:03, 18 January 2018 (UTC)

Changing the max-width of the table from 1200em to 100em doesn't implement your intended "automatically switch to 1 column on a narrow screen"; it merely prevents the table from getting any wider than 1142px in Monobook skin. That's a different issue. You were right to try {{div col}} but setting |colwidth=34em doesn't do the expected job on a small screen - the horizontal scroll bars kick in on desktop view and mobile view seems to display a single column even on wider screen devices. Testing with the Ripple emulator gives better results, but I'm still not terribly keen on them on a 800x480px screen.

I'd suggest you make a sandbox copy and experiment on just a single issue until you get something that you're sure does the job you want on multiple skins and devices, and then try to get consensus for that on the talk page. Eric can be quite laconic, but he is certainly able to perceive the improvement you're trying to make. --RexxS (talk) 17:42, 18 January 2018 (UTC)

the problem is that my version does work on my mobile device, whereas the other version does not. I don't see scrollbars, and it does using 1 column instead of 2. this is why I am asking for other suggestions, since I cannot see any problem with my version. Frietjes (talk) 18:01, 18 January 2018 (UTC)

still waiting for more input at Talk:The Laird o' Cockpen. Frietjes (talk) 15:31, 27 January 2018 (UTC)

Short descriptions

FYI

Wikipedia talk:Manual of Style/Layout#Short descriptions. --Redrose64 🌹 (talk) 20:55, 17 February 2018 (UTC)

Discussion notice: Observe MOS:FONTSIZE in infobox templates

You may be interested in the proposal/discussion at Wikipedia:Village pump (proposals)#Observe MOS:FONTSIZE in infobox templates. ―Mandruss ☎ 00:13, 17 March 2018 (UTC)

Status of table summaries

What's the status of summaries for tables on Wikipedia? They are obsolete in HTML5.

Relevant documentation and discussion on Wikipedia:

Alternatives to the HTML table summary attribute

On the HTML table summary attribute generally

Recommendations? Daask (talk) 18:46, 7 April 2018 (UTC)

Cui bono? There is a lack of support in JAWS for the alternative techniques. All of the browsers I checked were still happy to render the summary attribute. So anyone using the most common screen reader will be worse off if we abandon the summary attribute purely because of the HTML5 specification says it's obsolete. In my humble opinion, it's too soon to change any of our current advice for Wikipedia, because there's no benefit right now. --RexxS (talk) 19:15, 7 April 2018 (UTC)

We should advise use of the caption (which I believe we already do) and remove advice regarding summary or indicate that it should be removed in lieu of a summary external to the template. We should present the information for every one, not just screen readers. --Izno (talk) 21:08, 7 April 2018 (UTC)

If we advise moving summary external to the table, then a user of JAWS who navigates to the table directly will not hear the summary (which is specifically designed to help them). We should present the summary information for everyone and not exclude the visually impaired. --RexxS (talk) 23:23, 7 April 2018 (UTC)

Please don't be an ass. If the summary is indeed important, it should be presented also to the visually sighted. Tucking or hiding it away in a table summary is frankly dumb. We have an alternative to make it obvious what is going on in the table from a high level concept (that's <caption>), and a well-constructed table (meaning table headers marked up as such, possibly with scope=col) for the most part will make it obvious the intent of the table. --Izno (talk) 23:25, 7 April 2018 (UTC)

@Izno: the principal purpose of the summary attribute is to describe the organisation and layout of a table to those who can't see it. Take a look at H73 and check this: "Note: In HTML5 the summary attribute is obsolete. Assistive technologies may or may not continue to support the attribute. Authors should consider alternatives and only use with caution." It's too soon. You should understand that you're advocating removing this accessibility aid from the very people for whom it was designed, in favour of giving it those who don't need it. Now who's the ass? --RexxS (talk) 23:54, 7 April 2018 (UTC)

Experts on the subject matter (review above links) seem to validate the direction of my comments, so I'm going to take "too soon" with the grain of salt it deserves. In the below search results, it is evident to me that either the tables which are using it don't need it (for being correctly structured data tables) or are misusing it to indicate information already available in the various screen readers. I am, in fact, advocating accessibility for everyone. If a table is indeed so complex as to need an actual summary attribute, than a sighted user will also need help to understand the use of the table, and so we should expose that information to users who also need it. I very much doubt that there are any such tables given the first few pages worth of scanning I did, but there's some empirical results to dig through below. --Izno (talk) 00:29, 8 April 2018 (UTC)

I don't think that http://www.davidmacd.com/test/details.html validates the direction of your comments at all. It's too soon because the major screen readers haven't caught up with the HTML5 spec yet, and the cost of upgrading JAWS will mean that it will be years before most users will have an HTML5-compatible version. Until that happens, the alternatives to 'summary' will not be available to most screen reader users. That situation is unacceptable for Wikipedia.

"If a table is indeed so complex as to need an actual summary attribute, than a sighted user will also need help to understand the use of the table, and so we should expose that information to users who also need it." That's patently untrue. The summary attribute is a useful aid for the visually impaired in a whole range of tables whose structure is obvious to any sighted person. There's a clear example at H73 that I'm sure you're aware of. Or are you going to tell me a sighted reader needs the structure explained there as well? Why do you think W3C created the summary attribute in such a way that it is not visible in the rendered text in the first place? --RexxS (talk) 02:10, 8 April 2018 (UTC)

For context, there are only on the order of a thousand uses of summary. --Izno (talk) 23:45, 7 April 2018 (UTC)

H:title at TfD

People may be interested in the TfD here, as it relates to a tooltip template and possible accessibility problems from the use of it. Galobtter (pingó mió) 08:14, 5 June 2018 (UTC)

Row spans in tables

I have been looking for guidance about rowspans in tables, and how they are interpreted by screen readers. I have noticed more and more articles in the areas I edit using them. When I started editing here at the start of the decade I recall them being frowned upon because of accessibility issues so I was wondering if there is a formal position? Here are two specific examples that I have come across recently:

UK_Championship#Winners (used to look like this)
James Bond#The Eon Productions films

I would definitely be interested in input from editors with screenreaders if these tables are ok or not. Betty Logan (talk) 18:35, 26 June 2018 (UTC)

There is apparently still some concern about rowspans/colspans and some readers, but I would guess the popular ones have implemented them correctly. More concerning and which can be confusing even if a reader implements it correctly are rowspans internal to a table where the rows continue "through" the rowspanned cell, e.g. below:

A	B	C
AA	BB	CC
DD	BB	EE

(There is an analogous problem with colspaned cells.)

--Izno (talk) 20:16, 26 June 2018 (UTC)

How does a screenreader actually process something like that? Would it read out the "BB" on the second row or omit it? Betty Logan (talk) 20:53, 26 June 2018 (UTC)

Yeah, row/colspans are generally fine these days. As for the table example, JAWS omits the "BB" but NVDA reads it (though table navigation in that cell gets really weird). Graham87 04:04, 27 June 2018 (UTC)

Right, so in your opinion would that table be acceptable as it is or do you think it would be better to get rid of the rowspanning in this case have a duplicate BB on the second row? If so, do you think the MOS should explicitly advise against rows and columns that "cut through" other rows and columns (i.e. resulting in cases where the rows and columns have discontinuities)? My query has basically arisen from a short discussion at Wikipedia_talk:WikiProject_Snooker#Result_tables_in_tournament_articles. Historically snooker results tables did not utilise rowspans but they have proliferated in the last couple of years and IMO it is a change for the worse. Apart from the potential screenreader issues, I actually find rowspanned tables more difficult to digest on small resolutions because you can scroll along and then the row effectively disappears. I think it would be useful if the MOS issued some guidance on what would be good and poor practice in such cases. Betty Logan (talk) 09:38, 27 June 2018 (UTC)

I think it'd be better to get rid of the rowspan in this case. Guidance in hhe Manual of Style would probably be a good idea. Graham87 14:24, 27 June 2018 (UTC)

I agree with Graham, repeating a cell a few times is little effort and does make it easier for navigation with modern screen readers (don't forget many have a "table mode" that allows moving up, down, left, right from a cell, rather than just linearly left-to-right, top-to-bottom). If you find that you would need to repeat a cell a large number of times, it's often a sign that you might want to redesign the table. Things have moved on since my essay at User:RexxS/Accessibility in 2010, but the considerations inherent are still much the same. --RexxS (talk) 20:59, 27 June 2018 (UTC)

I've bumped into a web article or two before that had a really nice guide to "taking a bad table and turning it into a good table" but of course that was several years ago... I think Wikipedia:Manual of Style/Accessibility/Data tables tutorial has quite a bit actually. --Izno (talk) 21:12, 27 June 2018 (UTC)

Indentgap

FYI

Regarding WP:INDENTGAP, see User talk:Redrose64#Blank lines in talk pages. In particular, please observe the comment by Jc3s5h (talk · contribs), who wrote "I am not prepared to accept this guideline at all". --Redrose64 🌹 (talk) 20:14, 3 July 2018 (UTC)

Offending infobox

I don't know if this is the right place, but can someone please help Template:Infobox aerial lift line? I posted on the talk page but I had to create one, and I don't know if the people who work on that page can even see what I am seeing which is black text on a dark gray box. That's the worst case of I've ever seen on WP. —Мандичка^YO 😜 21:55, 7 July 2018 (UTC)

Answered there. In short: I think that it's one for RexxS (talk · contribs). --Redrose64 🌹 (talk) 22:19, 7 July 2018 (UTC)

Looks better now. Thanks both. --RexxS (talk) 23:11, 7 July 2018 (UTC)

Accessibility guidelines are petty

that is, according to Adam37 (talk · contribs), see Template talk:Richmond station routemap#Text size. It's time we had some teeth to use against clear disrespect for agreed practices. Are there any escalating user warnings, akin to {{subst:uw-mos1}}, {{subst:uw-mos2}} etc. that may be sent direct to such people? --Redrose64 🌹 (talk) 20:14, 28 August 2018 (UTC)

I've altered the font size of the table in {{BSsplit}} and the "legend" text so that it complies with MOS:FONTSIZE. I'd recommend a manually crafted warning, rather than templating experienced editors (who should know better), followed by an ANI report if the warning doesn't have any effect. --RexxS (talk) 22:10, 28 August 2018 (UTC)

Accessibility map

I'm all for accessibility but the first time I see this map at compulsory voting I was confused. Should the upload by an user who made this be reverted? Hddty. (talk) 04:13, 29 August 2018 (UTC)

@Hddty.: Our guidance for accessibility of content includes the requirement that, as far as possible, information should not be made available solely through the use of images. Obviously we would then be excluding blind visitors from that information, and I'm guessing that is your concern. In the case of that map, it would be wrong to use it as the only means in the article of explaining which countries have compulsory/non-compulsory voting, etc. However, the article does present the same information as text in the Current use by countries section. That means we are not excluding anyone by that particular use of the image, although I can't guarantee that other uses of the map elsewhere won't breach our guidance. I'd tend to consider the map as a summary for the sighted visitor, thus providing something extra to the article without disadvantaging the visually impaired. Hope that makes sense. --RexxS (talk) 16:25, 29 August 2018 (UTC)

Table captions

I seem to recall knowing that data tables require captions when they are preceded by prose in a single section, rather than the table being in its own section. Can someone point me to this guideline please? I can't seem to find it. Thanks. -- Alex^TW 14:28, 25 September 2018 (UTC)

All data tables, regardless of preceding content, should generally have their own captions due to the need for accessibility. --Izno (talk) 14:55, 25 September 2018 (UTC)

(edit conflict)

That's something I've laid out as an argument in the past, but I don't think it's ever been documented as a guideline. If it's any help the argument goes like this:

Most users of screen readers have two important short-cuts to navigating around Wikipedia pages. They can call up a list of tables and identify them by caption, or they can call up a list of headings and identify them by their text. In ether case, they can jump directly to the desired table or heading. If the table is immediately below (or very close to) a heading that describes the table, then they can, just as easily, jump to the heading and then move to the table. In such a case, the table caption is effectively redundant

Phrasing that in terms that become relevant advice would mean that whenever a table is adequately described by a heading that is (almost) immediately above it, you can get away with not supplying a caption. Naturally, there's no harm in having a caption, even then, if you want. This is a compromise for sighted editors who complain that captions are unnecessarily repetitive of the heading.

A simple example would be a table of an actor's filmography that comes straight after a heading called "Filmography" (or with no more than a few intervening words). Leaving out a caption that said "Filmography" would cause little disadvantage. However, if there was a lengthy introductory paragraph between the heading and the table, then it is kinder to the screen reader user to supply the caption, as that allows them to skip the introduction (which they may have already heard on a previous visit to the page).

Deciding on where t draw the line between "a few words" and "a lengthy paragraph" is subject to editors' judgement, which is probably why this isn't hard-and-fast guidance. I should add that most of the help for tables is at Wikipedia:Manual of Style/Accessibility/Data tables tutorial for anyone interested in the wider issues.

Does that help with your query? --RexxS (talk) 14:59, 25 September 2018 (UTC)

Accessible color combinations for box headers

I would like to produce a set of standard box-header colour pairs for the portal project that are accessible to a good standard. Is there anyone here willing to help select a set of background/foreground colour pairs that we can offer for this purpose?

If so, list the pairs below.

Black or white foreground (text) will probably be most popular, but other colours are also OK. A fairly wide range of background colurs would be nice as this might encourage sticking to the accessible set. Cheers, · · · Peter (Southwood) ^(talk): 19:14, 1 July 2018 (UTC)

The standard you want to meet is WCAG AAA (because there's no good reason not to). You can check foreground/background combinations with Snook's Colour Contrast Check. Remember that linked text is blue, not black, so if you are going to have links, you also need to check whether the background is compliant when the foreground colour is #0645AD.

You might want to make a start by reviewing User:RexxS/AAAcolour for black text. Cheers --RexxS (talk) 23:46, 1 July 2018 (UTC)

I found where EvergreenFir did the work to expand my original table to cover most cases. It might be just what you're looking for: User:EvergreenFir/sandbox1. --RexxS (talk) 23:50, 1 July 2018 (UTC)

That looks like a very good start, RexxS. Thanks for the link. · · · Peter (Southwood) ^(talk): 20:07, 2 July 2018 (UTC)

Here are some background colours that should work with the blue colour of links (based on a table linked above). Note that making colours lighter can make it look like the hue is changing. So, for example, light chartreuse looks greener than light green. I'm trying to explain next to each colour what I think it looks like.

#FFE3E3 or #FFE3E2, a very light pink. It looks slightly purpler than it is.
#FFE6C3 or #FFE3C2, a very light salmon. Looks slightly redder than it is.
#F1F100 reminds me of the yellow part of the Swedish flag. Some shade of yellow.
#AEFF5C seems to be usable as a light green. Maybe tending a bit towards lime
#9FFF9F looks like a light shade of mint green to me. Bluer than it is.
#8DFFCA looks like a greenish azure. Or aquamarine.
#61FFFF is a somewhat light cyan.
#D2EDFF I'd call washed out blue. A bit greyish.
#E9E9FF feels even more greyish.
#F8E4FF looks like a very light shade of magenta
#FFDFFF same, but looks more saturated (less greyish) and darker.
#FFE1F2 looks similar to the previous one, just a tiny bit redder.
#E9E9E9 is light grey.

As a result of those perceived hue changes, I'd say rather than selecting a dark colour and make it lighter, people should look at the light colours and select one of them. Especially since some colours might seem inappropriate in some contexts due to things they're culturally associated with. Maybe these colours should be put on an additional column in the table. – Pretended leer {talk} 20:34, 17 October 2018 (UTC)

I wrote that before some colours were added to the cable, so much of this is not relevant. The part about the hue appearing to change is still relevant though. – Pretended leer {talk} 20:41, 17 October 2018 (UTC)

[I'm keeping this list because it describes what the colours look like to me. The actual list of colours isn't really necessary, since someone else computed a similar list before I posted this one] – Pretended leer {talk} 20:46, 17 October 2018 (UTC)

Discussion on naming policy and ambiguous titles

A discussion at Wikipedia talk:Article titles has raised the question of whether distinguishing otherwise similar titles with small visual/typographical differences, such as Red meat and Red Meat, is a problem for screen-reader users, and what useful disambiguation might entail in such cases. Input from those with experience using screen-reader software would be appreciated. Thank you. —Sangdeboeuf (talk) 22:36, 20 October 2018 (UTC)

Plus signs and other non-words

So I read that screen readers don't usually read non-words. So how should we deal with articles that rely on things like mathematical symbols? Replace them with images with alt texts? Put them in spans with WAI-ARIA labels? Make templates that do one of those things (there currently is template:dagger)? And if we make templates for that, what should we call them? It seems there's been a template:plus which was used for a different purpose and then it got deleted. And if we make a template that shows a plus sign but reads as "proton", we can't call it template:proton, since that's a navbox. So what should we do with non-words like these? – Pretended leer {talk} 18:18, 29 October 2018 (UTC)

Treat them on a case-by-case basis. As for the plus sign, it's always read by screen readers. I can't think of any punctuation marks that require different treatment at the moment. Graham87 03:48, 30 October 2018 (UTC)