Wikipedia talk:WikiProject Accessibility/Archive 5

Pau Gasol
Team information
No.	16
Team	Chicago Bulls
League	NBA
Position	Power forward / Center
Personal information
Born	July 6, 1980 (age 43); Barcelona, Spain
Nationality	Spanish
Listed height	7 ft 0 in (2.13 m)
Listed weight	250 lb (113 kg)
Career information
NBA draft	2001 / Round: 1 / Pick: 3rd overall
	Selected by the Atlanta Hawks
Pro career	1998–present
Career history
1998–2001	FC Barcelona (Spain)
2001–2008	Memphis Grizzlies
2008–2014	Los Angeles Lakers
2014–present	Chicago Bulls

Pau Gasol
No. 16 – Chicago Bulls
Position	Power forward / Center
League	NBA
Personal information
Born	July 6, 1980 (age 43); Barcelona, Spain
Nationality	Spanish
Listed height	7 ft 0 in (2.13 m)
Listed weight	250 lb (113 kg)
Career information
NBA draft	2001: 1st round, 3rd overall pick
	Selected by the Atlanta Hawks
Playing career	1998–present
Career history
1998–2001	FC Barcelona (Spain)
2001–2008	Memphis Grizzlies
2008–2014	Los Angeles Lakers
2014–present	Chicago Bulls

This is an archive of past discussions. 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

←

Accessibility with infoboxes

I was wondering if MOS:TABLE#ACCESS is applicable to infoboxes, being that they are implemented as tables. Specifically, in the infobox example for {{Infobox basketball biography}} below (left), the player's jersey number and current team are combined into a single header. The HTML for this ends up as one row entry with plain text encodes into the header; there is no data cell:

<tr> <th colspan="2" style="text-align:center;background-color:#C41E3A;color:#FFFFFF;">No. 16 – <a href="/wiki/Chicago_Bulls" title="Chicago Bulls">Chicago Bulls</a></th> </tr>

Is there any preference based on accessibility to break this up into two separate fields—one each for the number and current team—as in the modified right column example?

Examples for Pau Gasol article

Current {{Infobox basketball biography}}

Modified with indiv rows for No. and team

Thanks in advance.—Bagumba (talk) 07:18, 31 March 2015 (UTC)

@Pigsonthewing: Ping Andy. He's the expert on this. Bgwhite (talk) 07:36, 31 March 2015 (UTC)

The modified version has two advantages: (1) the blue colour makes it obvious that "Chicago Bulls" is a wikilink; (2) the former version could be mistaken for suggesting that Chicago Bulls is Team No. 16. —sroc 💬 07:37, 31 March 2015 (UTC)

I would put the team first, though, since the number is a sub-division of the team. For that matter, a more logical order would be: (1) league; (2) team; (3) number. —sroc 💬 07:41, 31 March 2015 (UTC)

Order is the easy part. The main question is the combining of data into a header.—Bagumba (talk) 07:43, 31 March 2015 (UTC)

The accessibility project has not yet tried to improve infobox accessibility. Thus, MOS:TABLE#ACCESS does NOT YET apply to infoboxes.

We should write specific guidelines about infoboxes since it's a very specific situation with big challenges. But the French Wikipedia has poured a lot of work into making accessible infobox trough the project fr:Projet:Infobox/V3. I have substituted the template in a sandbox so you can see the code easily and the result at fr:Utilisateur:Dodoïste/bac à sable perso.

Basically, the infobox has the following structure. The box is made with the DIV tag. The title of the infobox is made with a P tag. Then every sub-section of the infobox has a short table with the sub-header in a CAPTION tag. Data cell have ROW HEADERS.

Using this structure you can make an accessible infobox. But you need to rewrite the whole infobox template. Cheers, Dodoïste (talk) 14:25, 31 March 2015 (UTC)

Of course MOS:TABLE#ACCESS applies to infoboxes. They are tables, and MOS:TABLE#ACCESS makes no such exclusion. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:08, 31 March 2015 (UTC)

Well it should apply to infoboxes too. But currently it says nothing about infoboxes specifically. And infoboxes are a very special case, you cannot apply the same rules without a hefty lot of salt.

User:Pigsonthewing, what do you think of the proposal at fr:Utilisateur:Dodoïste/bac à sable perso ? Dodoïste (talk) 19:56, 31 March 2015 (UTC)

... for the title? Why? Subheaders are now captions, which is better, but I feel that it would probably be more worthwhile to experiment with definition lists. Alakzi (talk) 20:14, 31 March 2015 (UTC)

@Dodoïste: It sounds like there are potential opportunities to optimize the underlying generic {{infobox}} template implemention. As far as high level usage of {{infobox}}, is it advisable to break out key value pairs of data by using the "label" and "data" tag, as opposed to combining multiple pieces of data into a single "header"? The actual HTML encoding is left to the underlying {{infobox}}, which can independently change if needed.—Bagumba (talk) 20:32, 31 March 2015 (UTC)

It is certainly not advisable to use headers for data. Visually, headers are higher-order labels; semantically, they are labels which lack an accompanying data field. Alakzi (talk) 20:39, 31 March 2015 (UTC)

(←) As regards taking a look at using divs/definition lists, I'm pretty sure that's not the first time the topic has come up, but with the configurability of the current template:infobox/module:infobox, I think you'd be hard pressed to make a div/dl style infobox work. It certainly wasn't possible when all we had was wikicode and not the magic of Scribunto at our fingertips. --Izno (talk) 04:40, 1 April 2015 (UTC)

Fellow editors, please allow me share the perspective of a sports editor who actually uses these templates on a daily basis:

Currently, American football (~15,000), Canadian football (~7,200), all baseball (~21,300), and all basketball (~9,600) player infoboxes use a "Current Team Name – No. 22" format for the first section header of the player infoboxes.
Infobox basketball biography is the only athlete bio that still links the current team name in the first section header. Discussions are being mooted to remove the team link from the section header. Links in section headers are contrary to MOS:LINK, and hidden links also violate the basic principle that all links should be visually distinguished from the surrounding text and background color (if any).
The layout and design of these templates was created by sports editors as the best presentation of the typical data of a pro athlete in these sports, taking into account the semantics of sports biographies. This format is space efficient and eliminates the need for redundant presentation of data in the main body of these infoboxes -- the player's current team is already named and linked in the "career history" sections of these infoboxes.
These infoboxes have existed in more or less their current formats for over seven years -- without substantial complaints from anyone.
Most sports editors like the current presentation of data in these infoboxes as it is. Presenting current team name and roster number above the player's position and other similar player data has great semantic value, and it functions as a subheader for the player's name immediately above.
Contrary to several questions recently raised regarding accessibility of the "Current Team Name – Roster No." presentation in an infobox section header, an inquiry of an actual visually impaired editor and current administrator demonstrates that commercial screen reader software has absolutely no difficulty reading the section header as written whatsoever.
MOS:TABLE, by its own terms and examples, only applies to wiki-tables and graphs. Infoboxes formatting is governed by MOS:INFOBOX, which includes nothing on point.
In fact, WP:ACCESS has nothing specific to offer on point.

Unless one of the discussion participants can offer a valid reason based in the text of the current infobox guidelines, I would suggest that there is no reason why a small group of editors should presume to make any changes based on their own preferences in contravention of the long-term, stable consensuses that each of these infobox templates represents. Dirtlawyer1 (talk) 01:17, 1 April 2015 (UTC)

This is a discussion; we're not seeking to perform any changes "in contravention of the long-term, stable consensuses". It might be that we won't need to alter the layout of these infoboxes, but it won't be because nobody's thought to put the word "infobox" in a guideline, or because it so happens that nobody's complained until now. At this moment, we should be debating the benefits and disadvantages of what's being proposed here; should we come to a conclusion that the good outweighs the bad, we'll submit a proposal at the appropriate venue(s). Alakzi (talk) 01:34, 1 April 2015 (UTC)

