Wikipedia talk:Manual of Style/Accessibility: Difference between revisions
SandyGeorgia (talk | contribs) →White space: re x 2 |
m Archiving 2 discussion(s) to Wikipedia talk:Manual of Style/Accessibility/Archive 17) (bot |
||
Line 1: | Line 1: | ||
{{Redirect|WT:ACCESS|the related wikiproject talk page|Wikipedia talk:WikiProject Accessibility}} |
|||
{{Redirect-multi|2|WT:COLOR|WT:COLOUR|WikiProject Color's talk page|Wikipedia talk:WikiProject Color}} |
|||
{{Skip to talk}} |
|||
{{talk header |search=yes |bottom=yes|WT:ACCESS|WT:ACCESSIBILITY}} |
|||
{{WikiProject banner shell|class=B| |
|||
{{WikiProject Manual of Style}} |
|||
{{WikiProject Accessibility}} |
{{WikiProject Accessibility}} |
||
{{Wikipedia Help Project|class=b|importance=mid}} |
|||
}} |
|||
{{User:MiszaBot/config |
|||
|archiveheader = {{archive}} |
|||
|maxarchivesize = 250K |
|||
|counter = 17 |
|||
|minthreadsleft = 6 |
|||
|algo = old(90d) |
|||
|archive = Wikipedia talk:Manual of Style/Accessibility/Archive %(counter)d |
|||
}}{{User:HBC Archive Indexerbot/OptIn |
|||
|target=/Archive index |
|||
|mask=/Archive <#> |
|||
|leading_zeros=0 |
|||
|indexhere=yes}} |
|||
== [[WP:NOBR]] notes == |
|||
{{archive box| |
|||
* [[/Archive 1]]}} |
|||
are there any acceptable uses for the HTML line break {{code|<br/>}}? on [[Special:PermanentLink/1246514405|a recent edit of mine]], I substituted a {{tl|ubl}} template into the HTML line break, as this was not being used for a list but as a visual break for the default size, separating the series title from the year in a table, for visual harmony. |
|||
== WCAG Samurai == |
|||
I have seen this sort of visual break in many articles that I have edited, especially less cared ones, but how should it be handled? is it COMPLETELY discouraged it, even for use cases where there is legitemately no factor other than aesthetics or what to do instead? [[User:JnpoJuwan|Juwan]] ([[User talk:JnpoJuwan|talk]]) 12:21, 19 September 2024 (UTC) |
|||
Hi, I've just noticed that the [http://wcagsamurai.org/ WCAG Samurai] finally released in June a draft of its WCAG 1.0 errata. This errata is not published by the W3C but by a group of accessibility experts, but I think they are sound and a real improvement updating these guidelines to current web technologies. For example, I've just removed the requirement to use an HTML 'summary' attribute to data tables [http://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia:Accessibility&diff=178067287&oldid=175530659] as explained in the errata. It's true that actually nobody uses it (neither me), and it doesn't offer any real accessibility improvement (the same info can be written in the article's text, so it will be available to every reader). |
|||
:Not to hock my own slogan, but essentially as I understand it, [[WP:break means pause|break means pause]]. That is to say, line breaks are acceptable when they actually represent semantic breaks in content, perhaps roughly equivalent to a paragraph break. They should neither be used to create the appearance of lists nor to manually wrap a single block of text, but beyond that there are actually plenty of plausible applications. Infobox templates themselves actually use them a lot under the hood. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 12:24, 19 September 2024 (UTC) |
|||
The drafts of the second W3C accessibility guidelines, WCAG 2.0, have been very criticised, so from my point of view we should stick with WCAG 1.0 + Samurai errata. What do you think? Cheers —[[User:Suruena|surueña]] 13:02, 15 December 2007 (UTC) |
|||
::oh, that's actually a great essay! if you think it is appropriate please link it on the section, that's exactly what I was looking for. [[User:JnpoJuwan|Juwan]] ([[User talk:JnpoJuwan|talk]]) 12:49, 19 September 2024 (UTC) |
|||
:::It's incomplete at the moment, and I like the idea that others would link such things rather than me if they find it useful so that only useful things get linked, so if you think it would help others then go for it! <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 12:56, 19 September 2024 (UTC) |
|||
:Line breaks are for visual appearance only, and so semantically they are equivalent to whitespace. Appropriate semantic markup should be used as applicable. Line breaks should be used sparingly. As browser widths change or other elements are added to the page, the page will automatically be laid out differently by browsers, and manual overrides can work against this process producing a pleasing result. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 18:40, 19 September 2024 (UTC) |
|||
== Where to place accessibility templates on problem templates == |
|||
==Wheelchair article== |
|||
''30-Jan-2008:'' One of the problems I have with the article "[[Wikipedia:Accessibility]]" is that it hit me like "Here's the wheelchair article but anyway". Perhaps a short paragraph should be added to explain the term "browser" versus "screen reader" and such: it could be linked to the lede section as one sentence linked to a fuller section later in the article. -[[User:Wikid77|Wikid77]] ([[User talk:Wikid77|talk]]) 10:50, 30 January 2008 (UTC) |
|||
The section on color suggests placing the {{t|Overcolored}} template at the top of articles with contrast issues. What about templates. For example, the {{t|Transport in Mexico City}} template has major issues with contrast. But if I place the template at the top of the template itself, it will appear on dozens of pages, which would be disruptive. I wound up placing it on the [[Template talk:Transport in Mexico City|Transport in Mexico City template talk page]] at the top of my topic. |
|||
==1001 Wikipedian Nights== |
|||
''30-Jan-2008:'' Although no one is buying time by making the article a "[[shaggy dog story]]" in the sense of ''[[1001 Arabian Nights]]'', the article seems to be a long, rambling laundry list of issues. The article needs a short, succinct intro section to summarize "Ten Things I Hate about You and Your Writing" to, at least, try to focus on ten guidelines a writer should know before losing interest in Wikipedia. (Actually, the Top 7 would be better, but the Top 10 is probably needed to accommodate the current rambling). -[[User:Wikid77|Wikid77]] ([[User talk:Wikid77|talk]]) 10:50, 30 January 2008 (UTC) |
|||
It would be good to clarify this in the text as to where it would best be placed in templates. |
|||
==Thou hypocrite== |
|||
''30-Jan-2008:'' The article "[[Wikipedia:Accessibility]]" seems to violate so many aspects of accessibility and readability that it hit me like wiki-[[hypocrisy]]. If everything in Wikipedia weren't already iffy, I would have recommended pulling this "[[advice column]]" until after trying "[[Physician, heal thyself]]" to make the article more readable and usable. Within just a few sentences, the article starts talking about "TOC" with no concern to try showing "table of contents (TOC)" to introduce the acronym. Also, there's really no [[lede]] section summarizing the issues being presented. OMG, just think: with unknown acronyms and no lede section, just imagine how unreadable the remainder of the article could be. I won't generate a laundry list of complaints: people simply need to realize the article needs to be rewritten, then ask for reviewers. Guidelines need to be written to the highest standards, above just featured-article content. -[[User:Wikid77|Wikid77]] ([[User talk:Wikid77|talk]]) 10:50, 30 January 2008 (UTC) |
|||
[[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 06:14, 26 September 2024 (UTC) |
|||
==Skeleton crews== |
|||
''30-Jan-2008:'' In most areas of Wikipedia, the content is being written and condensed by mere "[[skeleton crew]]s" of volunteers: even the guidelines are revised by just a relative handful of people. For that reason, the content is often hollow, sparse, and marginal, as compared to writings by full-time staff writers. As a consequence, the Wikipedia policies rarely get the help and reviews that are needed. No one should feel blamed for the lowered content; it is a monumental task even if there were full-time pay. -[[User:Wikid77|Wikid77]] ([[User talk:Wikid77|talk]]) 10:50, 30 January 2008 (UTC) |
|||
:I would put it on the doc page as well. If there's not a maintenance category for templates with accessibility issues, maybe it should be created and populated! I would personally appreciate that. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 07:04, 26 September 2024 (UTC) |
|||
==Merge with technical== |
|||
:Place it in the template, either in the documentation, or if it doesn't, then at the bottom between the noinclude tags. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 08:31, 26 September 2024 (UTC) |
|||
''30-Jan-2008:'' Should article "[[Wikipedia:Make technical articles accessible]]" be merged with article ''[[Wikipedia:Accessibility]]''? |
|||
* '''Heck no'''. Overly technical articles might be only 2% (if that) of the total article base, hence 98% of writing does not need to worry about revising technical articles. I've tried simplifying dozens of those very complex articles (see: ''[[Discrete Fourier transform]]''), and I recommend a spinoff guideline to address the ultra-intellectual issues of technical writing. Just try simplifying several of those "too technical" articles ("{{tl|technical}}"), and it becomes clear that there are numerous high-tech issues to address, beyond where to place an infobox. -[[User:Wikid77|Wikid77]] ([[User talk:Wikid77|talk]]) 10:50, 30 January 2008 (UTC) |
|||
::Thank you! I've moved it to the template documentation as well as added it to a related template. That's what I will do moving forward. [[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 07:21, 27 September 2024 (UTC) |
|||
== Looping GIFs and accessibility == |
|||
==Text size== |
|||
As a person with good corrected vision, I find the {{Tl|Reflist}} text too small for comfortable reading, this must be worse for those with more serious visual problems. The accessibility guidelines have nothing to say on type size, perhaps something should be added? ''[[User:Rich Farmbrough|Rich]] [[User talk:Rich Farmbrough|Farmbrough]]'', 10:07 [[18 February]] [[2008]] (GMT). |
|||
My edit [https://en.wikipedia.org/enwiki/w/index.php?title=Wikipedia%3AManual_of_Style%2FAccessibility&diff=1247822330&oldid=1246585686 Animations: Clarified 5 seconds as total playing time] was reverted by {{u|Remsense}} with the comment "This is confusing to me: are looping GIFs simply not allowed?" |
|||
:Just my thoughts here. The difference between the main text and text in {{Tl|Reflist}} looks like about two points. On my computer the text in the references of [[Road]] appears to me the same size as text on the front page of the [http://seattletimes.com Seattle Times], so I don't see a problem. I think most people expect to see references supplied in font size that is smaller then the main text, it is what we usually see in print and bound books. I should also add that I have played with just about all my computer and browser settings for font size, so what I am seeing may not be the same as what a user on a virgin system is seeing. [[User:Jeepday|Jeepday]] <small>([[User talk:Jeepday|talk]])</small> 15:03, 18 February 2008 (UTC) |
|||
Rather than risking getting into an edit war, I am moving the matter here to attempt to gain consensus on wording before proposing a final edit. |
|||
::Currently, [[mediawiki:common.css]] is defining <code>.references-small { font-size: 90%;}</code> |
|||
::I'd thought there was some agreement somewhere that 92% was the smallest we should use anywhere, but I can't find the discussion I'm looking for currently. (See [[Template:FootnotesSmall]] and its talkpage for a bit of discussion about 92%) |
|||
::However, as long as we're allowing text to be resized by the user manually, such that they can increase fonts with their browser whenever needed (ctrl-+ and ctrl-− in firefox), I don't think we need to change anything drastically. Because user defaults (browser program/settings, OS font settings, monitor size/screen resolution) vary so drastically, we can't be perfect for everyone. -- [[User:Quiddity|Quiddity]] <small>([[User talk:Quiddity|talk]])</small> 18:59, 18 February 2008 (UTC) |
|||
WCAG 2.1 provides [https://www.w3.org/WAI/WCAG21/Techniques/general/G152 Technique G152: Setting animated gif images to stop blinking after n cycles (within 5 seconds)] |
|||
Rich just added the issue that I wanted to add. The Wikipedia is the only web site I regularly visit which has routine and ubiquitous use of small font sizes for matter that I want to read. I'm not going even attempt to reverse the decisions to use small fonts, but could there been a ''global setting in user preferences'' for '''minimum font size displayed''' (i.e. the floor of the font size). This would enable a person with a slight impairment such as myself to set it to 10 points, while people with greater impairment could set it to 12 or 14 points. |
|||
Looping GIFs are permitted as long as they stop looping such that the total animation time is 5.0 seconds or less. So: |
|||
To points raised above: The problem really isn't in the browser but in the Wikipedia renderer (or any web page with combining extra large and extra small fonts). The comparison to printed media is not accurate: the printed page is analog, and monitor legibility of smaller fonts to the visually impaired doesn't scale in the same way. [[User:Patsw|patsw]] ([[User talk:Patsw|talk]]) 20:18, 18 February 2008 (UTC) |
|||
:Note: I was comparing display font on the web pages [[Road]] and [http://seattletimes.com Seattle Times], Not print to web [[User:Jeepday|Jeepday]] <small>([[User talk:Jeepday|talk]])</small> 20:29, 18 February 2008 (UTC) |
|||
* A 1 second long animated GIF could loop 5 times |
|||
:It seems to me that the only reason we use small fonts is to look like traditional designed-for-paper scholarly works. ''[[User:Rich Farmbrough|Rich]] [[User talk:Rich Farmbrough|Farmbrough]]'', 20:42 [[18 February]] [[2008]] (GMT). |
|||
* A 1.5 second long animated GIF could loop 3 times |
|||
::And to reduce the size of massive refs sections, eg [[William Gibson#References]], which seem to bug some people. Personally, I'm often tempted to replace {{tl|Reflist}} with <nowiki><references/></nowiki>, but don't simply to avoid low-priority arguments/reversions. -- [[User:Quiddity|Quiddity]] <small>([[User talk:Quiddity|talk]])</small> 21:37, 18 February 2008 (UTC) |
|||
* A 2 or 2.5 second long animated GIF could only loop twice |
|||
* A 3 second long animated GIF could not loop at all |
|||
* Endlessly looping animated GIFs are not permitted at all |
|||
Hope that makes it clear (which I believe the current page wording does not do). |
|||
:Rather than switch conventions (a very low-priority, but very argumentative argument waiting to happen), it may be useful to know that an individual can fix this easily (just for them). One just adds |
|||
.references-small { font-size: 100%; } |
|||
:to your [[Special:Mypage/monobook.css]]. |
|||
:Perhaps it might be worth gathering some similar options and including them in the preferences as a simple "visually impaired" setting. Personally, I've always used Firefox's minimum font size to globally fix this problem. It makes some sites look ugly, but honestly, they looked uglier before. [[User:JackSchmidt|JackSchmidt]] ([[User talk:JackSchmidt|talk]]) 22:25, 18 February 2008 (UTC) |
|||
[[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 07:11, 27 September 2024 (UTC) |
|||
== lowercase articles == |
|||
:Suffice it to say, this does require conversation as almost no one operates based on this understanding, even if it's well-founded. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 07:13, 27 September 2024 (UTC) |
|||
The guidelines specify that disambiguating hatnotes should always go on top. Does this still apply in cases where the article uses the template {{tl|lowercase}}? Or would having something above that template interfere with its function? Just wondering. --[[User:ShelfSkewed|<font color="Red">'''Shelf'''</font><font color="Black">'''Skewed'''</font>]] [[User talk:ShelfSkewed|<font color="Blue"><small>Talk</small></font>]] 17:04, 7 April 2008 (UTC) |
|||
::From what I understand, and I'm woefully underread in the literature so this is partially anecdotal so forgive me, there is a significant distinction in accessibility between short animations that loop and long animations. [https://www.w3.org/WAI/WCAG21/Understanding/pause-stop-hide SC 2.2.2: Pause, Stop, Hide] says |
|||
::{{cquote| |
|||
::Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers. |
|||
::Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the Web page. Five seconds was chosen because it is long enough to get a user's attention, but not so long that a user cannot wait out the distraction if necessary to use the page. |
|||
::}} |
|||
::The operative sentence uses the word "blinking" in a manner I find to be a bit vague: I would intuit some distinction many people would perceive between "blinking", merely "looping", and "ongoing" animated content in terms of its potential to interfere with their ability to focus or comfortably read? Later, "blinking" is defined as "content that causes a distraction problem", which is unfortunately a bit circular for our purposes. If blinking is coterminous with moving, why isn't moving used? <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 07:22, 27 September 2024 (UTC) |
|||
:::As I understood it at the time that the HTML BLINK element was first deprecated, it's because certain blink rates can trigger seizures. I've never heard of a looped animation doing that, unless the animation is essentially two images displayed alternately. --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 08:20, 27 September 2024 (UTC) |
|||
:::It doesn't only say blinking, it also says moving or scrolling. The area of concern is "The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page." Long form animations need to be done via a pauseable video rather than by an uncontrollable animated GIF. [[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 09:57, 27 September 2024 (UTC) |
|||
::::I'm just trying to fully understand what SC 2.2.2 says and why. Most concretely, it says: |
|||
::::* {{xt|Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers.}} |
|||
::::* {{xt|Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the Web page.}} |
|||
::::The first point is about moving content in general, and doesn't really apply to our conversation about looping GIFs in particular. The second specifically discusses <em>blinking content</em>, which is the distinction I'm currently unclear about. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 10:04, 27 September 2024 (UTC) |
|||
:::::I do find it odd that they seem to focus on blinking so much. The issue is that if anything on my screen is animating when I am trying to read some other content on the page, then I will have difficulty concentrating on that other content. It doesn't matter whether the animated content is blinking or showing how an oil rig operates. If I have no way to stop it, I can't focus on the content that I'm interested in focusing on. |
|||
:::::I've seen reports of usability tests where people will hold their hand up to obscure the unstoppable animation, and I've done that too. That assumes an abled person who can hold their hand up for an extended period of time; someone who is both attention challenged and arm-mobility disabled would not have that workaround. It still would take some of their/my attention away from trying to absorb the content of interest. And it's making the site visitor adapt to the site rather than the site adapting to the visitor. Hope that makes it clear. [[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 23:51, 29 September 2024 (UTC) |
|||
::::::Certainly. As I admitted, my previous understanding was based partially on my own anecdotal experience, where I can only recall those in my life having spoken about an inability to focus amid stimulus I would have characterized as "blinking" or "ongoing" above, rather than "looping". Of course, I don't doubt at all that the problem would cover that area also—there was just enough of a question in my mind that I felt it appropriate to make explicit. |
|||
::::::General question I may cross-post to [[WP:VPT]]: what feasibility would there be in building a tool that can help us accomplish this task? It would seem to require transcoding every GIF on a live page to a video—there's no real advantage to using GIFs at all, right? <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 23:58, 29 September 2024 (UTC) |
|||
== Do we need to call out team and transit colors under color? == |
|||
:Interesting question, but I'm not sure what do you want to ask. AFAIK, initially this template just reported that the article's title must be in lower case, but due to technical limitations (MediaWiki features) it wasn't possible. Later, it added some JavaScript to "fake" the title (rendered it with lowercase, although MediaWiki really sent the page with the title in uppercase) but if JavaScript was disabled the fallback solution was to still render the old hatnote (so I suppose this is what all screen readers and text-only browsers showed, and thus accessible). But now it seems that MediaWiki implements a new attribute (DISPLAYTITLE) to really generate pages with lowercase titles. So now it doesn't matter when the {{tl|lowercase}} is placed (from the {{abbr|POV|Point of view}} of accessibility) because it doesn't generate a hatnote anymore, but {{abbr|IMO|in my opinion}} when it did that in the past it should be placed below the disambiguation links. Have I answered to your question? {{abbr|HTH|Hope this helps}} —[[User:Suruena|surueña]] 19:25, 7 April 2008 (UTC) |
|||
I notice a lot of issues on Wikipedia where text has contrast issues because someone has duplicated team or transit route colors. Do we want to specifically mention that using team and transit colors for text is not exempt from meeting contrast requirements, and that accessibility takes precedence over non-logo branding? |
|||
:: I think so, although I wasn't thinking about any hatnote generated by the {{tl|lowercase}} template. The particular article I was looking at was [[Go! (airline)]], which the template causes to be rendered as '''go! airline''' in the title display. What I was wondering was, if the disambiguation template is placed above the lowercase template, will the latter template still lower-case the display--that is, will it still function as intended? When I moved the disambig template to the top, everything seemed to work fine in the "Preview" view, but in the "Show changes" view, the article title was rendered capitalized. So I moved the dab hatnote back down before I saved, in case it was messing something up. But you are saying that the {{tl|lowercase}} template should function correctly no matter where it appears on the page?--[[User:ShelfSkewed|<font color="Red">'''Shelf'''</font><font color="Black">'''Skewed'''</font>]] [[User talk:ShelfSkewed|<font color="Blue"><small>Talk</small></font>]] 19:47, 7 April 2008 (UTC) |
|||
Team example |
|||
:::Never mind: It does the same thing (give different displays in "Show preview" vs. "Show changes" view) even with the lowercase template on top. Poor scientific method on my part; I should have checked both ways when I first noticed the difference. --[[User:ShelfSkewed|<font color="Red">'''Shelf'''</font><font color="Black">'''Skewed'''</font>]] [[User talk:ShelfSkewed|<font color="Blue"><small>Talk</small></font>]] 20:44, 7 April 2008 (UTC) |
|||
:[[Geelong West Giants]] uses white text on a orange background extensively. Orange text or backgrounds are particularly problematic because white on orange fails WCAG 2.x contrast test, but some people find orange on black harder to read. The logo doesn't need to meet contrast, but text does. The best practice would likely be to abandon the orange background. |
|||
::::OK, understood. But note that I didn't said anything about the correct behaviour of {{tl|lowercase}}, but about that this template doesn't have any accessibility issues with respect its placement at the page (I don't know if it has any restriction to work properly). Cheers, —[[User:Suruena|surueña]] 23:10, 7 April 2008 (UTC) |
|||
:The color #FFFFFF (white) on #F15C22 (orange) has a contrast of 3.33:1, which fails for text smaller than 18.66px bold or 24px not bold. |
|||
== Multiple columns in {{tl|reflist}} deemed bad == |
|||
Transit example |
|||
:''"Howzat for a provocative headline, eh?" — [[User:Superluser|superluser]]<sub>[[User_talk:Superluser|t]][[Special:Contributions/Superluser|c]]</sub>'' |
|||
:{{tl|Transport in Mexico City}} themes colors by route and mode. Several of the routes use insufficient contrast, such as [[:File:CablebúsCDMX_Línea_1.svg|Cablebús line 1]], which has white on light blue, which violates contrast at all sizes. |
|||
There have been some discussion on [[Template_talk:Reflist#Discussion_so_far|Template talk:Reflist]] about whether to remove multicolumn support from {{tl|reflist}}. |
|||
The simple solution would be to remove support for it in the reflist template, however, some users suggested it might be better to have a policy change? (I'm guessing they where referring to [[Wikipedia:Manual of Style|MoS]]?). So if you have any thoughts about that please consider taking part in the discussion. ''<br />— [[User:Apis O-tang|<span style="color: rgb(5, 85, 5);">Apis</span>]] ([[User talk:Apis O-tang|<span style="color: rgb(5, 85, 5);">talk</span>]]) 21:41, 15 May 2008 (UTC)'' |
|||
:The color #FFFFFF (white) on #4EC3E0 (light blue) has a contrast of 2.05:1, which fails for text at all sizes. This issue is complicated that the icon is supplied by the government of Mexico City, but the license permits modification, such as making the "1" black instead of white (changing <code>fill="#FFFFFF"</code> to <code>fill="#000000"</code> in the SVG code). But it might be simpler and less distracting to use actual text rather than an SVG image. |
|||
== What the...?! == |
|||
[[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 21:24, 27 September 2024 (UTC) |
|||
Anyone else notice that [[WP:ACCESS]] (in all uppercase) leads here, but [[wp:access]] (in all lowercase) leads to "make technical articles accessible"? Was this intentional, because it's messing me up and I can't be the only one...!? [[User:L'Aquatique|<font face="Georgia"><font color="#000000">'''L'Aquatique'''</font></font>]][[User talk:L'Aquatique|<font color="#838B8B">[<font face="Monotype Corsiva">talk</font>]</font>]] 06:15, 18 May 2008 (UTC) |
|||
:Fixed. -- [[User:Quiddity|Quiddity]] ([[User talk:Quiddity|talk]]) 17:52, 18 May 2008 (UTC) |
|||
:These colors have always been horrible, and not only for accessibility reasons. Look at [[Template:Geelong Football League]], the hyperlink in title is completely hidden. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 21:32, 27 September 2024 (UTC) |
|||
== Gadget proposal == |
|||
:Many years ago, the ice hockey WikiProject moved to using colour borders instead of colour backgrounds in order to improve accessibility (including legibility). See [[Template:Montreal Canadiens]] for an example. (Some ice hockey editors don't like how it looks, while others do, but the consensus has held.) I feel this approach is a reasonable tradeoff between visual design goals, and should be considered for other similar scenarios. [[User:Isaacl|isaacl]] ([[User talk:Isaacl|talk]]) 16:22, 28 September 2024 (UTC) |
|||
:I don't see the point of it. It's a digression. I mean, I guess the people doing it think it adds a coolness factor, but this isn't TikTok. We aren't here to be cool, and we're here to be informative, and coolness is a distraction from that. |
|||
:When we have a list of the names of fruits, we don't precede each one by an icon depicting the fruit. [[List of typefaces]] (thank the forces that be) doesn't display the name of each typeface in that typeface. But some people, when they create or see a list of countries, they feel the impulse to prefix each name with the country's flag, as though every mention of a country merits another reminder to the reader of what that country's flag looks like. This situation is the same. It's an encyclopedia, not a font catalog or sports journal or score sheet. Identify typefaces, countries, routes, teams, etc., by name, without decoration. And not only do the color embellishments serve no useful purpose but, as you note, they break accessibility. [[User:Largoplazo|Largoplazo]] ([[User talk:Largoplazo|talk]]) 17:13, 28 September 2024 (UTC) |
|||
::Funny enough, I'd much rather List of typefaces show examples of how each typeface looks like (and I actually do believe {{em|that is}} informative), than see another list with a country flag in it. [[User:Gonnym|Gonnym]] ([[User talk:Gonnym|talk]]) 10:27, 29 September 2024 (UTC) |
|||
:So what is the path forward for this? |
|||
:How do we get consensus to move all sports templates to the ice hockey model? Do we need a bot to make this edit, given that hundreds of pages are involved? Further, some of this styling has carried over to section headings in the manually edited content, for instance the table headings on [[Geelong West Giants]]. |
|||
:And what would be a solution for transit? I'm happy to go in to, say, {{tl|New York City Subway}} and replace all the icons with text. (I did check the history and there is no mention of "accessibility" or "contrast" in any of the revisions.) I suppose I could be bold and see what happens, but without specific advice here on [[Wikipedia:Manual of Style/Accessibility]] I don't feel I have the concrete advice to back me up. I don't want to get into an edit war. |
|||
:I suggest adding the following text to [[Wikipedia:Manual of Style/Accessibility]]: |
|||
::Do not use logos or themed colors in place of default-color text links. They can keep people with low vision who don't use screen readers from being able to read the link, and can cause concentration issues for people with cognitive disabilities. |
|||
:[[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 23:36, 29 September 2024 (UTC) |
|||
Further, when non-white background colors are used, it can interfere with being able to see whether a link underline indicates the linked page does or does not exist. Actually, it can interfere with being able to see the link underline at all. [[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 04:58, 1 October 2024 (UTC) |
|||
:Also noticing templates where the title bar text is over a background gradient, where once of the background colors would properly take white text and the other one would properly take black text, making it impossible to choose an accessible text color that works with both. For example, {{tl|MARTA Red and Gold lines}}, {{tl|MARTA Blue and Green lines}}, and {{tl|Richmond station (California)}}. [[User:Thisisnotatest|Thisisnotatest]] ([[User talk:Thisisnotatest|talk]]) 22:34, 4 October 2024 (UTC) |
|||
==RfC partly concerning vision accessibility== |
|||
Can I have some more opinions about [[Wikipedia:Gadget/proposals#Gadget to move the section edit links right next to the headings|adding a gadget to move the section edit links]] so that they are easier to use with screen readers? '''[[User:Graham87|Graham]]'''<font color="green">[[User talk:Graham87|87]]</font> 14:00, 1 June 2008 (UTC) |
|||
[[File:Symbol watching blue lashes high contrast.svg|25px|link=|alt=]] You are invited to join the discussion at [[:Wikipedia talk:Manual of Style/Linking#RfC: Linking of three-part place names|Wikipedia talk:Manual of Style/Linking § RfC: Linking of three-part place names]]. <span style="font-family:courier"> -- [[User:Tamzin|<span style="color:#E6007A">Tamzin</span>]]</span><sup class="nowrap">[[[User talk:Tamzin|<i style="color:#E6007A">cetacean needed</i>]]]</sup> <small>([[User:Tamzin/🤷|they|xe]])</small> 20:59, 17 October 2024 (UTC)<!-- [[Template:Please see]] --> |
|||
== What to do about flashing images == |
|||
:I've just voted for the bug that fixed this in the software, don't forget to [https://bugzilla.wikimedia.org/votes.cgi?action=show_user&bug_id=11555#vote_11555 vote also for this one!] BTW, also just noticed that there is a '''specific category for [https://bugzilla.wikimedia.org/buglist.cgi?keywords=accessibility&resolution=--- accessibility MediaWiki bugs]''', which is a good thing (and very encouraging, indeed). It's important to tag new accessibility related bugs with this tag, and add old bugs to this category (if all of us vote for them, they will be fixed in less time). I've just tagged a couple of old bugs. Cheers, —[[User:Suruena|surueña]] 11:25, 3 June 2008 (UTC) |
|||
[[MOS:ANIMATION]]: {{tpq|In addition, animations must not produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.[14]}} |
|||
::I read in some bug report that developers ignore votes. I can't remember where I read it, but I've seen many bugs which caused a lot of distress [[:bugzilla:9213|bug 9213]] being an example, not being acted on for months. The accessibility keyword gives the bug a high priority, and I think adding that to all accessibility-related bugs is more importannt. '''[[User:Graham87|Graham]]'''<font color="green">[[User talk:Graham87|87]]</font> 12:00, 3 June 2008 (UTC) |
|||
Let's say there's an animated image in several articles with rapid blinking, well exceeding 3 f/s. And, let's say it's effectively impossible to illustrate the thing it illustrates, w/out rapid blinking. Is the right thing to do, just remove the image then? '''Photosensitivity Warning:''' Thinking of [[:File:Strobe 2.gif]]. Looking at that thing gives ''me'' a headache. --[[User:Slowking Man|Slowking Man]] ([[User talk:Slowking Man|talk]]) 21:56, 21 October 2024 (UTC) |
|||
:::OK, understood. I searched and tagged more accessibility-related bugs, but there are surely more. Cheers —[[User:Suruena|surueña]] 13:40, 3 June 2008 (UTC) |
|||
== |
== Concerns with [[MOS:PSEUDOHEAD]] == |
||
Going to say my piece here before being bold and seeing if others agree. The "acceptable" way of PSEUDOHEAD, shouldn't be an "acceptable" method. It's still pseudohead and is very manipulated by the community. Countless articles I have seen have dodged the use of headers by using bold markup instead which is pretty stupid, in my opinion. Maybe changing the language to make sure that people understand that it is ONLY to be used for when {{t|TOC limit}} can't be used. Right now, if I was an editor who never saw it. I'd see the acceptable way of using it and then just go ahead and use it, no questions. Or even get rid of the acceptable way and make it incorrect and tell people to suck it up. <span style="font-family:Arial;background-color:#fff;border:2px dashed#69c73e">[[User:Cowboygilbert|<span style="color:#3f6b39">'''Cowboygilbert'''</span>]] - [[User talk:Cowboygilbert|<span style="color:#d12667"> (talk) ♥</span>]]</span> 19:49, 31 October 2024 (UTC) |
|||
As currently written, [[WP:ACCESS]] demands that ''all'' navigation boxes be placed after the lead and before the table of contents. While I think this is fine for ''some'' navboxes, I can't support this approach for ''all'' navboxes in ''all'' articles, because of the three problems it causes: |
|||
:I would go further: if you're running into situations where you're struggling with {{tlx|TOC limit}}, there's almost certainly something wrong with how you're structuring the article. Even the heftiest prose articles rarely need level-4 headings and frankly should never use level-5 headings. I'm willing to go out on a limb and say the same is the case for list articles unless someone can show me a counterexample. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 19:53, 31 October 2024 (UTC) |
|||
* ''Implying an inappropriate level of importance.'' {{tl|Cardiac glycosides}}, like hundreds of similar medicine-related navigation boxes is intended as a convenient alternative to manually adding long, identical lists of medication-related articles to ''See also'' in dozens of articles such as [[Digoxin]]. Putting it at the end of the lead is essentially putting ''See also'' at the end of the lead. It's obvious from the visual layout that this template was intended to be placed at the very end of the article: it runs full-width across the screen. Also, can you imagine anyone starting at [[Digoxin]] for the purpose of finding [[Proscillaridin]]? |
|||
::I did see an issue with {{t|TOC limit}} is that you need to have nested-headers when doing lvl 4 or lvl 5. So it MUST follow a level 3 header. {{pb}}So you can't do:<br><code>== Header ==<br>==== Small header====<br></code>{{pb}}so you have to do:<br><code>== Header ==<br>=== Small-ish header ===<br>==== Small header ====<br></code>{{pb}}Which could be fixed with fixing the TOC limit template code but I am not a template editor. <span style="font-family:Arial;background-color:#fff;border:2px dashed#69c73e">[[User:Cowboygilbert|<span style="color:#3f6b39">'''Cowboygilbert'''</span>]] - [[User talk:Cowboygilbert|<span style="color:#d12667"> (talk) ♥</span>]]</span> 19:57, 31 October 2024 (UTC) |
|||
* ''Screwing up the formatting.'' Look at what happens to the formatting at [[Phylogenetics]] if you move {{tl|Evolution3}} after the text of the lead. The navbox runs down into the text of the next section. On older browsers, this could result in covering up text. (And on not-so-old browsers, either: In my entirely up-to-date browser (and given my font settings), the taxobox very slightly displaces an image so that it covers up the first four words at [[Plumeria#Etymology and common names]].) |
|||
:::I'm not quite understanding how this is an issue, unless it's that other editors would like to skip to smaller font sizes or more granular divisions. I would reiterate what I said above: it seems almost certain to me that if an editor finds themselves wanting this, they should consider whether they're doing something idiosyncratic or unnecessary. <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 20:01, 31 October 2024 (UTC) |
|||
* ''Overloading the lead.'' A huge number of science and medicine articles have large infoboxes (sometimes called taxoboxes) -- particularly if you look at articles on [[medication]]s or living organisms. Consider what happens when you have both an infobox and a navbox in the lead. Think about what [[Digoxin]] would look like if the navboxes were added to the lead. You'd have rather more screens of 'sidebar' navboxes than you would of text. |
|||
::::I saw it happen on [[Chromakopia]] while fixing it's PSEUDOHEAD. It has lvl 2 headers and then lvl 4 headers, but you can't limit lvl 3 because there are other sections that need to show on the TOC. {{small|(i did have to google idiosyncratic btw)}} But on articles where I mainly see it, which is in [[:Category:Production discographies]], they aren't an issue because it's usually a lvl 2 followed by a lvl 3 header. <span style="font-family:Arial;background-color:#fff;border:2px dashed#69c73e">[[User:Cowboygilbert|<span style="color:#3f6b39">'''Cowboygilbert'''</span>]] - [[User talk:Cowboygilbert|<span style="color:#d12667"> (talk) ♥</span>]]</span> 20:04, 31 October 2024 (UTC) |
|||
:::::My point is that one should never have to skip levels: usually, the better solution is either to omit the granular lower-level headings as unnecessary, or be less dogmatic about the scope of higher-level headings (for example, sections that relate the narrative of a historical event shouldn't be stuffed under a top-level "History" section, like [[Special:Diff/1254446762|my least favorite LTA]] and many others feel the need to do). <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 20:10, 31 October 2024 (UTC) |
|||
I think that we need to clarify in this guideline that not ''all'' articles should have ''all'' navigation boxes at the top. Navboxes in the lead should probably be restricted to shorter navboxes that are believed to be of immediate interest to the general reader, and even then only added to the lead in the absence of a large infobox (i.e., when it won't make subsequent sections illegible). |
|||
::::::[[MOS:GOODHEAD]] is clear: {{tq|1=Nest headings sequentially, starting with level 2 (<code>==</code>), then level 3 (<code>===</code>) and so on. (Level 1 is the auto-generated page title.) Do not skip parts of the sequence}} --[[User:Redrose64|<span style="color:#a80000; background:#ffeeee; text-decoration:inherit">Red</span>rose64]] 🌹 ([[User talk:Redrose64|talk]]) 00:04, 1 November 2024 (UTC) |
|||
:::::::I suppose I would echo Gil's question here: what is the expected use case for pseudoheaders when formatted correctly? <span style="border-radius:2px;padding:3px;background:#1E816F">[[User:Remsense|<span style="color:#fff">'''Remsense'''</span>]]<span style="color:#fff"> ‥ </span>[[User talk:Remsense|<span lang="zh" style="color:#fff">'''论'''</span>]]</span> 02:09, 1 November 2024 (UTC) |
|||
Furthermore, if the information in the navbox is essentially ''See also'' material, then it should be placed at the end of the article. [[WP:Portal|Portals]], for example, should probably be placed in the ''See also'' section in most articles. After all, if you're already at [[Plumeria]], you probably want to read about these flowers instead of taking an immediate trip to [[Portal:Plants]]. |
|||
Does anyone object to clarifying these points? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 18:54, 24 August 2008 (UTC) |
|||
: I don't believe this guideline intends to ''demand'' that navboxes be placed in the lead, rather to state that when they ''are'' placed in the lead, they should follow the text. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 19:14, 24 August 2008 (UTC) |
|||
:: I'm all for clarification. So I don't mind. [[User:Butwhatdoiknow|Butwhatdoiknow]] ([[User talk:Butwhatdoiknow|talk]]) 20:27, 24 August 2008 (UTC) |
|||
::: I agree with SandyGeorgia, it doesn't try to enforce that all navboxes should be placed in the lead, but because the current practice is to put some (vertical) navboxes at the top of the article it is more accessible to move them below the lead than above it. Of course it doesn't suggest that those (horizontal) navboxes usually put at the bottom of the article should be moved to the top (is that your point?). But adding a clarification in the text can avoid any misunderstanding, so feel free to add it to that guideline. With respect screwing up the formatting and overloading the lead, this guideline doesn't create those problems because there are a lot of navboxes so long that will reach the first section even if it is placed above the lead. Maybe that's an issue with the CSS or browsers, I don't know, but IMO we shouldn't discuss that here. BTW, thanks for your interest in improving the guidelines, WhatamIdoing, and for all your updates, Butwhatdoiknow. Cheers, —[[User:Suruena|surueña]] 20:54, 24 August 2008 (UTC) |
|||
::::I imagine that [[WP:ACCESS]] doesn't ''intend'' to demand that all navboxes appear in the lead, but it fails to provide for any alternatives. Compliance with this guideline is mandatory at FAC, so we really need it to authorize all of the possibilities (or to explicitly limit itself to the specific instances that it means to control). [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 22:11, 24 August 2008 (UTC) |
|||
::::: I think this is the part that is missed: |
|||
:::::* When the optional elements are used they should be in the following order: |
|||
::::: It doesn't demand those items be in the lead; it says when they are in the lead, they should be in that order. That doesn't contradict, in my mind, the navbox guideline at [[WP:LAYOUT]] (which has navboxes at the end of the article), but I agree that we need more clarity here. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 22:25, 24 August 2008 (UTC) |
|||
::::::Yes, a clarification can improve the wording here. Please, note that when I wrote that guideline what I had in mind was articles with up to 1 infobox, and one vertical navbox (both usually at the top) —and zero, one or several horizontal navboxes at the bottom— which was the common practice. But now it is very common to have more than one vertical navbox in an article, so this guideline should also recommend what to do with vertical navboxes placed outside the lead section (as Graham says below, they should be placed at the end of any section, just before another heading to be able to skip the navbox quickly to that heading). —[[User:Suruena|surueña]] 09:14, 25 August 2008 (UTC) |
|||
=== White space === |
|||
This is coming up more often now that I'm watching for it at [[WP:FAC]], so I could use more guidance. When an infobox is very very very long, placing a vertical navigational box below the text in the lead results in an extreme amount of white space. So, editors have been placing the navbox under the infobox. This is a no-no per the guideline and for screenreaders. But I can't move it to the end of the text in the lead because it creates massive white space. And I can't move them to the end of the article because they are vertical templates and don't work well at the bottom of the article, where they belong according to [[WP:LAYOUT]]. Does ACCESSIBILITY on screen readers have any opinion on placing a vertical templates somewhere in a section in the middle of the article, below the lead? See the issues in my recent edits, trying to fix [[AMX-30E]]. I don't know how to solve that navbox, and the article nominator is questioning on my talk page what to do. [http://en.wikipedia.org/enwiki/w/index.php?title=AMX-30E&oldid=233553578 This is the version before] I moved the navbox down. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 21:04, 24 August 2008 (UTC) |
|||
:The main problem I have with navboxes is moving past them to the rest of the article. I prefer them at the very end of the article for that reason, but before the TOC or at the end of a section is fine, because I can navigate past them by navigating to the next heading. '''[[User:Graham87|Graham]]'''<font color="green">[[User talk:Graham87|87]]</font> 00:57, 25 August 2008 (UTC) |
|||
::Is it just as easy to skip over the infoboxes? Why should an infobox go first, but a "sidebar" navbox be last in the lead? [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 07:14, 25 August 2008 (UTC) |
|||
:::Well, the idea is that whereas a navbox is a very long collection of links to related articles, and therefore many people are not interested at first in them, in theory an infobox is a brief summary of the article so you are interested in reading it before the lead. But maybe that assumption is wrong. What do you think, Graham? Do you usually read whole infoboxes, or do you skip them often? Can you skip to the lead section easily? In that case, maybe the infobox should be placed below the lead and the vertical navboxes below other sections. Cheers, —[[User:Suruena|surueña]] 09:14, 25 August 2008 (UTC) |
|||
:::: I just experimented with placing an infobox below the lead text, and I don't think that is something that the community would accept. It's unsightly. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 16:13, 25 August 2008 (UTC) |
|||
:SandyGeorgia, after seeing your fixes to [[AMX-30E]] I understand your point now. It's true, that special kind of navboxes relying in the {{tl|FixBunching}} template are an accessibility problem: they are designed to be placed just below infoboxes, and if you try to move them below the lead section the whole (graphic) layout will be broken (see [http://en.wikipedia.org/enwiki/w/index.php?title=AMX-30E&oldid=234107070]). I think that your decision of moving that navbox to the bottom of the article was the correct one, but those navboxes are designed to be placed below the infobox so we must find a solution and inform the authors of those infoboxes about the accessibility problems. Anyone with enough CSS knowledge to avoid breaking the layout when placing the infobox above the lead and those navboxes below the lead section? I will ask in [[Template talk:FixBunching]]... —[[User:Suruena|surueña]] 09:59, 25 August 2008 (UTC) |
|||
:: Thanks ! But if I understand correctly, you're saying it's also possible to place a vertical navbox below the text in any other section in the middle of the article? [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 16:13, 25 August 2008 (UTC) |
|||
== Also (more navbox) == |
|||
The text currently says: "Navigational boxes should be just after the lead section so a Wikipedian using a screen reader can jump to the table of contents without reading the whole navigational text." |
|||
What does this mean? "Please put a long list of articles before the table of contents, so we can find the table of contents more easily"? I thought that the entire point was to put the long list of articles before the TOC so that the reader could conveniently skip the rest of the article and go to a more interesting one, without having to skip to ''See also'' or end-of-article templates first. |
|||
If someone can explain to me the actual goal here, then I'll happily help wordsmith the rule. [[User:WhatamIdoing|WhatamIdoing]] ([[User talk:WhatamIdoing|talk]]) 22:19, 24 August 2008 (UTC) |
|||
:I don't know, but it's easy to get to the table of contents because it's a second-level heading. '''[[User:Graham87|Graham]]'''<font color="green">[[User talk:Graham87|87]]</font> 00:59, 25 August 2008 (UTC) |
|||
:: Graham, is a navbox at the end of a section in the middle of an article a problem? Some vertical navboxes don't lend themselves well to being placed at the bottom of an article. [[User:SandyGeorgia|Sandy<font color="green">Georgia</font>]] ([[User talk:SandyGeorgia|Talk]]) 01:26, 25 August 2008 (UTC) |
|||
:::No, it's not. The idea is that an screen reader or a text browser a web page is serialized, so the goal is to be able to read in a logical order the article. Many articles have a dadlink and an illustrative image and caption at the top, for example. If the article has first the image and then the dablink, in a graphic browser it doesn't care much, but a screen reader would read first the image's caption, which is part of the article's contents, and after that will "jump" outside the article to read the dablink (and after that the lead section again). That's illogical, and can be a big problem to wikipedians with learning disabilities (well, that was I think, I haven't performed any experiment). The good organization is to first hear the dablink, then the image caption, and finally the lead (if after hearing the caption or the lead you realize that's not the article you are looking for, you can just jump to the top of the article again and click on the dablink). In the case of a navbox, the idea is that probably you don't want to hear the complete list of related articles, so you can just jump to the next heading (including the table of contents, which have an h2 header). If there is text between the navbox and the next heading (e.g. the whole lead section), you would miss that part of the article. But it doesn't matter if the navbox is just before the TOC or another heading, but the usual practice is to put them at the top of the article. I hope this can clarify the goals :-) Cheers, —[[User:Suruena|surueña]] 09:32, 25 August 2008 (UTC) |
|||
=== Special cases === |
|||
Some short articles have a very long vertical navbox, but they have so few sections that they don't even have a TOC. Therefore, the navbox cannot be place below the lead section (see for example [http://en.wikipedia.org/enwiki/w/index.php?title=History_of_agricultural_science&oldid=212816076], and [http://en.wikipedia.org/enwiki/w/index.php?title=Reverse_Address_Resolution_Protocol&oldid=232971194]). So either we have to make here an exception, allowing the navbox above the lead section, or either disallow completely the long navbox (just a link to the main article in the see also section). Opinions? —[[User:Suruena|surueña]] 10:24, 25 August 2008 (UTC) |
|||
== How I navigate pages with JAWS and my thoughts on navboxes == |
|||
I can't find a good place to fit this reply, so I've created a new section for it. My screen reader [[JAWS (screen reader)|JAWS]] uses quick navigation keys that can jump to the next HTML element of a specific type, get out of the current HTML element or go to the next different HTML element. Other modern Windows screen readers, including the free [[NonVisual Desktop Access]], use a similar scheme. In JAWS, to get out of infoboxes, I press the ">" key to move to the end of the table, and to move to the TOC from the lead section, I press "H" to move to the next heading (as the TOC is a level 2 heading). My problem with navboxes is that there's no way to reliably get out of them by jumping past HTML elements. I usually use the "n" key (move to the next non-linked text block), but that usually gets me to the wrong place. Otherwise, it helps if navboxes are either at the end of an article or close to another HTML element (a heading, a table, etc). Here's a [http://www.freedomscientific.com/fs_products/JAWSKeystrokes.asp full list of JAWS keystrokes including Internet keystrokes]. |
|||
:And what about infoboxes? Do you usally skip them, or are a good summary of the article? —[[User:Suruena|surueña]] 14:51, 25 August 2008 (UTC) |
Latest revision as of 17:34, 7 December 2024
Please place new discussions at the bottom of the talk page. |
This is the talk page for discussing improvements to the Manual of Style/Accessibility page. |
|
Archives: Index, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17Auto-archiving period: 3 months ![]() |
![]() | This project page does not require a rating on Wikipedia's content assessment scale. It is of interest to the following WikiProjects: | ||||||||||||||||||||||||||||||
|
are there any acceptable uses for the HTML line break <br/>
? on a recent edit of mine, I substituted a {{ubl}} template into the HTML line break, as this was not being used for a list but as a visual break for the default size, separating the series title from the year in a table, for visual harmony.
I have seen this sort of visual break in many articles that I have edited, especially less cared ones, but how should it be handled? is it COMPLETELY discouraged it, even for use cases where there is legitemately no factor other than aesthetics or what to do instead? Juwan (talk) 12:21, 19 September 2024 (UTC)
- Not to hock my own slogan, but essentially as I understand it, break means pause. That is to say, line breaks are acceptable when they actually represent semantic breaks in content, perhaps roughly equivalent to a paragraph break. They should neither be used to create the appearance of lists nor to manually wrap a single block of text, but beyond that there are actually plenty of plausible applications. Infobox templates themselves actually use them a lot under the hood. Remsense ‥ 论 12:24, 19 September 2024 (UTC)
- oh, that's actually a great essay! if you think it is appropriate please link it on the section, that's exactly what I was looking for. Juwan (talk) 12:49, 19 September 2024 (UTC)
- It's incomplete at the moment, and I like the idea that others would link such things rather than me if they find it useful so that only useful things get linked, so if you think it would help others then go for it! Remsense ‥ 论 12:56, 19 September 2024 (UTC)
- oh, that's actually a great essay! if you think it is appropriate please link it on the section, that's exactly what I was looking for. Juwan (talk) 12:49, 19 September 2024 (UTC)
- Line breaks are for visual appearance only, and so semantically they are equivalent to whitespace. Appropriate semantic markup should be used as applicable. Line breaks should be used sparingly. As browser widths change or other elements are added to the page, the page will automatically be laid out differently by browsers, and manual overrides can work against this process producing a pleasing result. isaacl (talk) 18:40, 19 September 2024 (UTC)
Where to place accessibility templates on problem templates
[edit]The section on color suggests placing the {{Overcolored}} template at the top of articles with contrast issues. What about templates. For example, the {{Transport in Mexico City}} template has major issues with contrast. But if I place the template at the top of the template itself, it will appear on dozens of pages, which would be disruptive. I wound up placing it on the Transport in Mexico City template talk page at the top of my topic.
It would be good to clarify this in the text as to where it would best be placed in templates.
Thisisnotatest (talk) 06:14, 26 September 2024 (UTC)
- I would put it on the doc page as well. If there's not a maintenance category for templates with accessibility issues, maybe it should be created and populated! I would personally appreciate that. Remsense ‥ 论 07:04, 26 September 2024 (UTC)
- Place it in the template, either in the documentation, or if it doesn't, then at the bottom between the noinclude tags. Gonnym (talk) 08:31, 26 September 2024 (UTC)
- Thank you! I've moved it to the template documentation as well as added it to a related template. That's what I will do moving forward. Thisisnotatest (talk) 07:21, 27 September 2024 (UTC)
Looping GIFs and accessibility
[edit]My edit Animations: Clarified 5 seconds as total playing time was reverted by Remsense with the comment "This is confusing to me: are looping GIFs simply not allowed?"
Rather than risking getting into an edit war, I am moving the matter here to attempt to gain consensus on wording before proposing a final edit.
WCAG 2.1 provides Technique G152: Setting animated gif images to stop blinking after n cycles (within 5 seconds)
Looping GIFs are permitted as long as they stop looping such that the total animation time is 5.0 seconds or less. So:
- A 1 second long animated GIF could loop 5 times
- A 1.5 second long animated GIF could loop 3 times
- A 2 or 2.5 second long animated GIF could only loop twice
- A 3 second long animated GIF could not loop at all
- Endlessly looping animated GIFs are not permitted at all
Hope that makes it clear (which I believe the current page wording does not do).
Thisisnotatest (talk) 07:11, 27 September 2024 (UTC)
- Suffice it to say, this does require conversation as almost no one operates based on this understanding, even if it's well-founded. Remsense ‥ 论 07:13, 27 September 2024 (UTC)
- From what I understand, and I'm woefully underread in the literature so this is partially anecdotal so forgive me, there is a significant distinction in accessibility between short animations that loop and long animations. SC 2.2.2: Pause, Stop, Hide says
“ |
|
” |
- The operative sentence uses the word "blinking" in a manner I find to be a bit vague: I would intuit some distinction many people would perceive between "blinking", merely "looping", and "ongoing" animated content in terms of its potential to interfere with their ability to focus or comfortably read? Later, "blinking" is defined as "content that causes a distraction problem", which is unfortunately a bit circular for our purposes. If blinking is coterminous with moving, why isn't moving used? Remsense ‥ 论 07:22, 27 September 2024 (UTC)
- As I understood it at the time that the HTML BLINK element was first deprecated, it's because certain blink rates can trigger seizures. I've never heard of a looped animation doing that, unless the animation is essentially two images displayed alternately. --Redrose64 🌹 (talk) 08:20, 27 September 2024 (UTC)
- It doesn't only say blinking, it also says moving or scrolling. The area of concern is "The intent of this Success Criterion is to avoid distracting users during their interaction with a Web page." Long form animations need to be done via a pauseable video rather than by an uncontrollable animated GIF. Thisisnotatest (talk) 09:57, 27 September 2024 (UTC)
- I'm just trying to fully understand what SC 2.2.2 says and why. Most concretely, it says:
- Content that moves or auto-updates can be a barrier to anyone who has trouble reading stationary text quickly as well as anyone who has trouble tracking moving objects. It can also cause problems for screen readers.
- Moving content can also be a severe distraction for some people. Certain groups, particularly those with attention deficit disorders, find blinking content distracting, making it difficult for them to concentrate on other parts of the Web page.
- The first point is about moving content in general, and doesn't really apply to our conversation about looping GIFs in particular. The second specifically discusses blinking content, which is the distinction I'm currently unclear about. Remsense ‥ 论 10:04, 27 September 2024 (UTC)
- I do find it odd that they seem to focus on blinking so much. The issue is that if anything on my screen is animating when I am trying to read some other content on the page, then I will have difficulty concentrating on that other content. It doesn't matter whether the animated content is blinking or showing how an oil rig operates. If I have no way to stop it, I can't focus on the content that I'm interested in focusing on.
- I've seen reports of usability tests where people will hold their hand up to obscure the unstoppable animation, and I've done that too. That assumes an abled person who can hold their hand up for an extended period of time; someone who is both attention challenged and arm-mobility disabled would not have that workaround. It still would take some of their/my attention away from trying to absorb the content of interest. And it's making the site visitor adapt to the site rather than the site adapting to the visitor. Hope that makes it clear. Thisisnotatest (talk) 23:51, 29 September 2024 (UTC)
- Certainly. As I admitted, my previous understanding was based partially on my own anecdotal experience, where I can only recall those in my life having spoken about an inability to focus amid stimulus I would have characterized as "blinking" or "ongoing" above, rather than "looping". Of course, I don't doubt at all that the problem would cover that area also—there was just enough of a question in my mind that I felt it appropriate to make explicit.
- General question I may cross-post to WP:VPT: what feasibility would there be in building a tool that can help us accomplish this task? It would seem to require transcoding every GIF on a live page to a video—there's no real advantage to using GIFs at all, right? Remsense ‥ 论 23:58, 29 September 2024 (UTC)
- I'm just trying to fully understand what SC 2.2.2 says and why. Most concretely, it says:
- The operative sentence uses the word "blinking" in a manner I find to be a bit vague: I would intuit some distinction many people would perceive between "blinking", merely "looping", and "ongoing" animated content in terms of its potential to interfere with their ability to focus or comfortably read? Later, "blinking" is defined as "content that causes a distraction problem", which is unfortunately a bit circular for our purposes. If blinking is coterminous with moving, why isn't moving used? Remsense ‥ 论 07:22, 27 September 2024 (UTC)
Do we need to call out team and transit colors under color?
[edit]I notice a lot of issues on Wikipedia where text has contrast issues because someone has duplicated team or transit route colors. Do we want to specifically mention that using team and transit colors for text is not exempt from meeting contrast requirements, and that accessibility takes precedence over non-logo branding?
Team example
- Geelong West Giants uses white text on a orange background extensively. Orange text or backgrounds are particularly problematic because white on orange fails WCAG 2.x contrast test, but some people find orange on black harder to read. The logo doesn't need to meet contrast, but text does. The best practice would likely be to abandon the orange background.
- The color #FFFFFF (white) on #F15C22 (orange) has a contrast of 3.33:1, which fails for text smaller than 18.66px bold or 24px not bold.
Transit example
- {{Transport in Mexico City}} themes colors by route and mode. Several of the routes use insufficient contrast, such as Cablebús line 1, which has white on light blue, which violates contrast at all sizes.
- The color #FFFFFF (white) on #4EC3E0 (light blue) has a contrast of 2.05:1, which fails for text at all sizes. This issue is complicated that the icon is supplied by the government of Mexico City, but the license permits modification, such as making the "1" black instead of white (changing
fill="#FFFFFF"
tofill="#000000"
in the SVG code). But it might be simpler and less distracting to use actual text rather than an SVG image.
Thisisnotatest (talk) 21:24, 27 September 2024 (UTC)
- These colors have always been horrible, and not only for accessibility reasons. Look at Template:Geelong Football League, the hyperlink in title is completely hidden. Gonnym (talk) 21:32, 27 September 2024 (UTC)
- Many years ago, the ice hockey WikiProject moved to using colour borders instead of colour backgrounds in order to improve accessibility (including legibility). See Template:Montreal Canadiens for an example. (Some ice hockey editors don't like how it looks, while others do, but the consensus has held.) I feel this approach is a reasonable tradeoff between visual design goals, and should be considered for other similar scenarios. isaacl (talk) 16:22, 28 September 2024 (UTC)
- I don't see the point of it. It's a digression. I mean, I guess the people doing it think it adds a coolness factor, but this isn't TikTok. We aren't here to be cool, and we're here to be informative, and coolness is a distraction from that.
- When we have a list of the names of fruits, we don't precede each one by an icon depicting the fruit. List of typefaces (thank the forces that be) doesn't display the name of each typeface in that typeface. But some people, when they create or see a list of countries, they feel the impulse to prefix each name with the country's flag, as though every mention of a country merits another reminder to the reader of what that country's flag looks like. This situation is the same. It's an encyclopedia, not a font catalog or sports journal or score sheet. Identify typefaces, countries, routes, teams, etc., by name, without decoration. And not only do the color embellishments serve no useful purpose but, as you note, they break accessibility. Largoplazo (talk) 17:13, 28 September 2024 (UTC)
- Funny enough, I'd much rather List of typefaces show examples of how each typeface looks like (and I actually do believe that is informative), than see another list with a country flag in it. Gonnym (talk) 10:27, 29 September 2024 (UTC)
- So what is the path forward for this?
- How do we get consensus to move all sports templates to the ice hockey model? Do we need a bot to make this edit, given that hundreds of pages are involved? Further, some of this styling has carried over to section headings in the manually edited content, for instance the table headings on Geelong West Giants.
- And what would be a solution for transit? I'm happy to go in to, say, {{New York City Subway}} and replace all the icons with text. (I did check the history and there is no mention of "accessibility" or "contrast" in any of the revisions.) I suppose I could be bold and see what happens, but without specific advice here on Wikipedia:Manual of Style/Accessibility I don't feel I have the concrete advice to back me up. I don't want to get into an edit war.
- I suggest adding the following text to Wikipedia:Manual of Style/Accessibility:
- Do not use logos or themed colors in place of default-color text links. They can keep people with low vision who don't use screen readers from being able to read the link, and can cause concentration issues for people with cognitive disabilities.
- Thisisnotatest (talk) 23:36, 29 September 2024 (UTC)
Further, when non-white background colors are used, it can interfere with being able to see whether a link underline indicates the linked page does or does not exist. Actually, it can interfere with being able to see the link underline at all. Thisisnotatest (talk) 04:58, 1 October 2024 (UTC)
- Also noticing templates where the title bar text is over a background gradient, where once of the background colors would properly take white text and the other one would properly take black text, making it impossible to choose an accessible text color that works with both. For example, {{MARTA Red and Gold lines}}, {{MARTA Blue and Green lines}}, and {{Richmond station (California)}}. Thisisnotatest (talk) 22:34, 4 October 2024 (UTC)
RfC partly concerning vision accessibility
[edit] You are invited to join the discussion at Wikipedia talk:Manual of Style/Linking § RfC: Linking of three-part place names. -- Tamzin[cetacean needed] (they|xe) 20:59, 17 October 2024 (UTC)
What to do about flashing images
[edit]MOS:ANIMATION: In addition, animations must not produce more than three flashes in any one-second period. Content that flashes more than that limit is known to cause seizures.[14]
Let's say there's an animated image in several articles with rapid blinking, well exceeding 3 f/s. And, let's say it's effectively impossible to illustrate the thing it illustrates, w/out rapid blinking. Is the right thing to do, just remove the image then? Photosensitivity Warning: Thinking of File:Strobe 2.gif. Looking at that thing gives me a headache. --Slowking Man (talk) 21:56, 21 October 2024 (UTC)
Concerns with MOS:PSEUDOHEAD
[edit]Going to say my piece here before being bold and seeing if others agree. The "acceptable" way of PSEUDOHEAD, shouldn't be an "acceptable" method. It's still pseudohead and is very manipulated by the community. Countless articles I have seen have dodged the use of headers by using bold markup instead which is pretty stupid, in my opinion. Maybe changing the language to make sure that people understand that it is ONLY to be used for when {{TOC limit}} can't be used. Right now, if I was an editor who never saw it. I'd see the acceptable way of using it and then just go ahead and use it, no questions. Or even get rid of the acceptable way and make it incorrect and tell people to suck it up. Cowboygilbert - (talk) ♥ 19:49, 31 October 2024 (UTC)
- I would go further: if you're running into situations where you're struggling with
{{TOC limit}}
, there's almost certainly something wrong with how you're structuring the article. Even the heftiest prose articles rarely need level-4 headings and frankly should never use level-5 headings. I'm willing to go out on a limb and say the same is the case for list articles unless someone can show me a counterexample. Remsense ‥ 论 19:53, 31 October 2024 (UTC)- I did see an issue with {{TOC limit}} is that you need to have nested-headers when doing lvl 4 or lvl 5. So it MUST follow a level 3 header. So you can't do:
== Header ==
so you have to do:
==== Small header====== Header ==
Which could be fixed with fixing the TOC limit template code but I am not a template editor. Cowboygilbert - (talk) ♥ 19:57, 31 October 2024 (UTC)
=== Small-ish header ===
==== Small header ====- I'm not quite understanding how this is an issue, unless it's that other editors would like to skip to smaller font sizes or more granular divisions. I would reiterate what I said above: it seems almost certain to me that if an editor finds themselves wanting this, they should consider whether they're doing something idiosyncratic or unnecessary. Remsense ‥ 论 20:01, 31 October 2024 (UTC)
- I saw it happen on Chromakopia while fixing it's PSEUDOHEAD. It has lvl 2 headers and then lvl 4 headers, but you can't limit lvl 3 because there are other sections that need to show on the TOC. (i did have to google idiosyncratic btw) But on articles where I mainly see it, which is in Category:Production discographies, they aren't an issue because it's usually a lvl 2 followed by a lvl 3 header. Cowboygilbert - (talk) ♥ 20:04, 31 October 2024 (UTC)
- My point is that one should never have to skip levels: usually, the better solution is either to omit the granular lower-level headings as unnecessary, or be less dogmatic about the scope of higher-level headings (for example, sections that relate the narrative of a historical event shouldn't be stuffed under a top-level "History" section, like my least favorite LTA and many others feel the need to do). Remsense ‥ 论 20:10, 31 October 2024 (UTC)
- MOS:GOODHEAD is clear:
Nest headings sequentially, starting with level 2 (
--Redrose64 🌹 (talk) 00:04, 1 November 2024 (UTC)==
), then level 3 (===
) and so on. (Level 1 is the auto-generated page title.) Do not skip parts of the sequence- I suppose I would echo Gil's question here: what is the expected use case for pseudoheaders when formatted correctly? Remsense ‥ 论 02:09, 1 November 2024 (UTC)
- MOS:GOODHEAD is clear:
- My point is that one should never have to skip levels: usually, the better solution is either to omit the granular lower-level headings as unnecessary, or be less dogmatic about the scope of higher-level headings (for example, sections that relate the narrative of a historical event shouldn't be stuffed under a top-level "History" section, like my least favorite LTA and many others feel the need to do). Remsense ‥ 论 20:10, 31 October 2024 (UTC)
- I saw it happen on Chromakopia while fixing it's PSEUDOHEAD. It has lvl 2 headers and then lvl 4 headers, but you can't limit lvl 3 because there are other sections that need to show on the TOC. (i did have to google idiosyncratic btw) But on articles where I mainly see it, which is in Category:Production discographies, they aren't an issue because it's usually a lvl 2 followed by a lvl 3 header. Cowboygilbert - (talk) ♥ 20:04, 31 October 2024 (UTC)
- I'm not quite understanding how this is an issue, unless it's that other editors would like to skip to smaller font sizes or more granular divisions. I would reiterate what I said above: it seems almost certain to me that if an editor finds themselves wanting this, they should consider whether they're doing something idiosyncratic or unnecessary. Remsense ‥ 论 20:01, 31 October 2024 (UTC)
- I did see an issue with {{TOC limit}} is that you need to have nested-headers when doing lvl 4 or lvl 5. So it MUST follow a level 3 header. So you can't do: