Wikipedia talk:WikiProject Accessibility: Difference between revisions

This is the talk page for discussing WikiProject Accessibility and anything related to its purposes and tasks.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8Auto-archiving period: 150 days

	Accessibility
This page is within the scope of WikiProject Accessibility, a group of editors promoting better access for disabled or otherwise disadvantaged users. For more information, such as what you can do to help, see the main project page.AccessibilityWikipedia:WikiProject AccessibilityTemplate:WikiProject AccessibilityAccessibility articles

This is the talk page for discussing WikiProject Accessibility and anything related to its purposes and tasks.

Put new text under old text. Click here to start a new topic. New to Wikipedia? Welcome! Learn to edit; get help. Assume good faith Be polite and avoid personal attacks Be welcoming to newcomers Seek dispute resolution if needed

Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8Auto-archiving period: 150 days

Wikipedia:Wikipedia Signpost/WikiProject used

I have a quick question since it was brought up at Talk:Utah Warriors#Colored tables. The colors   and   are used on hundreds (thousands?) of articles designating won and lost games as backgrounds on tables in season pages. In the linked discussion, the editor has claimed these fail accessibility, but when I use the tools in MOS:CONTRAST, it says they are fine.(red and green) As I am no expert here, is it truly an accessibility issue or of a personal preference/over-decoration issue? (If it is the former, a longer discussion probably needs to take place. If it is the latter, then it would just a consensus style discussion for that particular group.) Yosemiter (talk) 05:04, 13 February 2019 (UTC)[reply]

Those colours fail Snook's Colour Contrast Check when checking against linked text (black text is okay), but not by much. It's not enough to start a war over, but slightly less saturated background colours (e.g.   and  ) would render links more legible, especially visited links against the red background. I've left some comments and recommendations at Talk:Utah Warriors #Colored tables, but that will be pertinent to any use of those colours as backgrounds. --RexxS (talk) 15:53, 13 February 2019 (UTC)[reply]

@RexxS: Appreciate the comments. As I stated there, I do not have any particular preferences, I was was just carrying over what has been typically used in the past (which is not a justifiable reason to continue using per se, as described in WP:OTHER). It may be worth bringing up the contrast issues with linked text as it is widely used by Wikipedia:WikiProject Sports. Yosemiter (talk) 16:17, 13 February 2019 (UTC)[reply]

@RexxS: You wouldn't happen to have the color code for visited links handy? I believe unvisited is #002BB8? Yosemiter (talk) 23:11, 21 March 2019 (UTC)[reply]

@Yosemiter: The default colour for visited links for Vector skin is #0B0080 (although it's #5A3696 in Monobook skin). You're right about unvisited. --RexxS (talk) 23:25, 21 March 2019 (UTC)[reply]