@Dirtlawyer1: Feel free to invite the "visually impaired editor and current administrator" that you mentioned. As far as I know, administrators have equal standing with others as far as discussions, so not sure how mentioning that was relevant.—Bagumba (talk) 01:45, 1 April 2015 (UTC)

In fairness, Alakzi, I would suggest that this "discussion" needs to be properly noticed on each of the potentially affected template talk pages, and not presented as a fait accompli decision in "the appropriate venue(s)" after this discussion is concluded. As for the applicable guidelines, they are what they are, and it would be tough to say any decision taken here is based upon a particular guideline when that guideline says nothing on point. As for the actual accessibility issue mooted above, these "Current Team Name – No. X" infobox section headers present absolutely no problem for commercially available screen-reader software (please see [1]). We seem to be inventing a problem that does not exist -- and therefore one that does not need to be cured. Dirtlawyer1 (talk) 01:56, 1 April 2015 (UTC)

I think if there's any question re accessibility, it's not regarding unsighted users, but rather sighted users. The link in question is not obviously a link to my eyes, and there aren't many that would expect it if (unless you're a regular peruser/editor of sports articles I suppose). --Izno (talk) 04:40, 1 April 2015 (UTC)

@Izno: Please note my point no. 2 above. I agree the hidden link in the section header should be removed, but for the simple reason that it violates MOS:LINK as I described. Removing the hidden team link from the section header has already been suggested to User:Bagumba in a related discussion regarding another athlete infobox; oddly, Bagumba opposed removing the link from the section header, saying that the first occurrence of a word or phrase should always be linked (hint: that's not what MOS:LINK actually says). Please also note per my point no. 3 above that the current team is already linked in the "career history" section of the infobox. Putting a second team link in the first section is redundant. Dirtlawyer1 (talk) 05:19, 1 April 2015 (UTC)

oddly, Bagumba opposed removing the link: Odd is being quoted out of context. Here is an actual quote: "I don't understand the desire to add a linkable term to a header that isn't linked, when the term can be easily introduced and linked outside of header.—Bagumba (talk) 03:30, 27 March 2015 (UTC)"Here is the full discussion that DLawyer did not provide.—Bagumba (talk) 06:32, 1 April 2015 (UTC)

Bagumba, you're cherry-picking your own quotes. When you were told that hidden links in section header elements violated MOS:LINK, you responded: "AFAIK, it doesn't hurt to have a link that is not visible; it's just not obvious unless you are in the know about the convention. If the solution is to make the term unlinkable on its first usage, and make readers hunt for the team link further down, I'd say just leave the term linked as is. Those who are used to it, continue using it. Those who don't know about it, use the later (more obvious) linked instance that we would otherwise be forcing everyone to do." For the particular template then in discussion, the hidden team link in the section header has already been removed. As for Infobox basketball biography, the example template under discussion here, the simple solution is the same: remove the hidden team link in the first section header. Dirtlawyer1 (talk) 10:50, 1 April 2015 (UTC)

Another quote out of context. You omitted in red: "AFAIK, it doesn't hurt to have a link that is not visible; it's just not obvious unless you are in the know about the convention. If the solution is to make the term unlinkable on its first usage, and make readers hunt for the team link further down, I'd say just leave the term linked as is. Those who are used to it, continue using it. Those who don't know about it, use the later (more obvious) linked instance that we would otherwise be forcing everyone to do. I guess there is an option 5 now. So the purist in me !votes option 2—link the first instance of the team—otherwise, leave the linking as is.—Bagumba (talk) 05:18, 27 March 2015 (UTC)"—Bagumba (talk) 20:43, 1 April 2015 (UTC)

That's interesting: I've never expressed support for a linked header element, never suggested that a header element be linked, and have repeatedly pointed out that such a linked header element violated MOS:LINK, as I did above in my point no. 2. Dirtlawyer1 (talk) 10:30, 1 April 2015 (UTC)

And where did anyone say you did? Please provide a direct quote, preferably not out of context for a 3rd time.—Bagumba (talk) 20:43, 1 April 2015 (UTC)

current team is already linked in the "career history": You do realize that readers are either unnecessarily forced to hunt down for the second use of the term, or those using screen readers have to wait for all the text to be read before getting the second instance—they don't have the luxury to skim—Bagumba (talk) 07:01, 1 April 2015 (UTC)

Again, interesting: that's a layout and design choice, not an "accessibility" problem. The simple solution is removing the hidden link in the section header, as previously suggested, and there would be no need to be discuss the "accessibility" problem here, as layout and design issues should be discussed on the template talk page, not here. Dirtlawyer1 (talk) 10:30, 1 April 2015 (UTC)

DLawyer: For your point No. 1, you failed to note sports templates like {{Infobox football biography}}, {{Infobox cricketer}}, {{Infobox rugby biography}}, and {{Infobox ice hockey player}}, which do not list the team and number is a combined header. Feel free to supply those transclusion counts if you deem them important. Personally, I think it would be best to discuss the merits of the design options, and avoid mere WP:OTHERSTUFF statements.

I thought you brought this here to discuss an "accessibility" problem, not the "merits of design options," which rightly should be discussed on the template talk page. As User:Izno rightly points out above, the biggest "accessibility" problem is the hidden link in the section header which I have repeatedly said should be removed for the reasons stated above in my point no. 2. If that hidden link in the section header is removed, where is your "accessibility" problem that prompted this discussion? Dirtlawyer1 (talk) 10:30, 1 April 2015 (UTC)

There is still data in the header. See Alakzi's 20:39, 31 March comment above: "It is certainly not advisable to use headers for data."—Bagumba (talk) 20:43, 1 April 2015 (UTC)

Alakzi is entitled to his opinion, okay, but so what? There is still no identified "accessibility" problem here -- there is no specific suggestion in any existing guideline that using the unlinked team name in the first section header is an "accessibility" problem, including:

not Wikipedia:Manual of Style/Accessibility;

not Wikipedia:Manual of Style/Tables#Accessibility; and

not Wikipedia:Manual of Style/Infoboxes.

In contrast, using a hidden link for the team name in the section header violates at least two guidelines:

Wikipedia:Manual of Style/Linking: "Section headings should not themselves contain links", and

Wikipedia:Manual of Style/Accessibility#Color: "Articles that use color should keep accessibility in mind, as follows . . . Links should clearly be identifiable as a link to our readers."

As another editor succinctly said above, "if there's any question re accessibility, it's not regarding unsighted users, but rather sighted users. The link in question is not obviously a link to my eyes, and there aren't many that would expect it . . . (unless you're a regular peruser/editor of sports articles I suppose)."

Bottom line: including the unlinked team name in the section header violates no specified provision of any applicable guideline, including those listed above. Including a hidden link for the team name in a section header violates at least two very specific provisions of the applicable guidelines, including, ironically, the Manual of Style section on Accessibility.

What's the simple solution? Remove the hidden team link from the section header because it violates multiple identified guidelines, and move on. By keeping the hidden team link, which is a specific formatting violation, it seems you are trying to preserve the accessibility issue to force a different outcome. Sorry, but that's called "boot-strapping." Delete the hidden link in the section header, and there is no "accessibility" problem. Dirtlawyer1 (talk) 21:45, 1 April 2015 (UTC)

Ooookay... Now I understand why the subject was brought here. There was a previous conflict between editors about the link in the header and the color. Your current discussion has strictly nothing to do with accessibility. Infoboxes as a whole have a lot to improve in terms of accessibility. But I suspect you are only here to drag more people into your conflit about a link in the header.

My answer is simple:

Please observe Wikipedia:Manual of Style/Text formatting#Color : "Links should clearly be identifiable as a link to our readers."
1. If the link is white and the text is white, the link is not clearly identifiable. Links on Wikipedia are typically blue. So keep the links blue.
2. If you disagree on Wikipedia:Manual of Style/Text formatting#Color, please go debate there. You are not on the right page. Thank you.

On a side note : asking Graham87 to test accessibility is good. But keep in mind that he can only answer for himself. There are other people and other kind of disabilities out there, and to cover accessibility for everyone we have to follow a generic guideline. This is what this accessibility project is about. Dodoïste (talk) 22:18, 1 April 2015 (UTC)

@Dodoïste: My original question was whether two data points, number=16 and currentteam=Chicago Bulls, is accessible in a table as header, or should it be alternatively encoded as a header/data pair. The wikilink is a side issue which agreeably sidetracked the main question.—Bagumba (talk) 23:30, 1 April 2015 (UTC)

... But I suspect you are only here to drag more people into your conflit about a link in the header. That is a remarkable assumption of bad faith. Alakzi (talk) 00:18, 2 April 2015 (UTC)

@Bagumba: Thanks for refocusing the debate around the original question. :-) Having the data in the header or not makes no difference regarding accessibility. Because normal users and impaired users all have the same information. Only new users or readers (regardless of disability) unaccustomed to this infobox might not understand what the number means.

