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)
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)
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. ~ RobTalk01:09, 29 August 2015 (UTC)
Maybe consider excluding those which have no text on the background colour. They simply have a short bar of colour. All the best: RichFarmbrough, 01:44, 29 August 2015 (UTC).
WikiProject Accessibility/Archive 6
Date
First Sunday following 5 January
WikiProject Accessibility/Archive 6
Date
First Sunday following 5 January
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.)
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)
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 ?
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)
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.
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. ~ RobTalk00:40, 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.
"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 edits20: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. ~ RobTalk01: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)
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.
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. Graham8710:35, 10 October 2015 (UTC)
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)
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
@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. Graham8705:35, 13 February 2016 (UTC)
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. Graham8711:43, 19 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)
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.
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)
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? ~ RobTalk16:46, 31 May 2016 (UTC)
This is fine and one of the reasons you might validly use <br>. You could also use a <p>, 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 <br /> - 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 <p>...</p> 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)
@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)
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)
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.
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 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. Graham8705:01, 8 September 2016 (UTC)
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)
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)
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. ~ Rob13Talk07: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)
@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. Graham8708: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
first sub-item
second item
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)
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
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)
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.
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)
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)
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)
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. Graham8714: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)
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.
@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)
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)
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)
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:
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
EE
(There is an analogous problem with colspaned cells.)
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). Graham8704: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. Graham8714: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 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)
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)
@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. -- AlexTW14: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)
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.
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.
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.
#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'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. Graham8703:48, 30 October 2018 (UTC)