@RexxS: @Yosemiter: Late coming to this, but default colours can be found at WP:LINKCOLOR, which indicates that the default colour for unvisited links is actually lighter (#0645AD). —Domeditrix (talk) 22:00, 11 August 2019 (UTC)[reply]

@Domeditrix: Sorry I wasn't very clear about that. #002BB8 is the base colour for Monobook links, i.e. 'unvisited' (defined by a {color: #002bb8;}) as you can check with the inspector. You're right about Vector, but it's annoying for old-timers that WP:LINKCOLOR only considers Vector skin. --RexxS (talk) 22:39, 11 August 2019 (UTC)[reply]

FYI

 – Pointer to relevant discussion elsewhere.

Posted at VPT by John Cline (talk · contribs): Wikipedia:Village pump (technical)#Technical advice needed; Thanks. This concerns the width of an infobox when the browser is zoomed in, and I see it as an accessibility concern. --Redrose64 🌹 (talk) 11:30, 12 April 2019 (UTC)[reply]

I asked about reasons for not linking in section headers at Wikipedia_talk:Manual_of_Style/Linking#Links_in_section_headers. one of the replies suggested there may be an accessibility problem, so checking here. Please ping with reply, Cheers, · · · Peter Southwood ^(talk): 05:30, 25 April 2019 (UTC)[reply]

@Peter: no current issue that I'm aware of. I've made a demo at Wikipedia talk:Manual of Style/Linking #There is a link to the Main Page in this section header. Cheers --RexxS (talk) 14:19, 25 April 2019 (UTC)[reply]

Thanks RexxS, · · · Peter Southwood ^(talk): 17:19, 25 April 2019 (UTC)[reply]

Have you seen these comments? --Redrose64 🌹 (talk) 21:44, 8 May 2019 (UTC)[reply]

Hopefully of interest to this WikiProject is CSS Color Adjust Module Level 1 which was published yesterday as a "W3C First Public Working Draft"; its abstract states This module introduces a model and controls over automatic color adjustment by the user agent to handle user preferences, such as "Dark Mode", contrast adjustment, or specific desired color schemes.. Of course it will be some years before its provisions are embraced by browser vendors. --Redrose64 🌹 (talk) 18:42, 22 May 2019 (UTC)[reply]

I've been poking around a number of other W3C working drafts, and have found a proposal for a font-min-size property which will allow an author or user to require that an element’s font size be clamped within the specified range. If the specified value font-size is outside the bounds created by the used font-min-size and font-max-size, the computed value of font-size is clamped to the values specified in these two properties. --Redrose64 🌹 (talk) 18:40, 27 May 2019 (UTC)[reply]

Currently there are discussions related to colour usage on two articles related to the recent European Parliament elections, if anyone is interested in contributing: Talk:2019 European Parliament election#Overcoloured and Talk:2019 European Parliament election in the United Kingdom#Misuse of colour. -- DeFacto (talk). 18:33, 28 May 2019 (UTC)[reply]

Apparently if you put a bulleted list inside one of the definitions in a definition list, at the end of a definition, it makes the definition list end right after the bulleted one. Now, if you put a blank line with just the colon after the bulleted list, it doesn't end the list, but it does put in a blank element. So it seems this is wrong:

; Cats
: Animals that make several different sounds:
:* meow
:* purr
; Mosquitoes
: These animals rarely speak, or at least that's what humans think. Humans do here them buzz sometimes. 

And this doesn't seem perfect either, but it was the least wrong I could come up with:

; Cats
: Animals that make several different sounds:
:* meow
:* purr
:
; Mosquitoes
: These animals rarely speak, or at least that's what humans think. Humans do here them buzz sometimes.

So I'm guessing the latter is preferred but, I'm really not sure. – Pretended leer {talk} 09:59, 6 August 2019 (UTC)[reply]

I think it was Anomie and I who recently discovered this. This issue probably should be a rarity because you should not be putting complex list blocks into this kind of list in the general case (at least in articles; talk pages are a lost cause anyway). --Izno (talk) 14:08, 6 August 2019 (UTC)[reply]

thanks! The article where I saw this seems to be using definition lists for something that... it's not really definitions, but it's mostly single sentences. It's this one: Solved game. Is it the kind of situation where bold paragraphs would be appropriate? – Pretended leer {talk} 14:35, 6 August 2019 (UTC)[reply]

That particular article's bullet list could probably be made into a single paragraph. I haven't given a lot of thought to whether that should be an association list at all, but on first observation that looks reasonable. --Izno (talk) 17:12, 6 August 2019 (UTC)[reply]

Can someone take a look at Lecrae discography and see where it fails the Accessibility policy? This list is typical of discography articles. There were some previous discussions, and I've looked at the guidance for data tables, and I'm still not sure of what is within policy and what is not, and how to fix any violations.

Thanks, --3family6 (Talk to me | See what I have done) 19:39, 6 August 2019 (UTC)[reply]

I made a couple of edits to demonstrate increased accessibility [1] and [2], though I am not sure how much is required per se by the guidance. Comments on each:

• The scopes were generally good. I added a 'colgroup' which is approved scope for use when there are subcolumn headers.
• Avoid use of small text (especially the small element in most cases) and arbitrary widths. The former prevents users with bad eyesight from reading and the latter prevents users with varying screens from getting the most out of the table.
• Avoid the list as they were--each of those corresponded to a facet of the title, and you provided them as if they were data--so add a column for each. This isn't strictly necessary but it does enable table simplification and a more 'data' table rather than a 'table used for structure'.
• Provide keys at the beginning of the table rather than later. That makes it obvious to a reader what is going on.
• Likewise remove the note to either before or after the table. This enables a simple table and reduces confusion for an unsighted reader when he gets to that row.

An additional change for the longer table now would be to add the sortable class so a reader with full capabilities can sort on each column if he desires. --Izno (talk) 22:58, 6 August 2019 (UTC)[reply]

Thank you! I will try to work on anything which you did not already do. Can you please explain #3, "Avoid the list as they were"?--3family6 (Talk to me | See what I have done) 03:50, 7 August 2019 (UTC)[reply]

Uh, trying to say that, because you covered the same content in each of the lists, and each of the lists corresponded to a title, that what you were trying to do was add some more data to the table--for which a table cell for each list item is generally the best. Why else use a table? :) --Izno (talk) 03:30, 8 August 2019 (UTC)[reply]