@Alakzi: : Yes. Nothing personal though. I saw a conflict in this discussion that seemed to go nowhere. And it had nothing to do with this project. So I tried to... (how do I say this ?) set boundaries ? Set remit ? It seems to have worked. I agree that this sentence was not necessary though. I apologize for violating the good faith rule. :-) Cheers, Dodoïste (talk) 09:58, 2 April 2015 (UTC)

New discussion: As there is no consensus that this is an access issue, I have started a new discussion at Wikipedia talk:WikiProject Basketball#Current team in Infobox basketball biography. Thanks for everyone's input.—Bagumba (talk) 07:57, 3 April 2015 (UTC)

Alt text and figures in infoboxes

I recently noticed that the alt text I'd added to an infobox (locomotive infobox on GWR 5700 Class) was displayed when my cursor is over the image, but when the cursor is over any other images in the main text (using File: and alt text) nothing is displayed. BTW I'm using the monobook skin, Firefox and Windows 8.1. I wondered if this is intentional functionality or just an inconsistency. I guess that having the alt text displayed could be quite irritating to a sighted reader, but it also struck me that it would be quite useful to have a display option for editors so that the alt text is displayed for all images. It would then be very easy to see if there was alt text defined and to check if it was appropriate. Robevans123 (talk) 16:48, 25 January 2015 (UTC)

There's a weird set of rules concerning inline images intended to provide some context to what image is displayed. The various options as of 2010 were documented at User:Colin/Alt. — Dispenser 18:26, 4 May 2015 (UTC)

Accessibility of Template:SCOTUS-termlist-entry

Please comment at Template talk:SCOTUS-termlist-entry#Accessibility. --Izno (talk) 17:34, 26 June 2015 (UTC)

Complex tables, accessibility, and Wikipedia

In brief: Complex tables cannot be manually marked up accessibly on Wikipedia, nor is it reasonable to expect them to be. Do we replace them, HTML-ize them, automate them, or accept them?

At length:

I'm questioning the use of complex tables on Wikipedia. By complex tables, I mean tables with two or more column-heading rows, two or more row headers, and/or any merging of cells in the first column or first row of the table. Such as the one that appears in WikiProject Accessibility Userboxes.

It is my perception that such tables cannot be properly marked up for accessibility on Wikipedia, and that even if they could be, they would be unmaintainable by all but an incredibly detail-oriented editor (I consider myself quite detail-oriented and this is too much for me) with huge amounts of time and patience.

I have seen advice in Wikipedia to use colgroup and rowgroup, but the description section of WCAG Technique for using the scope attribute to associate header cells and data cells in data tables says these tags only apply to simple tables.

For complex tables, WCAG prescribes using id and headers attributes to associate data cells with header cells in data tables. This leads to several issues on Wikipedia:

id attributes need to be unique on a page, not just within a table. Yet, Wikipedia allows editing sections of a page such that an editor would not be aware of id attributes elsewhere on the page.
Tables within templates need to generate unique ids, even if the template is used more than once on a given page or if multiple templates on the page have complex tables.
Some tables, including tables that are within templates, include table cells that are inserted by other templates. How are these inserted cells to be marked up with appropriate id and header attributes?
Wikicode does not currently appear to tolerate the header attributes on table cells.

Even if none of the above were true, who is going to keep track that all id attributes on a page are unique? Who is going to spend the time to create the dozens of header attributes in each and every data cell in a large table?

Example: Suppose table 1 has two column-heading rows and one row-heading column. In data cell row 3, column 2, the header attribute might read "t1r1c2 t1r2c2 t1r3c1" representing column headers starting in row 1 column 2 and row 2 column 2, as well as a row header in row 2 column 1. If that table has 100 data cells, we're talking 100 header attributes with a total of 300 ids specified in them.

Who is going to fix each table inadvertently de-accessiblized by an editor who is not familiar with accessibility techniques? How will we even know the table has been de-accessiblized without re-examining the code or listening to it on a screen reader?

It would be nice if generating accessible HTML from content marked as column and row headings happened automatically. Then we would only need to train editors to mark column headings properly, as well as which rows contain row headings.

Well, and dealing with editors who object to row headings getting the default heading formatting. Maybe we need a Wikicode to tell the Wiki software which columns contain row headers.

So what do we do about complex tables?

Convert them to simple tables wherever they occur. As an editor, I have had edits reverted when I do this.
Require complex tables to be marked up with accessible HTML rather than with Wikicode. Probably a non-starter.
Change Wiki software to detect complex tables and generate the appropriate accessible HTML without requiring know-how on the part of editors beyond correctly identifying heading rows and columns.
Accept that Wikipedia will never be accessible with regard to complex tables, but that complex tables are sufficiently useful that the community decides to use them anyway.

I feel like Sisyphus here. All it takes is persistent reverters to force the last option. And it can be awkward to convert some complex tables to simple ones. Ideas? Anyone here with Wiki software code smarts? — Preceding unsigned comment added by Thisisnotatest (talk • contribs) 09:39, 7 June 2015 (UTC)

The id and headers requirements for Wikipedia are insane simply due to already-voiced issues. Suggest ignoring them. (They might even be insane in the general/practical; no writer/publisher of content is going to go through that pain.)
Non-starter.
Good idea, but software runs into all the same issues as above, and additionally runs into the question of "is this a display-content or data table?", which can only be decided by a human.
This one, because no other option is feasible. --Izno (talk) 16:09, 7 June 2015 (UTC)

Display-content vs. data table would not be an issue provided editors don't use the header marker. That said, I imagine some editors would use the header marker to get header formatting on a title row.
Actually, there is an in-between one. Convert complex tables to simple ones where it is reasonable to do so, leaving only those tables that must be complex tables as complex tables. That said, people of good faith may disagree on what is reasonable. Thisisnotatest (talk) 20:39, 7 June 2015 (UTC)

I don't think you're going to get consensus on your 'in-between' option. The examples provided above at WP:Accessibility userboxes are not unreasonable to me in the slightest. And I'm fairly reasonable, of course. ;) --Izno (talk) 16:34, 8 June 2015 (UTC)

Hi Thisisnotatest. :-) I would like to see more examples of the "complex tables" you speak of. I know they exist and are hard to deal with. But I do not see the problem with WikiProject Accessibility Userboxes.

I do agree that the id/headers technique was designed to be used in stable websites, not collaborative websites where anyone can edit. It should not be used on Wikipedia, and that is the reason why it is not a technique mentioned in the Wikipedia accessibility guideline WP:ACCESS.

When faced with a complex table, I usually suggest to break them down into several smaller tables. First I suggest that to the editors, and I make the changes afterwards. If they refuse to change the tables I do not insist. It prevents me from wasting my energy.

I know it's a tiring, long, endless, impossible task. But it has to be done, slowly, patiently. Keep up the good work ! :-) Dodoïste (talk) 17:06, 20 June 2015 (UTC)

Here are a couple

Template:ISO_15924_script_codes_and_Unicode

Highway interchange templates (this one at least attempts to be accessible by making the entire mile marker column, the third column, headers), example New_Jersey_Turnpike#Exit_list — Preceding unsigned comment added by Thisisnotatest (talk • contribs) 08:22, 21 June 2015 (UTC)

Thanks Thisisnotatest for the examples. Well the first is a long table with a lot of data. But her structure is in itself fairly good. It only needs a few improvements. I would not call this table a complex table, it is only a big table.

For the Template:ISO_15924_script_codes_and_Unicode, I would suggest to combine your table caption with scope=col attributes on column headers. And I mean all column headers, which means that there are two rows of column headers. It solves all the accessibility problems and it keeps the table visually almost identical.

ISO 15924 script codes^[a]^[b] and Unicode^[c]^[d]
ISO 15924			Script in Unicode^[e]
Code	No.	Name	Alias^[f]	Direction	Version	Characters	Remark

However i agree that New_Jersey_Turnpike#Exit_list is a complex table because its structure is unfamiliar and difficult to improve. Mostly because it is difficult to find a good row header... Having the miles act as row header is the best option available but still not very good unfortunately. But we still have good column headers, so this table is still fairly good overall. Dodoïste (talk) 21:08, 21 June 2015 (UTC)

re 1: we need rational criteria when a "complex table" would need adjustments. So far, both examples (ISO and New Jersey) are complex (as in: composed) but do not require these additions. Check: I can tell unambiguously which column- and row-headers each cell has (New Jersy may be unclear, but that's an other topic).

Dodoïste, can you tell us more about scope=col? Could is solve this question?

To be clear, I oppose the changes to {{ISO_15924_script_codes_and_Unicode}} as proposed by Thisisnotatest in the sandbox. (and "It only needs a few improvements"? - related or separate issue?) -DePiep (talk) 21:29, 21 June 2015 (UTC)

(arbitrary break #1)

(edit conflict)

Letters
A	B
1	3
17	24

A "complex table" here is a table that has a shared colum and/or row. In wikitable notation, that is made by using like | colspan=2 or | rowspan=2.

What the OP says is that for page-to-speech applications, the reading programme must must be told for each cell to which columns it actually belongs (that is, in the example: somehow note in cell "1" that it is under ~~yellow~~Letters too).

Me response: first: strange that an read the page-application should enforce us to make such big edits, to comply with accessability.

Second, even worse: why can that program itself not see what you and I can see: that the yellow header applies to both sub-columns??? It is in there, deductable.

I don't get why W3C would require such application-help. Why can it not read what I see? -DePiep (talk) 21:17, 21 June 2015 (UTC)

DePiep : Sorry for replying so late, I don't participate on Wikipedia very often. But I try to keep track of some things...

Thanks for explaining, now I see what is troubling you. There are no more accessibility concerns with the use of | colspan=2 or | rowspan=2 anymore. Modern screen readers like JAWS (screen reader) understand tables that use rowspan or colspan.

scope=col defines column headers that applies to the cells underneath.

So in your example for this small table, it would be accessible like this :

{| class=wikitable
! scope=col colspan=2 style="background:yellow" | Letters
|-
! scope=col | A
! scope=col | B
|-
| 1 || 3
|-
| 17 || 24
|}

Letters
A	B
1	3
17	24

Cheers, Dodoïste (talk) 21:51, 27 June 2015 (UTC)

Not sure yet. Does ! scope=col | satisfy the w3c requirement (OP)? -DePiep (talk) 21:39, 30 June 2015 (UTC)

Well I'm not sure either, frankly. So let's discuss this further and find more evidence.

I found this helpful reference, a tutorial from the W3C on irregular (complex) tables. Using the scope attribute. http://www.w3.org/WAI/tutorials/tables/irregular/

Basically, we should use scope=colgroup. I don't remember if it works on Wikipedia, has it been implemented ? Dodoïste (talk) 21:50, 30 June 2015 (UTC)

Actually, I remember removing "scope="'s because I didn't know what they are about (still don't). Since this really affects WP:table and WP:ACCESS stuff, it should be higher up, wm even?. OP Thisisnotatest points to a serious W3C diff issue. -DePiep (talk) 22:08, 30 June 2015 (UTC)

To be clear: I will keep using like plain !colspan=2 | until some WP:ACCESS and WP:TABLE says there is a WP:MOS change. -DePiep (talk) 22:23, 30 June 2015 (UTC)

The use of scopes on a header can indicate whether that header is meant to be a row header or a column header. This is most important where there are both rows and column headers but is good practice to use in general. For example, to software reading a table, the below table is ambiguous (even though you and I may understand):

Person	Deathdate
Izno	Not yet

The software would say that the person, deathdate, and Izno are all headers, that the person and deathdate headers occur in the first row and the Izno header in the second row, but would not be able to tell you whether the Person header is describing the row which it is in or whether it is describing the column which it is in (in case it's not obvious, it's the column it's in). So from this perspective, the following table is more useful to software, because I am using the scope attribute to tell the software that the Person header is about the column it is in:

Person	Deathdate
Izno	Not yet

--Izno (talk) 22:24, 30 June 2015 (UTC)

The use of the scope attribute does not remove or relieve us of the guidance to reduce the number of complex tables we have (see my earlier opinion which is basically "good luck asking editors to conform to the recommendations suggested"). --Izno (talk) 22:24, 30 June 2015 (UTC)

This is W3C-vs-enWP stuff. So must be discussed somewhere else then. I don't feel the urge to change templates. -DePiep (talk) 22:53, 30 June 2015 (UTC)

User:DePiep, have you read Wikipedia:Manual of Style/Accessibility/Data tables tutorial ? This page is part of the MOS, and is mentioned in WP:ACCESS. I wrote this tutorial five years ago when I was very active on this project. The need to simplify the tables is supposed to be understood and agreed on. And the ! scope=col | has already been heavily used on several projects.

What we need to discuss is the very specific way to simplify some tables. Can we allow more than one column header per column ? Can we use some specific code like scope=colgroup ? User:RexxS I need your help here ! :-) Dodoïste (talk) 21:28, 2 July 2015 (UTC)

Did not read that yet, glanced it. I am willing to learn more, much more, about |scope=. However, this OP thread starts with "you must add info per cell" (my words), even invoking W3C (ie, not just a WP:MOS). So far, I am not convinced to change wiki-tables for this OP claim (and remember it is about the page-into-speech application only). In my opinion the "|scope=" topic deserves a different thread (into WP:TABLE help even). -DePiep (talk) 21:43, 2 July 2015 (UTC)

Wikimarkup is not html, and it is "sanitised" by a parser as it is translated into html. One of the results is that colgroup is not implemented, and another is that it is effectively impossible to use ids in order to associate headers with data cells, so H43 is a non-starter on Wikipedia. However, using scope (per H63) can still help with the task of associating headers with data cells. If you're not sure why we want to do that, look inside:

How screen readers navigate tables

Screen readers such as JAWS or NVDA can not only navigate tables left-to-right and row-by-row (i.e. sequentially), but also may be set to navigate from cell-to-adjacent cell in any direction (up, down, left, right). This is useful for a user who wants to read down a column of data in a table. In order to help the user identify where they are in the table, it is possible in many screen readers to enable announcement of the column header and row header for that cell before reading the contents of the cell. Here's a snippet of Anthony Hopkins' filmography as an example:

Title	Year	Role
The White Bus	1967	Brechtian
The Lion in Winter	1968	Richard I
The Looking Glass War	1969	John Avery

A user may want to hear the roles that Hopkins played, so a screen reader could navigate down the 'Role' column and read out "Brechtian", "Richard I", "John Avery". But that doesn't give the relation to the film that a sighted reader could ascertain quite easily. The screen reader user doesn't want to have to keep navigating two cells to the left and then back again just to pick up the title of the film. Instead, a screen reader could be set to travel down the 'Role' column, but read out "The White Bus", "Role", "Brechtian"; then "The Lion in Winter", "Role", "Richard I", and so on (see HTML Tables with JAWS and MAGic for details of how it's done with JAWS). That's a much more useful experience, but it's only possible if the screen reader can associate a column header and a row header with each data cell. We can make sure that the widest possible range of screen reading software can find the best column and row headers by marking them up as headers ('!' in wikimarkup which is <th>...</th> in html) and making explicit their scope as "row" or "col". The snippet of Anthony Hopkins' filmography would be marked up as:

Title	Year	Role
The White Bus	1967	Brechtian
The Lion in Winter	1968	Richard I
The Looking Glass War	1969	John Avery

Because some editors don't like having row headers bold and centred, we created a class for the table to render them plain again:

Title	Year	Role
The White Bus	1967	Brechtian
The Lion in Winter	1968	Richard I
The Looking Glass War	1969	John Avery

In any table, a screen reader might be able to guess that the cell at the top of the column is the column header it wants and the cell at the start of the row is the row header. However, that may not always be the case - see Madonna videography for an example where the year is at the start of each row and the title of the video (a much better candidate) is the second item in each row. Nevertheless, in each row, the title is marked up as a row header and with a scope of "row". That ensures that as many screen readers as possible are able to navigate down (or up) the 'Director' column while still hearing the title of the video before the name of the director. Sadly they will not get the information that Mary Lambert directed "Material Girl" (because of the rowspan), but that's the penalty the visually impaired pay for our editors not wanting to repeat the directors name in vertically adjacent cells.

Does that help explain why marking up headers and scopes, as well as simplifying tables (e.g. by cutting down on rowspans) is done to try to improve the experience of screen reader users on Wikipedia? --RexxS (talk) 00:49, 3 July 2015 (UTC)

What do you propose then? How does that answer the OP? -DePiep (talk) 00:58, 3 July 2015 (UTC)

I would suggest that we accept them and mark them up as far as possible, but attempt (wherever we can) to educate editors about the advantages that simplifying tables would have for the visually impaired. --RexxS (talk) 17:03, 3 July 2015 (UTC)

That's what I would suggest as well. Not everything has to be perfect. Users with impairments are used to running into these kinds of problems all over the place. Wikipedia will never be perfect in this regard, because we cannot turn every single editor into an accessibility expert, and that is simply the only way we can ever fix this. At the same time it's also not fair to impair other users in their creativity and authorship. Yes it's better if tables are marked up properly, but it's not the end of the world if they are not. And yes super complex structures for no good reason should be simplified, but i would say that goes equally as much for non impaired users. Just as writing over complex prose is a bad idea. Don't try to force everything into rules, the real world is more important than the rules. For instance we output 'invalid' HTML these days on the website, but we do so for a reason. We know WHY we do it, and we know that all browsers support it and that it gives us a better website in the real world. The rules simply don't account for every possible situation. —TheDJ (talk • contribs) 08:04, 14 July 2015 (UTC)

My thoughts exactly. Graham87 11:49, 14 July 2015 (UTC)

Copyright Violation Detection - EranBot Project

A new copy-paste detection bot is now in general use on English Wikipedia. Come check it out at the EranBot reporting page. This bot utilizes the Turnitin software (ithenticate), unlike User:CorenSearchBot that relies on a web search API from Yahoo. It checks individual edits rather than just new articles. Please take 15 seconds to visit the EranBot reporting page and check a few of the flagged concerns. Comments welcome regarding potential improvements. These possible copyright violations can be searched by WikiProject categories. Use "control-f" to jump to your area of interest (if such a copyvio is present).--Lucas559 (talk) 19:31, 2 July 2015 (UTC)

How does that relate to accessibility? — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:10, 13 July 2015 (UTC)

It doesn't; that message was posted to the talk page of every WikiProject as far as I can tell. Graham87 11:49, 14 July 2015 (UTC)

Multiple tables of contents

It's come to my attention that the article Legality of cannabis by U.S. jurisdiction has two tables of contents (TOC). The first TOC is a manually-constructed table consisting of one column, one header row and one data row; the single data cell contains a bulleted list of links to major section headings. The second TOC is in the form of a {{horizontal TOC}} template. There is nothing between them, and nothing of importance (only a {{clear}} template) between the second one and the first section heading. Is this article alright for accessibility? --Redrose64 (talk) 14:48, 18 July 2015 (UTC)

It's alright, I guess. My instinct after coming across the first table of contents would be to hit "h" to go to the next heading, which would land me at the second TOC, which might be a little confusing, but I wouldn't lose any information that a sighted reader would have. Graham87 15:40, 18 July 2015 (UTC)

Expert review needed

Any actual Web accessibility professionals around? Wikipedia:Manual of Style/Accessibility/Data tables tutorial has not been reviewed in almost 5 years, and has a recent new section on table summaries. I'm arguably competent to do such a review myself, but I'm the one who added the new material, so that would be a conflict of interest. :-) — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 20:09, 13 July 2015 (UTC)

SMcCandlish ☺ : There isn't any Web accessibility professionals around here, sadly. But we could contact WebAIM and ask them for their opinion if needed. Here is my opinion on your changes :

I really liked your explanation of A, AA and AAA criteria. :-)
plainrowheaders :
"Used by itself, plainrowheaders will make headers look just like normal cells, and this is usually not desirable;"
Yes.

"use style="CSS declarations here;" on the row headers to add a custom style."
This is the part I did not understand, because I don't know in which specific case it would be needed.

"The plainrowheaders class is mostly used outside of mainspace."
Yes.
Table captions : I believe a solution for collapsible tables has not yet been found. The solution would be to change the collapsible table template and to rewrite the Javascript associated.
Table summaries : It is an important accessibility requirement. When I wrote this tutorial I left it out on purpose, only mentioning in the internal subpage : Wikipedia:Manual of Style/Accessibility/Data tables tutorial/Internal guidelines#Providing a summary. I expected the difficulty would be too high for editors. We still have a lot of difficulties with alt text, and a table summary seems much more difficult to write on my opinion. I believe this change needs to be discussed before being introduced.

Dodoïste (talk) 11:44, 18 July 2015 (UTC)

@Dodoïste: Regarding WebAIM, that would be helpful.

A–AAA: I'm glad. It took quite a while, because it's frankly confusing, and the changes from 1.0 to 2.0 made it even more so.
'Example text' – Because headers that look like normal cells is not desirable, if you use plainrowheaders to wipe the default style, you actually need to replace it with something else that distinguishes header from cell content. I'll try to clarify the wording.
Rats. Do we know who's "in charge" of that code, or was? Seems like the issue has been IDed for a very long time.
I have to suggest that the way past the fact that people don't know what to put in summary is to tell them what to put in it. :-) My first take on how to do that might not be perfect, but I submit that it is substantial progress. "Some editors might do it wrong" is true of everything on WP. We were offering no advice at all, ensuring that it probably would be done wrong. I have no objection to modifying that section to be less gung-ho about it, but I don't see a rationale for omitting all advice. Things will never get better if we don't have advice on how to do it. MOS is just advice, it's not a policy. We could even state that it's better to not use summary than to use it poorly. Anyway, it's already been introduced. The question is whether a) anything in it is wrong and needs to be reverted, B) something in it is unclear and needs to be written better; C) the priority/difficulty and whether we directly recommend editors do it should be adjusted (as just suggested, and perhaps with a recommendation that accessibility-experienced editors be consulted when in doubt), or D) it's good enough to run with until it proves necessary to alter it. I suspect some C and perhaps B tweaks lead straight to D with little effort, and we should get there ASAP, since as you say "It is an important accessibility requirement." Its absence would be likely to inspire the removal of even very well-constructed summaries by editors who thought that it not being covered by the guideline indicated that summaries are not desired or supported by WP. I don't see a point in revert-pending-more-discussion unless A is clearly true. WP's community faith in WP:BRD has been shot full of holes lately at WP:VPPOL for good reason.