Okay, yes, and I think I ended up doing this anyway. Take a look at where I'm at so far and see if this looks right, if you like.--3family6 (Talk to me | See what I have done) 04:33, 8 August 2019 (UTC)[reply]

The tables are a bit inconsistent from the stuff up top down to the stuff toward the bottom with e.g. the styling on the first cell--I think you just forgot to convert those to use exclamation points? The other thing that needs changing is the far right column on the lower tables; you shouldn't use rowspans like that. --Izno (talk) 05:31, 10 August 2019 (UTC)[reply]

Izno, yes, I didn't use the exclamation points. Regarding rowspan, do you mean the entries in the "Album" column?--3family6 (Talk to me | See what I have done) 03:26, 16 August 2019 (UTC)[reply]

Yes. --Izno (talk) 12:26, 16 August 2019 (UTC)[reply]

Thanks.--3family6 (Talk to me | See what I have done) 03:26, 20 August 2019 (UTC)[reply]

Izno, anything else outstanding now?--3family6 (Talk to me | See what I have done) 03:39, 22 August 2019 (UTC)[reply]

There is currently an ongoing discussion on the WikiProject Football talk page regarding potential changes to the club seasons template. Any input from those with some knowledge on the topic would be extremely welcome – I think we're quite well-meaning but fumbling in the dark a little! Domeditrix (talk) 14:06, 12 August 2019 (UTC)[reply]

When is use of small text helpful and when is it unhelpful? Specifically, is the use of small text in Template:Track listing an example where it is helpful?--3family6 (Talk to me | See what I have done) 20:35, 11 September 2019 (UTC)[reply]

Semantically, the <small>...</small> element represents side comments such as small print. This is followed by examples, and nothing resembling a music track listing seems to be among them. --Redrose64 🌹 (talk) 21:23, 11 September 2019 (UTC)[reply]

@3family6: To add to what Redrose64 says above, pragmatically, Wikipedia has allowed text size to be reduced when space is at a premium, such as in tables and infoboxes. Traditionally, the community has tolerated abuse of semantic markup for practical purposes. I wouldn't recommend misuse of <small>...</small> for convenience in cramming information into a small space; but if you must, then using something like <span style="font-size:90%;"> ... </span> or the {{small}} template, is free of semantic meaning. Please remember, though, that under no circumstances should the resulting font size fall bellow 85% of the normal page font size, for accessibility reasons. --RexxS (talk) 22:36, 11 September 2019 (UTC)[reply]

Okay, thank you!--3family6 (Talk to me | See what I have done) 17:10, 12 September 2019 (UTC)[reply]

Hello! I believe that I may have started a discussion process about the use of alt text in mathematical formulae. I have learned today that the alt text is automatically generated from the TeX code that was used to generate the formula. Any other alt text given in the <math> environment is currently ignored, contrary to the help pages on the topic. The pertaining existing discussions are at the Talk page of the Help page and most directly at the bug report at [3]. Since the feature of displaying alt text is now back in the state of feature request, it would be excellent to chime in to the discussion. --Lpd-Lbr (talk) 19:00, 17 September 2019 (UTC)[reply]

Discussion at Wikipedia_talk:Manual_of_Style/Accessibility#Diagonal_split_color_box AngusWOOF (bark • sniff) 21:50, 17 September 2019 (UTC)[reply]

 You are invited to join the discussion at Talk:List of American Horror Story episodes#Graph . Radiphus (talk) 12:45, 20 September 2019 (UTC)Template:Z48[reply]