I had no idea the Wikipedia:Manual of Style/Accessibility/Data tables tutorial/Internal guidelines page even existed, or would have tried to integrate more of it. Five years is too long for no progress to be made in pushing a bit closer to higher compliance levels, and instructing editors how to help. We do surely still have alt problems, but we'll always have problems since anyone in the world can edit. I don't see a way around that other than by stating what the best practices are as editor education, and improving implementation as we go, which probably means moving more of the /Internal_guidelines page (which is misnamed) into the actual guideline, even if we observe the results with caution. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 15:24, 18 July 2015 (UTC)

PS: I added {{under discussion inline}} to that section, and posted a pointer to this discussion on its talk page and at WT:ACCESS. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 15:45, 18 July 2015 (UTC)

I made a living for ten years or so before I retired incorporating accessibility into clients' web sites, but I'm no longer a professional. So what? Credentials mean SFA here. Table summaries have one principal function: to inform screen readers how the data in a table is organised. That allows the user to set a suitable mode for reading the table and helps them contextualise the data read in each cell. If the table is small and simple, then a summary doesn't help much because the user will quickly grasp how the data is organised with being told. It reduces annoyance value to such users by omitting the summary and we ought to say that. Otherwise we should give good examples: perhaps a table with a lot of column headers; and perhaps a complex table where there are sub-headers that could be explained in the summary. Frankly I don't think that summaries that analyse data are helpful to editors because we'll end up with them thinking they need to make analyses in summaries, rather than describing the table organisation.

Let's try to remove the confusion about the plainrowheaders class. They don't apply to column headers because they only apply to cells marked up as table header with a scope of "row". They actually don't make row header cells look "just like" normal data cells: they explicitly set left-alignment and normal font-weight, but don't change the cell background. In an otherwise unmodifed wikitable, the difference in background is subtle, but clear. The reason why plainrowheaders was introduced was because there was considerable resistance from WikiProjects to marking up row headers as headers, because it changed how they were accustomed to seeing the table. In order to encourage editors to adopt markup that improves accessibility for screen readers, it was necessary to allow a simple means of retaining existing table visual formats while marking up row headers. So I don't agree that plainrowheaders are undesirable (by whom? and why?). Nor do I agree that they are mainly used outside of mainspace. Their only value is in meeting editors' concerns about the visual presentation of tables in mainspace. I'll update Wikipedia:Manual of Style/Accessibility/Data tables tutorial #Layout of table headers as a narrative, rather than making value judgements about appropriateness. --RexxS (talk) 17:16, 18 July 2015 (UTC)

Signature tutorial

I have proposed that we make changes to the examples presented in our tutorial on sig design, to encourage more accessibility. Please comment and assist at Wikipedia talk:Signature tutorial#Accessibility. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 19:10, 27 July 2015 (UTC)

Alt text on images for screen readers

Would adding alt text to images so they can be accessed by screen readers be part of this project or part of Wikipedia:WikiProject Writing Captions? EvergreenFir (talk) Please {{re}} 22:27, 24 July 2015 (UTC)

Accessibility - see the WikiProject banner at the top of WT:ALT. --Redrose64 (talk) 23:17, 24 July 2015 (UTC)

Awesome. Thanks. Hopefully we can get an edit-a-thon or something one day to help with this. Woefully neglected area. EvergreenFir (talk) Please {{re}} 23:30, 24 July 2015 (UTC)

An editathon would be great, but in the meantime, one simple thing we can do is to encourage nominators of Featured Article candidates to add alt text. We shouldn't insist, because reviewers will remember the problems FA had with alt text a few years ago. Nevertheless, if it becomes the norm for Featured Articles to have good quality alt text, then we have an excellent model that other editors will mimic. My experience with raising the profile of accessibility at the Featured List process suggests that over time, compliance with accessibility guidelines can become an expectation for all nominations. --RexxS (talk) 08:55, 26 July 2015 (UTC)

Is the underlined text a loophole at WP:ACCIM: "Images should include an alt attribute, even an empty one, that acts as a substitute for the image for blind readers, search-spiders, and other non-visual users."—Bagumba (talk) 09:17, 26 July 2015 (UTC)

An image with a blank alt attribute is understood to be purely decorative and is ignored by screen readers. alt should not be left empty unless that is the intended effect. Alakzi (talk) 10:16, 26 July 2015 (UTC)

I've reworded it, for clarity. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:47, 26 July 2015 (UTC)

This reminded me that the MediaWiki software doesn't always do what you might expect, especially if you're used to writing html. I've made a page at User:RexxS/AltText that some might find useful - particularly in interpreting what is meant by "an empty alt atribute". --RexxS (talk) 18:08, 27 July 2015 (UTC)

Great research; worth raising a Phabriator bug. Would you like to do so? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 18:24, 27 July 2015 (UTC)

I don't think that <img alt> is the same as <img alt=""> - is it? Alakzi (talk) 18:30, 27 July 2015 (UTC)

~~I'm not seeing any alt text when I mouse-over the images. I'm using Firefox 39.0 for what it's worth. EvergreenFir (talk) Please {{re}} 18:56, 27 July 2015 (UTC)~~ Apparently it hasn't done that for years... sigh. I'm so behind the times. EvergreenFir (talk) Please {{re}} 18:59, 27 July 2015 (UTC)

@EvergreenFir: Mouseover text (or "tooltip") normally comes from the title= attribute, not the alt= attribute. You should see a tooltip if you hover over the image where Alt is omitted, but caption is specified. --Redrose64 (talk) 22:27, 27 July 2015 (UTC)

@Alakzi: I've tried creating a web page with one image using <img alt> and another using <img alt=""> in html. I've been unable to find a browser that distinguishes between the two. As you know, there is a very real difference between those in wikitext, as a naked |alt is treated as the caption and so the alt text is set to "alt".

@EvergreenFir: For Wikipedia pages, enabling "Navigation popups" in your Preferences (Gadgets tab, Browsing) gives a lot more information than just a tooltip, including telling you what the alt text is for any image. I'd recommend it. --RexxS (talk) 00:26, 28 July 2015 (UTC)

Abbr

Please note a discussion which may affect {{Abbr}} and {{Discreet abbreviation}}, at Wikipedia:Templates for discussion/Log/2015 July 28#Template:Discreet abbreviation. You contributions will be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:56, 28 July 2015 (UTC)

New category tracks infoboxes that fail COLOR

New category to work on: [2] EvergreenFir (talk) Please {{re}} 22:37, 24 July 2015 (UTC)

There's a discussion at Template_talk:Infobox_television_season#Questions_to_move_color-contrast_issues_forward_to_resolution to reach consensus on how to handle these.—Bagumba (talk) 06:03, 25 July 2015 (UTC)

If it's any help, I've prepared a table of 12 colours at 30° hue intervals and the darkest shade of those hues that meets WCAG AAA standards when used with normal black text of less than 18px font size. See User:RexxS/AAAcolour - any observations welcome. --RexxS (talk) 02:15, 27 July 2015 (UTC)

@RexxS: Just out of curiosity, did you use the WCAG formula to figure those out, or just play with the sliders on the contract website? EvergreenFir (talk) Please {{re}} 18:58, 27 July 2015 (UTC)

@EvergreenFir: There's a link to the tool used, on the page itself. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 21:30, 27 July 2015 (UTC)

@Pigsonthewing: Yes, thank you. Wondering though if there was a way to start at the contrast level and work your way back, or if you just play around with the sliders until you get AAA compliance. (Basically wondering if this is an exact process, or just best guesses). EvergreenFir (talk) Please {{re}} 21:35, 27 July 2015 (UTC)

Using Snook's Colour Contrast, I start with the base colour using HSL (with S and L at 100%). If the hue is already compliant (e.g. yellow or cyan), then I reduce the lightness (the slider once selected allows the left & right keyboard arrows for fine tuning) until it is just compliant in all parts. That has to be the darkest compliant shade of that hue. On the other hand, if the base colour isn't compliant, then the saturation has to be reduced until compliance is just achieved, producing the darkest shade of that hue that meets all the requirements. It's quite a quick process and easily reproducible for any base colour characterised by 100% saturation and lightness. Hope that helps. --RexxS (talk) 00:00, 28 July 2015 (UTC)

Snook seems to have modified the tool. It used to be that if you dragged any slider in either direction you would see the results in the last column changing, so you could determine the exact point where the AA/AAA boundary lay for a given characteristic. It now only updates those figures when you let go the mouse button. Another difference is that every different colour value permutation that you try gets entered into your browser page history, so you end up having to use the "back" button a great many times. On the plus side, the URL now accepts starting colour values (like this), which it didn't do before. --Redrose64 (talk) 07:30, 28 July 2015 (UTC)

I thought that the mouse behaviour had changed. Well, that's why I suggest using the left/right arrow keys to make the fine adjustments. Anyway, in my humble opinion, it doesn't matter much if we end up recommending a background colour that has a Colour Difference of 502 when we could have got away with a Colour Difference of 500. Life's too short. --RexxS (talk) 17:24, 28 July 2015 (UTC)

Thank you for the clarification! That does indeed help! EvergreenFir (talk) Please {{re}} 18:23, 28 July 2015 (UTC)

Right: this is one of those "varies by browser" situations, big time. In descending order of usefulness we have - Opera: using either mouse or arrow keys, the figures update as the sliders move - this is how it used to be for other browsers. Safari: using mouse, the figures update as the sliders move; arrow keys do nothing. Chrome: using arrow keys, the figures update as the sliders move; using mouse, the figures update only when you release the button. Firefox: using arrow keys, the figures update only when you tab to another slider; using mouse, the figures update only when you release the button. IE8: no sliders, no input for hex values, no use at all. --Redrose64 (talk) 20:24, 28 July 2015 (UTC)

Minor accessibility point discussion

I've made an accessibility argument (with regard to partially-visually-impaired users of GUI browsers with large font sizes), at MediaWiki talk:Common.css#Compensate for italic lean. Someone expressed skepticism about this, so it's probably best if some accessibility specialists have a look at it; it's possible I'm arguing for a distinction that doesn't need to be drawn. — SMcCandlish ☺ ☏ ¢ ≽^ʌⱷ҅_ᴥⱷ^ʌ≼ 22:31, 29 July 2015 (UTC)

Barnstar

Proposed a barnstar for the project. Open to critique and suggestions. Please see Wikipedia_talk:WikiProject_Wikipedia_Awards#Accessibility_Barnstar. EvergreenFir (talk) Please {{re}} 02:16, 30 July 2015 (UTC)

Navbox colours

I've raised a concern about the accessibility of the default colours in {{Navbox}}, at Template talk:Navbox#Accessibility. Your contributions will be welcome. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:29, 30 July 2015 (UTC)

Accessibility tracking meta category

Newly created: Category:Accessibility issue tracking categories. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:39, 30 July 2015 (UTC)

Floated TOCs

I've known for some time that the table of contents (TOC) must be just before the first section heading, for screen readers. But where is this actually stated? I recently directed somebody to WP:TOC and now reviewing that guideline, I find that it says "usually a heading after the TOC is preferable, __TOC__ can be used to avoid being forced to insert a meaningless heading just to position the TOC correctly" which implies that a TOC can be placed part-way through the lead section - which is surely not what we want people to do. --Redrose64 (talk) 18:50, 3 August 2015 (UTC)

There's no doubt that the TOC should appear just before the first heading as a screen reader doesn't want to hear half the lead, then the TOC, then the remaining lead. If our documentation doesn't explicitly say that, then it's about time it did so. The quoted text is misleading, in my humble opinion. What I assumed it meant, at first glance, was that in articles with less than four sections, we can still force a TOC without having to add more headings - but I see that's not what it says. If we changed the final phrase to "just to create a TOC in short articles", we might reflect the actual point of __TOC__. --RexxS (talk) 19:49, 3 August 2015 (UTC)

The accessibility implications of moving the TOC are mentioned in the second point in the "Floating the TOC" section, but I agree that the wording above that is not ideal. Graham87 01:44, 4 August 2015 (UTC)

Barnstar Proposal

Hello everyone! I am proposing this barnstar for (1) use by WikiProject Accessibility and (2) to recognize contributions to further increase accessibility to Wikipedia. Got the idea because I wanted to recognize some of the folks who have been making great efforts to increase accessibility on Wikipedia and thought a project barnstar would be an appropriate way of doing this. I have used Colour Contrast Analyzer to view the image in various forms of colorblindness and in grayscale. It appears to be visibly accessible under all conditions. I originally posted the barnstar at the Awards Project, but was told to get local consensus for it here (which makes sense...)

Does the project want this barnstar? Please make your opinion known. Thank you! EvergreenFir (talk) Please {{re}} 16:07, 31 July 2015 (UTC)

Sorry to solicit replies, but Pigsonthewing, RexxS, and Redrose64 any opinions? EvergreenFir (talk) Please {{re}} 20:47, 3 August 2015 (UTC)

This Barnstar can only help increase visibility of a traditionally underserved WikiProject and policy. Sounds like a good idea. ~ Rob^Talk 21:27, 3 August 2015 (UTC)

Apologies - I had meant to reply days ago, but it slipped my mind. Barnstars have a place in Wikipedia tradition, and recognition of other editors' contributions helps to encourage them. I think the one you have designed is apt and would be very much worth having for this project. --RexxS (talk) 09:50, 4 August 2015 (UTC)

Looks good; and I'm sure it will be well used. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 09:59, 4 August 2015 (UTC)

Accessibility discussion regarding small text in infobox

There exists a prevalent accessibility issue in Template:Infobox NFL player caused by the use of small text to denote whether a player was on a team during the regular season or just during the offseason or on the practice roster. WP:FONTSIZE disallows the use of text smaller than 11px, and specifically states to avoid use of small text in infoboxes. Please see the relevant discussion at the template's talk page regarding the possible removal of the small tags from this text. ~ Rob^Talk 06:17, 5 August 2015 (UTC)

Use of inaccessible markup in gridiron football infoboxes is widespread

I've just had to fix Special:Diff/671327448, only to discover that that's how the career history in (probably) all 7,000 {{Infobox gridiron football person}}s is coded. Is there a way we can get this sorted without expending hundreds of (wo)man hours? Alakzi (talk) 00:06, 14 July 2015 (UTC)

Paging Andy, RexxS and Dirtlawyer1. Alakzi (talk) 00:07, 14 July 2015 (UTC)

@Alakzi: I'm happy to consult regarding the appearance, but I have no technical expertise to offer on coding and data entry. I do know that Template:Infobox gridiron football is based on older code than Infobox NFL player and Infobox college football (which share common code), and as a result, the data for this template is entered in a different format than that for the NFL and college templates. Also, please note that this is the primary template for Canadian football players, not American professional and college players. If you are going to propose any solution that materially changes the appearance or the format of data entry, you really should seek the input of the WikiProject Canadian football guys. I am available to act as interlocutor with the WP:CFL editors as needed, but I don't pretend to speak on behalf of the WP:CFL guys -- they're off in their own CFL-centric orbit. Dirtlawyer1 (talk) 00:19, 14 July 2015 (UTC)

Thank you. I should've thought to explain; basically, a screen reader would read aloud all of the years, and then all of the teams. For more details, see Wikipedia:WikiProject Accessibility/Infoboxes. Alakzi (talk) 00:34, 14 July 2015 (UTC)

Bot? Or have the template intelligently parse into an asterisk? Note also that Template:Infobox basketball biography has separate entries for each team (e.g. yearsN/teamN) to save the user from formatting details such as these (and make life easier if consensus is to tweak formatting in the future).—Bagumba (talk) 00:22, 14 July 2015 (UTC)

A bot would definitely be preferable - though there's a bit of a shortage of them, I've noticed. The issue is with writing a robust enough pattern, which is hard to do without some prior analysis. And we'd need to know what the maximum number of items is if we're gonna split them into into separate parameters. Alakzi (talk) 00:44, 14 July 2015 (UTC)

This football is a vicious sport, so I'd think 20 teams is way longer than anyone has lasted. Shouldn't a robust bot spit out an error file if it is exceeded :-)—Bagumba (talk) 06:53, 14 July 2015 (UTC)

Technically still not correct--should be an ordered list rather than an unordered list. But the point you make is one I agree with.

Probably the best way to go about this is to create a new parameter to move that information into, then listify the contents and delete the old parameters. This allows for tracking. --Izno (talk) 00:40, 14 July 2015 (UTC)

And a request made at WT:Bot requests. And get the template modified. Someone with some AWB-fu can probably run this replacement. --Izno (talk) 00:42, 14 July 2015 (UTC)

Good point about the tracking; I'd not thought of that. Alakzi (talk) 00:59, 14 July 2015 (UTC)

Good catch. I, too, think a bot is the way to go. It may first be worth analysing a sample of, say, 100 articles (fewer may suffice) to see if there are any gotchas. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 07:50, 14 July 2015 (UTC)

While we are at it, some notes on the resulting punctuation (without altering the main gist).

The top label ("As player:") should not indent, it's the equivalent of the regular LH label (in two-column infobox).

I don't think the dotted list is needed in an infobox. Dotted lists are fine in inline text (regular paragraphs). Here indent and regularity may be used (creating visual lines by being in line without added visual graphs). The indent supports the sub-data level, and a more tabular-like list (as opposed to say small verbose lines) supports that it is a series.

I'd replace the ndash used with colon, to show: "2013: Baltimore Ravens*". Ndash is bascially used as a range-marker (between to equal words or numbers). Only rarely as a separator (see MOS:DASH). Also, quite often the period is a year range that already uses a dash. -DePiep (talk) 09:17, 14 July 2015 (UTC)

I've been editing frequently for CFL player bios recently. As far as I know, I'm the most active editor in that area, since I don't see new player biographies pop up that I don't create myself, really. Here's my personal preferred solution, but I can't enact it because I don't have any understanding of how to edit templates. We could temporarily leave the playing_teams/playing_years as they are now, but add additional parameters playing_team_1/playing_year_1 through playing_team_10/playing_year_10 that are coded to appear directly below playing_teams/playing_years in the same style that they currently appear. I'd happily volunteer to go through all player bios and make the appropriate adjustments if someone can create those additional parameters. The goal would be to eventually remove the playing_teams/playing_years parameters entirely from the template once the manual changes are made. While someone is tinkering with the template, if you could add the following text to appear directly below all playing teams/years, I would be very grateful: "*Offseason and/or practice squad member only". ~ Rob^Talk 13:38, 14 July 2015 (UTC)
"As they currently appear" - What do you mean? I want to verify your intent. --Izno (talk) 14:29, 14 July 2015 (UTC)
Just that the new parameters appear visually similar to the old non-accessible method. ~ Rob^Talk 14:34, 14 July 2015 (UTC)
You should read WP:Accessibility#Lists regarding formatting of talk pages...
Did the changes that Alakzi made today satisfy you? --Izno (talk) 14:37, 14 July 2015 (UTC)
Yes, they have. I'll start working on changing parameters through these articles. If a bot materializes, I certainly wouldn't object, but as noted earlier that could take a while due to high demand for them. I appreciate the long-term fix by Alakzi. ~ Rob^Talk 14:57, 14 July 2015 (UTC)

I should note that I specifically would not support the "band-aid" fix of formatting as in Ray Holley, unless the bot continuously runs and can make corrections if I continue to create bios the way I have been since June. That markup is not easy to edit, and it would discourage editors from helping out with creating new CFL articles. Even then, it's not a good long-term solution. ~ Rob^Talk 13:42, 14 July 2015 (UTC)
To help inform any discussion on whether a bot is worthwhile, I've processed around 150 today, averaging around 1 per minute. I can probably get through 100 or more per day, which would resolve this in around 3 months if I did the majority (counting an upcoming vacation and days where I'm unable to edit much). Things might speed up as we move along, though; the most recent articles will have only one team per article, and editors can fly through that by just fixing the labels from playing_years --> playing_years1 and playing_teams --> playing_team1. I'm going to notify a few WikiProjects affected by this template, if they haven't been already, and direct them to this discussion. ~ Rob^Talk 21:32, 14 July 2015 (UTC)

Wouldn't it be useful to have them listed in a maintenance category (eg "Category:Infobox gridiron football person articles that use a deprecated parameter"? -DePiep (talk) 23:18, 14 July 2015 (UTC)

Yes. Currently, I've been using "What links here" from the template to find all articles that use it. Essentially all articles that use this template at all have the deprecated parameters, so that's fine for one person working on it, but not for multiple. Is there an easy way to add only those articles that use the parameters "years", "teams", "playing_years", "playing_teams", "coaching_years", "coaching_teams", "administrating_years", "administrating_teams", "other_years", or "other_teams" to a category? ~ Rob^Talk 23:31, 14 July 2015 (UTC)

Will do this. -DePiep (talk) 23:46, 14 July 2015 (UTC)

Done. See Category:Infobox gridiron football person articles using deprecated parameters. -DePiep (talk) 00:25, 15 July 2015 (UTC)

Same with {{Infobox Speedway rider}} - see Category:Pages using Infobox Speedway rider with unknown or deprecated parameters. Alakzi (talk) 16:31, 17 July 2015 (UTC)
{{Infobox college coach}} appears to have the same issue, and does not have appropriate parameters in place to address the issue yet. Also, as an update, the gridiron football template is down to ~4000 left. I was able to take care of roughly 2,500 through automation and am gradually working through the rest. ~ Rob^Talk 02:09, 29 July 2015 (UTC)
- I've added the necessary parameters and tracking. Alakzi (talk) 11:16, 29 July 2015 (UTC)
I bit off more than I can chew in thinking I could manually handle all of these. I managed to automate a good many and have completed several hundred by hand. I'll continue to work through these by hand whenever I find an article that does not use the new parameters, but if anyone is able to develop either a bot or script to handle this, that would be extremely helpful. I greatly underestimated the number of teams that some of the more obscure players that hop from practice roster to practice roster have listed in their articles. ~ Rob^Talk 06:08, 5 August 2015 (UTC)
- Damn the Pareto principle. --Izno (talk) 06:18, 5 August 2015 (UTC)
  - No joke. Some of the coaches went above 20 entries and contained separate issues with WP:FONTSIZE. The worst take upwards of 5 minutes for a single edit. Multiply by 4000 remaining transclusions and I'd have to drop out of university. ~ Rob^Talk 06:23, 5 August 2015 (UTC)

Mobile changes

Hi everyone, there are some proposed design changes for how the lead section of the article could be displayed on mobile web. The rationale and specifics of the change are elaborated on the mediawiki page. Please take a look and post your suggestions to the talk page. Whatamidoing (WMF) (talk) 17:24, 18 August 2015 (UTC)

Editors adamant on flouting WP:COLOUR

Another day on Wikipedia, another war of attrition on the topic of accessibility. Enjoy. Alakzi (talk) 07:39, 26 August 2015 (UTC)

Line color cat

@AlexTheWhovian, Alakzi, and Favre1fan93: Found a glitch in Category:Episode lists with invalid line colors. It appears that LineColor=none causes the page to be categorized as an invalid line color. For example, see The Adventures of Don Quick. EvergreenFir (talk) Please {{re}} 20:25, 27 August 2015 (UTC)

@EvergreenFir:, that is an invalid color, but can be fixed by simply removing the parameter. it could be useful to ignore the cases where there is no shortsummary. although, just fixing the articles works as well. Frietjes (talk) 20:30, 27 August 2015 (UTC)

Okay... it's not a WP:COLOR violation, but I guess that makes sense to include them. EvergreenFir (talk) Please {{re}} 20:34, 27 August 2015 (UTC)

I don't think ignoring cases where there is no short summary would be helpful, because if a summary ever is added, the line color will appear and will be invalid. - Favre1fan93 (talk) 21:51, 27 August 2015 (UTC)

[a]

[b]

[c]

[d]

[e]

[f]