This page 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. |
Hi folks, and @ Graham87: in particular. I was wondering if I could get some input on this bug ticket, regarding the usage of tabIndex, especially when it comes to the sidebar collapsibles. In my opinion, we might as well set them to 0 now that the rest of the section has been elevated to be under an H2. — TheDJ ( talk • contribs) 09:48, 1 June 2013 (UTC)
Much of this page pertains directly to articles, but could just as easily apply to project pages or Talk pages. What is its scope? Where should it apply, and where should it not? Is there a limit? Personally, I think the scope should be as wide as possible, and the site should be universally accessible to everyone. But some editors clearly disagree with my take, so I’d like to hear theirs, free of all of the above drama. And obviously, if it applies to Talk pages, any edits to anyone else’s comments would be governed by WP:TPO. — Frungi ( talk) 06:45, 1 June 2013 (UTC) edited 19:38, 10 June 2013 (UTC)
Articles Only, But... I do think we should and must encourage accessibility across the entire encyclopedia, articles, talk pages, project pages, etc. However, I don't believe that a broad mandate across all those spaces fits within the Manual of Style, which is pretty exclusively dedicated to the article space. It may be worth considering promoting this section outside of the Manual of Style, but I really do have some concern about pushing the Manual of Style outside of article space. -- j⚛e decker talk 22:47, 2 June 2013 (UTC)
Article space only unless explicit. Some of the guidelines should apply to all pages. However, the one we are talking about (elsewhere on this talk page; technically not here) detracts from readability and editability by sighted, but possibly otherwise disabled, readers and editors. I would have to ask Graham whether the blank lines make it easier for a blind editor to, well, edit the talk page, but I agree that the "Wall of text" could be, and in fact, has been, a problem for me. (Note that I'm violating the guideline here, as I've started a new list.) — Arthur Rubin (talk) 13:39, 3 June 2013 (UTC)
<div>
s or something would make much more sense. I’m not sure how the nesting could be implemented for screen readers, though. Still a bit off topic here, but is there anything we can do about that beyond Bugzilla (or just waiting for a new system)? This bug (
T6521) is six and a half years old. —
Frungi (
talk)
15:12, 3 June 2013 (UTC)Article space only However its use can be encouraged elsewhere and any accessibility solutions should be consistent with it. WP:TALK and Help:Using talk pages are the right places to put things about talk pages and if there is a common accessibility problem in talk pages then that is the place for a guideline about it even if just a short description of the problem with the usual solutions and a link to a section here about it. Dmcq ( talk) 14:02, 3 June 2013 (UTC)
Everywhere: Whatever arguments are adduced in support of accessibility considerations for those reading articles apply with exactly the same reasoning to all other pages on Wikipedia. That is assuming that disabled readers are just as welcome on other pages - and I've seen no arguments contradicting that view yet. -- RexxS ( talk) 16:05, 3 June 2013 (UTC)
Everywhere but it won't be mandatory for talk pages rather than for articles. It would be a guideline for talk pages, maybe like a how-to. Ramaksoud2000 ( Talk to me) 01:46, 4 June 2013 (UTC)
I have a concern. Recently, several editors who are involved in this RfC were involved in a failed attempt to expand the accessibility guidelines that were specifically written for Wikimarkup lists so that they apply to all talk pages, arguing that the talk page you are reading right now is really a list, the comment you just wrote is really a list item, and thus the guideline that was written to apply to Wikimarkup lists applies to your talk page comments. Now I do not want to re-hash the merits of that argument in another place, but I am concerned that votes that agree with statements like "the scope should be as wide as possible" and "this guideline should be applied everywhere" might not be interpreted as meaning "the guideline on lists should apply to lists on articles, lists on talk pages, lists on template pages, etc." but rather "the guideline on lists should apply to lists, talk page comments, and various other elements to be specified later." Now I could very well be completely wrong on this, and there might not be anything to be concerned about, but if enough people vote for "apply the guidelines everywhere" and if such a result is interpreted the way I think it will be, then we are going to end up having Yet Another Battle, this time over whether those who voted on this RfC knew what they were voting for. -- Guy Macon ( talk) 02:47, 4 June 2013 (UTC)
Request to all participants in this RfC: Let's not yet discuss the specifics of how any particular part of the guideline may or may not apply to any particular quirk of the software outside of article pages. It's simply a waste of time while it's unclear whether the guideline applies outside of article pages, and muddies up the discussion. — Frungi ( talk) 13:51, 4 June 2013 (UTC)
Everywhere, but of course within reason. We want all users to be able to read all the pages. we don't want to tell some users that their participation is unwelcome or should be needlessly painful. This statement is true regardless of whether the issue is quietly indenting the newbie's comments with the correct number of colons (which we do hundreds of times a day, without anyone getting upset) or quietly removing blank lines that slow down the page for people using screen readers. This statement is true regardless of whether the question is an AFD or a talk page or an article. Everyone should be welcome everywhere, not just in articles. We don't have to be nasty about any of this, and it doesn't have to be "important" or take time away from article writing, but we should fix it when it when we run across it, or at least not object to other people fixing such problems. (In fact, the ideal solution to the LISTGAP problem on talk pages IMO is to have the archiving bots fix it. They're already removing stray blank lines after section headings.) WhatamIdoing ( talk) 19:10, 6 June 2013 (UTC)
off-topic replies by Dmcq and Frungi hidden by Frungi
|
---|
|
<pre>...</pre>
block due to an unintentional leading space. I’m with WAID: I don’t see how this is anything new. There’s already plenty of opportunity to screw up in trivial ways that are easily fixed. Likewise, there are countless wrong ways to “fix” these errors, mostly by drawing unnecessary attention to them—we don’t fix a newbie’s colon count with an edit summary of, “editor was violating
WP:INDENT; corrected and left a stern warning on his Talk.” That kind of nonsense would be unacceptable, and there’s no reason that it would be any more likely to happen with LISTGAP or any other accessibility-related matters. —
Frungi (
talk)
22:36, 9 June 2013 (UTC)
TPO has said that list markup can be corrected for months now. See the item that begins "Fixing format errors that render material difficult to read" (and, if necessary, take particular notice that it's not just "renders material difficult to read for sighted readers"). Fixing list markup was explicitly added about six months ago, but the general concept has been there for years. There was no objection to this fixing other people's lists— I've done it hundreds of times without a single complaint—until Guy and Walter discovered that indented threads are technically lists (something I hadn't realized until this dispute, either), and decided that the presence or absence of blank lines in a discussion at [[Template talk:Track listing] was critically important. WhatamIdoing ( talk) 19:53, 10 June 2013 (UTC)
(This cross-post is identical to the note at the WikiProject Accessibility page.)
The WP:VisualEditor is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka WYSIWYG), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013.
A couple thousand editors have tried out the early test versions so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will not be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that WP:Flow is ultimately supposed to deal with talk pages).
The developers are asking editors like you to join the alpha testing for the VisualEditor. This is especially important for people who deal with accessibility, because it always takes a while to write, test, and deploy code—so it's important to get any major problems on the list sooner rather than later. Please go to Special:Preferences#mw-prefsection-editing and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section [Edit] buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the top of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note Wikipedia:VisualEditor/Feedback about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar.
Also, the screenshots and instructions for basic editing will need to be completely updated. The old edit window is not going away, so help pages will likely need to cover both the old and the new. The WMF is committed to this long-requested improvement, and it's my impression that nothing short of a complete collapse of the servers will cause it to be reversed, so we need information that will help them get it right. The new editing system will become the default, not the only option.
If you have any other questions and can't find a better place to ask them, then please feel free to leave a message on my user talk page, and perhaps together we'll be able to figure it out. Thanks, WhatamIdoing ( talk) 01:08, 7 June 2013 (UTC)
Currently, the guideline reads "If a space is needed, insert an extra line consisting of the same number of colons.", please look at the wikimarkup for the following tests in your editing window and then look at the HTML source:
TEST A
Comment (level 0)
Comment (level 0)
TEST B
Comment (level 0)
Comment (level 0)
TEST C
Comment (level 0)
Comment (level 0)
TEST D
Comment (level 0)
Comment (level 0)
As expected, test D is far worse than A, B, or C, but it turns out that it matters whether "the same number of colons" means the same number as the comment above or below. TEST C renders to the same HTML as TEST A, BUT TEST B does not. IMO, if we are going to tell people how to tweak the wikimarkup so that it produces a particular HTML rendering, exactly how they should do this should be clarified, with examples.
BTW, I really like the lines with colons idea, and am going to start doing it that way (test C) in my posts. -- Guy Macon ( talk) 21:21, 10 June 2013 (UTC)
Hi, please see this discussion at WikiProject Military history. We wish to style the † symbol properly, in a way that looks more like the 2nd or 5th example in - the default sans-serif version (†) usually looks like the 1st example, which has caused many problems and raised various questions. Please reply there (to keep everything centralized), with suggestions on how to best implement this, and if it is possible to achieve high-percentage reliable styling across browsers. (I've not kept up-to-date with CSS over the last few years, but my tests can be seen a few replies down, in the thread). Much thanks.
what's the consensus on this sort of thing? I reverted as possibly problematic, but could use some additional feedback, especially if I am wrong about it being a problem. I, personally, find plain text easier to read, and image maps better for inclusion in articles where the information is also presented in plain text. Frietjes ( talk) 21:01, 14 June 2013 (UTC)
When a single source is cited multiple times in the same article, getting back from the references section to the right section of prose requires guesswork. This is (imo) a bad thing and I have prosed to change it.
For a detailed explanation see Wikipedia:Village pump (technical)#Multiple references to the same source. You are invited to participate in the discussion there. Thryduulf ( talk) 00:36, 16 June 2013 (UTC)
Just a brief note: I know there are rumors floating about that all users will be required to use WP:VisualEditor when WP:Flow rolls out. None of it's true. The design for Flow has always included a fallback for users who use screen readers or don't have Javascript or otherwise cannot use VisualEditor. Even assuming that the Flow team decides to use VisualEditor (which I understand is likely, but not set in stone yet), there will be options for people who have special accessibility issues. Whatamidoing (WMF) ( talk) 04:17, 15 July 2013 (UTC)
...I present to you The Web Accessibility WCAG Theme Song. Enjoy! -- Guy Macon ( talk) 16:55, 4 June 2013 (UTC)
I was wondering about what the experience is like, for a typical regular screenreader user. Does anyone have a particularly good example video, to demonstrate to editors who are semi-familiar with screenreaders, what standard high-speed usage is like? I know Graham has mentioned skipping or clipping off the end of items, but I'm not sure what that sounds like in practice. The best two videos I've found after a while of searching youtube, are
(Note that I did watch many more videos, and there an abundance of poor quality recordings, or labored introductions to the topic aimed at non-geeks.) I'm hoping to find something right in between those two; something that demonstrates 2–5 minutes of normal use, by an advanced or smart user. Maybe even something that we could link to from the WP:ACCESS page itself. – Quiddity ( talk) 06:03, 5 June 2013 (UTC)
I was unaware of this, so I suspect many others as well. It's actually possible to use role="presentation" on tables, if they are used for presentational purposes. Considering adding this to *mbox... — TheDJ ( talk • contribs) 08:40, 13 August 2013 (UTC)
See Template talk:Flatlist#Accessibility. Frietjes ( talk) 15:54, 22 August 2013 (UTC)
I've recently done a write-up about accessibility problems on Wikipedia in the Signpost's tech report, and flowing from that, I've started a bot request discussion to fix some accessibility issues that I noted in the write-up. Any comments at the bot request discussion would be appreciated. Graham 87 05:16, 7 September 2013 (UTC)
see Template talk:Cross-Tipped Churches. Frietjes ( talk) 20:00, 16 September 2013 (UTC)
We have ...
Images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
... meanwhile, we also have ...
- Periodic table snippets for each element – no caption needed
- Images of Element samples in the element infobox – no caption needed
- Images of plants and animals, protists etc. in infoboxes – caption optional
- Infobox images with mission insignia – no caption needed, but if there is a description of the symbolism, it should be included on the image description page
- Other images (especially within infoboxes) where the purpose of the image is clearly nominative, that is, that the picture serves as the typical example of the subject of the article and offers no further information – no caption needed.
It seems that these conflicts require some arbitration (e.g. sub-clausing the WP:CAP#Special_situations items: "except where there is no WP:ALT content" – the basis upon which I acquiesced a recent revert spat, regarding music release cover-art).
Any ideas folks? I'm very interested in technology to accommodate the differently enabled (e.g. abatement of sight-impairment), but have much to learn, in terms of all the prevalent combinations of abilities and aids (e.g. screen readers). – Ian, DjScrawl ( talk) 23:07, 14 October 2013 (UTC)
Just in case anybody interested doesn't have the WikiProject page on their watchlist, see this thread about an ongoing Signpost interview with the project. Graham 87 02:34, 18 October 2013 (UTC)
Can someone explain to Ken at User_talk:Dennis_Brown#Would_you_take_a_look.3F that inserting a {{ col-break}} in the middle of a list causes a WP:LISTGAP? Thank you. 174.56.57.138 ( talk) 05:35, 18 October 2013 (UTC)
The section at WP:ACCESS#Resolution primarily deals with ensuring that users with low-resolution screens won't be hindered in their Wikipedia experience. Should the same care extend to users with high-resolution screens? For example, {{ track listing}} creates a simple table for combining multiple sets of data about a musical album's track listing (track number, track title, writing credits, lyric credits, track notes, track length, etc.). However, when the same template is only used for a few fields (just track title and track length), on a higher-resolution screen, this can cause an ungodly amount of empty space between the two sets of data in the table. And that space gets larger as the screen size increases since the table is formatted to fill the entire screen, whatever the size. Should this MOS be updated to include concerns about higher-resolution screens as well? Fezmar9 ( talk) 01:09, 28 October 2013 (UTC)
see Talk:Catalogue of Women. thank you. Frietjes ( talk) 17:27, 10 November 2013 (UTC)
WP:Manual of Style/Accessibility#Text says:
That presumably prohibits adding single line breaks to the end of sentences. The essay Wikipedia:Don't use line breaks gives pros and cons of line breaks within article source text, but despite the title does not come to a conclusion. A poll on Wikipedia talk:Don't use line breaks shows editors about equally split, maybe slightly leaning to line breaks if they are only used at the end of sentences. The main "pro" argument is that diffs are easier to follow if there are line breaks in the source text and the main "con" argument is that they make the source text look even more different from what is displayed. The essay does not discuss accessibility.
My eyesight and coordination are not great: I sometimes find it hard to position the cursor precisely using the mouse. I swap text around a lot when I am working on an article until I am satisfied with the sequence. If each sentence is followed by a line break I find it easier to select the sentence, then cut it and paste it somewhere else. I click and hold in the white space after the end of the line, pull the mouse back to the start of the sentence on the left of the edit box, then CTRL+X, CTRL+V to move it. It is harder for me to select and move text that is embedded in a line or lines because I have to position the cursor more precisely. I also prefer not to overcite. Two or three sentences may have a cite at the end of the last sentence. Before moving one of these sentences somewhere else, I have to copy the cite to the end of it too, which is easier for me with line breaks at the end of each sentence:
On the other hand line breaks, even when only placed at the end of sentences, make editing with a screen reader a bit more awkward. This seems like a trade-off between making editing a bit easier for some editors at the cost of making it a bit harder for others. I would prefer to change this statement in the guideline to:
Comments? Aymatth2 ( talk) 14:56, 6 November 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have decided to start a centralized discussion about collapsing track lists, and the effect this has on users with disabilities. Talk:Long. Live. ASAP#Collapsed sections and Talk:Music_of_the_SaGa_series#Collapsed_sections contain previous discussions about the issue which I plan to continue here. I am not sure how this discussion should be moved over here, so if someone can do that it would be appreciated. -- Jax 0677 ( talk) 00:09, 1 October 2013 (UTC)
I would like to add the following section under text:
Comments? — Edokter ( talk) — 18:03, 4 January 2014 (UTC)
<sup>
, <sub>
and reference section that use {{
Reflist}} or <references />
... Anotherwords, wherever the font size is reduced, it should be avoided to reduce even more. Bugs me to no end that some reference sections are so small that I can't read the dang thing.
Bgwhite (
talk)
19:22, 4 January 2014 (UTC)2nd draft:
I think it may be important enough to include it in both pages. — Edokter ( talk) — 20:07, 4 January 2014 (UTC)
<small>
tag and the {{
small}} template reduces text by."
Bgwhite (
talk)
07:17, 7 January 2014 (UTC)<small>...</small>
HTML tag) produces a font-size of 85% of its surrounding text. The resulting font size should not drop below 85% of the page fontsize: Text should never appear smaller then this.I've created quite a few articles on braille, using either Unicode or images. It seems rather ridiculous that the blind can't read them because braille readers can't process Unicode braille. I wouldn't mind adding brackets or something to the braille so that the blind could distinguish between linear and braille script in the articles, but how do you make the braille itself accessible? Or do we simply need to wait for braille displays to catch up? (This is also a problem elsewhere; if you email a blind person in braille, they can't read it.) — kwami ( talk) 19:43, 7 January 2014 (UTC)
Hi.
How can we have exponentiation in an accessible manner? i.e. in a manner that screen readers read 28 as "two power eight" instead of "twenty eight"?
Best regards,
Codename Lisa (
talk)
13:58, 17 January 2014 (UTC)
I've found a page titled
DUKEDOM OF GRAFTON which has severe contrast issues. The colours are set using <body text="#FF0000" bgcolor="#666633" vlink="#800080" alink="#000000">
. In case you can't get to the page, and don't know what that HTML tag does, it means that plain text is coloured like this , for a contrast ratio of 1.49; unvisited links are coloured like this , for a contrast ratio of 1.57; active links are coloured like this , for a contrast ratio of 3.51; and visited links are coloured like this , for a contrast ratio of 1.58. Perhaps we should use it as An Example of Very Bad Contrast? --
Redrose64 (
talk)
20:44, 23 January 2014 (UTC)
There's a new proposal to re-design MediaWiki's toolbar, code-named Winter; comments about it are welcome at the proposal's talk page. Here is a prototype; I have already raised a few accessibility concerns about it. Graham 87 10:30, 28 January 2014 (UTC)
Someone has just gone through Arthur C. Clarke Award, a featured list, to denote the winners with a blue ribbon icon ( ), rather than with a * character like it was before. (The colored backgrounds have always been there in addition to the mark). Is this sort of marking acceptable from an ACCESS perspective? -- Pres N 18:20, 19 March 2014 (UTC)
|alt=
parameter and set default alt text, so it should be more accessible now. Unfortunately the icon is GPL and requires attribution, so we can't suppress the link.|alt=winner
) was supplied for every occurrence. I wouldn't bother re-reverting though! Cheers --
RexxS (
talk)
20:06, 19 March 2014 (UTC)Would someone please look at Wikipedia:Administrators' noticeboard/Header, specifically the "Are you in the right place?" section? I'm not certain, but I believe that it's a table of one column and sixteen rows, each cell of which contains a one-item list. If I'm right about how that template's working, then we really ought to simplify it. WhatamIdoing ( talk) 16:53, 1 March 2014 (UTC)
I attempted to add alt-text support for the map at {{ infobox language family}} ("map" or "map2" and "mapalt" or "mapalt2"). I don't know what behaviour to expect. Is it working correctly? — kwami ( talk) 20:14, 25 March 2014 (UTC)
|mapalt
had not been set. When that happens, you need to code it in the template as {{{mapalt|}}}
. The pipe character can be read as "or default to". In other words if mapalt isn't supplied, it then returns what's to the right of the pipe - i.e. null in this case. I've
made a tiny amendment to the template to insert the pipe character to {{{mapalt}}}
and {{{mapalt2}}}
. If you purge your browser you can see that in e.g.
Austroasiatic languages there is no alt text, but in
Germanic languages (where I've added |mapalt
to the infobox) the alt text is displaying as expected. --
RexxS (
talk)
20:51, 25 March 2014 (UTC)Please see Wikipedia talk:WikiProject Accessibility#Background colours on templates for a discussion on the use of background colours in templates (such as those used to mark closed discussions) which can cause accessibility issues when various text colours are used in the discussion. It is suggested that the use of such background colours should be avoided and that this may be introduced as a guideline or even a policy. — sroc 💬 06:49, 21 April 2014 (UTC)
Though this might not be directly related if anyone wishes to weigh in on this discussion to improve accessibility at Template:Infobox album please see the discussion here Template_talk:Infobox_album#Consistancy. → Lil-℧niquԐ 1 - { Talk } - 22:02, 30 April 2014 (UTC)
Regarding this recent edit and the corresponding one at MOS:FONTSIZE, please see Wikipedia talk:Signatures#On the topic of "Appearance and color" and line-height, and post comments there. -- Redrose64 ( talk) 20:25, 26 June 2014 (UTC)
I thought that Wikipedia:Manual of Style/Accessibility#Headings (or MOS:HEAD?) used to say that having multiple, identical section headings was an accessibility issue. Is that no longer the case? WhatamIdoing ( talk) 22:51, 27 July 2014 (UTC)
can someone look at the horizontal list in Trawniki men? I tried to change it to use actual list markup, rather than images as bullet points, but was reverted. is there a different method that I am not considering? I will start a thread on the talk page as well. Frietjes ( talk) 14:12, 9 August 2014 (UTC)
A discussion pertaining to WP:COLOR is taking place at Wikipedia talk:WikiProject Tropical cyclones/Tracks#Wikipedia:Manual of Style/Accessibility#Color compliance. Feedback from knowledgeable or interested editors is welcome. -- Netoholic @ 02:00, 15 August 2014 (UTC)
Template:lang-de-AT is used in only Austrian Empire. Because no other pages use it, I'm torn between proposing deletion and leaving it alone for several years. I tried to replace the template with simple formatting, but someone reverted it and cited this guidelines as a reason. Shall we follow this guideline, or shall we consider usefulness and effectiveness of the template? -- George Ho ( talk) 23:40, 14 August 2014 (UTC)
lang-*
are often not utilized very often while others in the same series are used constantly. The less frequently needed ones are there for completeness (both for user and automated tool expectation/need). There is no principle that a template must be frequently used to be useful. A template doesn't have to make excuses for how often it's needed.
WP:DROPTHESTICK. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
03:08, 19 August 2014 (UTC)
George Ho has nominated several {{Lang-xx-YY}}
templates for deletion, despite being advised against doing so above. They are grouped together near the top of
Wikipedia:Templates for discussion/Log/2014 August 13. Some respondents there have made accessibility (e.g. screen reader) arguments regarding such templates, so participants here may be interested in those TfDs, pro or con.
See also:
Ho raised related issues in a number of other forums (most of these deal with {{lang-xx-YY}}
templates in particular, while the one at WT:NOT is more general):
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:08, 19 August 2014 (UTC)
There is no guideline to add alt text, so I propose to add the text to an accessibility icon. Examples:
84.127.80.114 ( talk) 12:23, 15 September 2014 (UTC)
any advice/help in cleaning up English translations of Homer is welcome. the lack of section headings is crazy, and the fact that the highest level table headings is all the way at the top of the article is also a mess. also, the width of the article is impossible on a narrow screen, not to mention the massive number of small tags. thank you. Frietjes ( talk) 14:16, 4 October 2014 (UTC)
Is there much/any support for these in real screen readers? I'm wondering if, for example, our code layout templates should be using style="speak-punctuation: code;"
. Also, a <dt>
template like {{
Term}} maybe should be using style="richness: 75;"
and perhaps a slight pause-before
and pause-after
. Would such tweaks actually be helpful? —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
02:21, 30 October 2014 (UTC)
I'd be interested in the accessibility arguments pro and con regarding:
E=MC²
(with Unicode character for superscript-2), E=MC²
(with HTML code for same character), E=MC²
(with character entity code for same character), E=MC{{
sup|2}}
(template), and E=MC<sup>2</sup>
(the underlying markup behind the template, using HTML superscript). These render respectively as "E=MC²", "E=MC²", "E=MC²", "E=MC2", and "E=MC2".1⅔
(with Unicode two-thirds character), 1⅔
(with HTML code for same character), {{
frac|1|2|3}}
(commonly used template), {{
sfrac|1|2|3}}
(alternative template), 1<sup>2</sup>⁄<sub>3</sub>
(the underlying markup behind both templates, using HTML superscript and subscript markup, and the character entity code for fraction-slash), 1<sup>2</sup>⁄<sub>3</sub>
(same but with Unicode fraction-slash), 1<sup>2</sup>⁄<sub>3</sub>
(same but with HTML code for the fraction-slash), plain-text 1 2/3
, and plain-text with thin-space 1 2/3
. These render respectively as "1⅔", "1⅔", "1+2⁄3", "1+2/3", "12⁄3", "12⁄3", "12⁄3", "1 2/3", and "1 2/3". [The form "1-2/3" is sometimes encountered, but too easy to interpret as "1 minus 2/3", because the hyphen (-
) is commonly used as a stand-in for the proper minus character (−
, not distinguishable from hyphen in most fonts), and has been intended to serve double-duty since the dawn of computing.]My general impression is that the Unicode characters can often be problematic, their HTML and entity code equivalents a little less so (mainly from an OS and browser support, not accessibility, point of view). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:22, 20 October 2014 (UTC)
<sup>2</sup>
.
Bgwhite (
talk)
21:57, 20 October 2014 (UTC)
&
-codes from a reader perspective (they're both bad for screen readers if the character represented isn't in ISO Latin-1's character set), other than in editing mode the &
-code version will be read out in a way that a sight-impared editor can tell what it is? This would seem to indicate that when we must use such a character, that it should be encoded, not given as bare Unicode. Exactly the opposite is the current general practice. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
01:03, 30 October 2014 (UTC)
am I the only one who finds this excessive? Frietjes ( talk) 20:38, 7 November 2014 (UTC)
At the List of Seattle bridges FLC, a question occurred to me as I was reviewing it: in List of Seattle bridges the table is using bold and/or italics to call out if a bridge is a national/city landmark. Does that work for screen readers, or does it need to be a dagger/* after the year instead? -- Pres N 03:09, 20 December 2014 (UTC)
I've reverted the bold addition of the sentence "Likewise, do not switch between list marker types (e.g. asterisks and colons), unless embedding lists starting at the highest level." partly because it was not discussed beforehand, partly because the last clause is ambiguous. -- Redrose64 ( talk) 14:43, 6 January 2015 (UTC)
*'''Keep''' because etc.
*'''Delete''' because etc.
*:Comment on vote
*::Comment on comment
*'''Merge''' with X because etc.
There was no reason for you to revert me other than "discuss before adding", which means there was no reason for you to revert me.
The wording you removed specifically allows for nesting such as in your example ("embedding lists starting at the highest level"
). The problem addressed is the broken nesting of lists, such as:
*'''Keep''' because etc.
*'''Delete''' because etc.
**Comment on vote
:::Comment on comment
*'''Merge''' with X because etc.
-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 6 January 2015 (UTC)
The link to the data table tutorial is useful, but there's no such link for layout tables. Do any examples exist anywhere? Xaxafrad ( talk) 07:27, 10 January 2015 (UTC)
The accessibility of {{ Tiny ping}} is being discussed. Please make your views known there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:37, 31 January 2015 (UTC)
Please see T18691 Section headings should have some clickable anchor for passing links, particularly my comment there. Graham 87 15:05, 1 March 2015 (UTC)
@
Graham87,
Redrose64,
Plastikspork, and
Frietjes: I add {{
paragraph break}} into articles where <p>
is used inside footnotes. It will get removed because of "no consensus", even though the template says this is for accessibility reasons. If the template is important for accessibility, can this be added to Accessibility MOS page?
Bgwhite (
talk)
23:03, 9 May 2015 (UTC)
<p>
tag. Personally I would have named it
Template:Visual break, to show it's got nothing to do with paragraphs, but that's just me. Naturally, I'd support the use of this template over raw html that carries unintended semantics with it, and I'd support adding it to MOS:ACCESS. --
RexxS (
talk)
23:19, 9 May 2015 (UTC)
<li>...</li>
element; they are not semantically paragraphs. As far as a sighted editor is concerned, bundled references display just as well using <div></div>
to force a new visual line as they would using <p>
, so for the sighted, it shouldn't really matter which is used. I suspect though that a screen reader user might be initially confused by hearing a new paragraph announced for each bundled reference - I'd defer to
Graham87 on how annoying or confusing that might be, but I'm guessing he'll tell us it's not a big deal. I do understand your concern about load times - if you recall, we discussed this about the cite templates before they were converted to Lua. However, the {{
paragraph break}} template is extremely light-weight; I just previewed this page after adding 1,000 of the templates and the increase in load time was around a fifth of a second. So I wouldn't worry about load times in this case, as I doubt any article will be using enough bundled references for anyone to notice. James will always be concerned for translations when a new template is used on en-wp, and I share his concern when many our templates now depend on Lua modules, which complicates any attempt to port them to other languages. The good news here is that {{
paragraph break}} is an extremely simple template and can be copied into any language Wikipedia without having to worry about internationalisation or dependencies. It is a slow process to improve the infrastructure of small Wikipedias - I struggle on occasion trying to help porting into the Welsh Wicipedia, without speaking Welsh! - but it's worthwhile in the long run. Has any of that been any use in providing some perspective on the issues? Cheers --
RexxS (
talk)
01:31, 10 May 2015 (UTC)<p>...</p>
.
Bgwhite (
talk)
06:17, 10 May 2015 (UTC)
<p>
for bundled references, but I don't believe it's such a vital issue that it's worth getting into conflict with other editors who, in all good-faith, don't accept that it's a net benefit. Life's too short. --
RexxS (
talk)
10:15, 10 May 2015 (UTC)
Sarah (SV)... This has nothing to do with AWB editing or the pump discussion. AWB does not add the template, close with a </p>
or remove the <p>
in these cases. AWB will only remove <p>
if it is in open text (ie not in a template or ref tags) and replace it with a blank line. I arrived at the page due to a broken bracket and a template variable being used... {{{variable|arg}}}
. This was detected by CheckWiki. CheckWiki will
detect <p>
tags in open text, but does not check for <p>
inside template or ref tags. I added {{
Paragraph break}} manually days later after the AWB edit. Doc James removed them by saying get consensus. I then asked here if this was important enough to pursue.
Yes, it would make sense to fix the problem causing this issue. It took over eight years to fix this problem that was happening inside <blockquote>
and {{
quote}} type templates. It was only fixed because of VE. There is a
T57674 ticket open on this current problem, that I commented on in 2013. When I took over maintenance of CheckWiki in ~2012 and removed CheckWiki detecting <p>
where bugs were filed. I was only made aware of {{
Paragraph break}} and also the disability reasons around 8 months ago. I do not actively look for this and only add the template when I see an "issue".
Having User:RexxS and/or Graham comment at T57674 would be helpful... They pull alot more weight. Stating the problem does cause a disability issue may help in getting it fixed sooner rather than later. Bgwhite ( talk) 23:23, 10 May 2015 (UTC)
<p>...</p>
anyway. Semantically, bundled references ought to be a list (i.e. a nested list within the overall list of references), and the best way to mark them up would be to use an unbulleted list, {{
ubl}}. That would probably be optimal for screen readers and would display acceptably for sighted users:There are eight planets orbitng the sun in our solar system. [1]
The sun is pretty big, but the moon is not so big. The sun is also quite hot. [2]
The moon is most visible at night. [3]
- ^ Miller, Edward. The Solar System. Academic Press, 1999, p. 1.
- ^
- For the sun's size, see Miller, Edward. The Sun. Academic Press, 2005, p. 1.
- For the moon's size, see Brown, Rebecca. "Size of the Moon", Scientific American, 51(78):46.
- For the sun's heat, see Smith, John. The Sun's Heat. Academic Press, 2005, p. 2.
- ^ Miller, Edward. The Moon. Academic Press, 2009, p. 17.
I don't understand the logic of enabling short ones without controls. In my experience, short ones can be worse, because they can flash more often. In my experience, the transition between the ending frame and the startying frame tends to be the painful part, the rest tends to just be distracting. 71.191.163.95 ( talk) 20:33, 28 May 2015 (UTC)
You are invited to join a discussion: Complex tables cannot be made accessible in Wikipedia and what to do about it Thisisnotatest ( talk) 21:13, 7 June 2015 (UTC)
Under the "Bulleted vertical lists" section, at the end it states, "Do not separate list items with line breaks (<br>). Use one of the following methods." Problem is, it doesn't give any following methods. Bgwhite ( talk) 23:37, 8 July 2015 (UTC)
<br>
with: {{
plainlist}}/{{
unbulleted list}} if the list is to remain vertical; or consider {{
flatlist}}/{{
hlist}} if the list could be better rendered horizontally (in-line). I'll try to clarify that. Feel free to tweak if you can improve it --
RexxS (
talk)
00:32, 9 July 2015 (UTC)More input is sought at Wikipedia talk:WikiProject Accessibility#Expert review needed. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 15:36, 18 July 2015 (UTC)
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:29, 29 July 2015 (UTC)
any suggestions about what to do about [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] ... ? Frietjes ( talk) 17:14, 26 July 2015 (UTC)
-- [[
User:Edokter]] {{
talk}}
17:28, 26 July 2015 (UTC)
Is there any reason nobody notified me ahead of time?@ Frietjes: All these are on my watch list, I didn't see any talk messages. That would have been nice. Wikipedia is full of styling, almost all navboxes for universities and other institutions of higher learning have a colored style. Below linked are examples of these. They have been this way for a long time, with no objection. I see no injury done by styling, and the styling I used was not arbitrary, each was representative of the symbols of their respective jurisdictions.
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)
I've reverted the rather WP:POINTy removal of the parenthetical wording from the colour-section's hatnote "This section is about the use of colors in articles (though the advice on contrast ratios is applicable more generally).". This, being part of WCAG, quite clealry applies to al web content, and there are incoming links from relevant discussions.
As noted at the head of the page:
The WMF's Non discrimination policy...
"is approved by the Wikimedia Foundation Board of Trustees to apply to all Wikimedia projects. It may not be circumvented, eroded, or ignored by local policies".and says:"The Wikimedia Foundation prohibits discrimination against current or prospective users... on the basis of... disability".
-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 20 September 2015 (UTC)
@ BethNaught: It's worth noting that WP:ACCESS is kind of a weird guideline because it derives its "authority" from a WMF policy that cannot be changed via local consensus. No matter what we write in the guideline itself or decide as a community, inaccessible colors cannot be used anywhere on the project where alternatives exist, as the WMF's non-discrimination policy is clear that we must make the site accessible to all potential readers whenever feasible. That policy is preceded by a statement that local consensus cannot override or erode it in any way. It's always tricky where we have WMF policies conflict with our preferred dispute resolution method, but this is an area where consensus has a much lesser role than it does elsewhere. ~ Rob Talk 07:27, 23 September 2015 (UTC)
The Text section of this project page contains the following instruction:
Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is {{ †}}; see Category:Image insertion templates for more.
However, Category:Image insertion templates appears not to have any content and in fact bears the message "Note: This category should be empty."
So how does one get a handy list of Image insertion templates? And would whoever knows please be so kind as to update that item? Or else fix Category:Image insertion templates so it shouldn't be empty and isn't, if that is the actual problem.
Thisisnotatest ( talk) 06:40, 23 September 2015 (UTC)
It is a real improvement for screen readers when we replace pseudo-headings with real headings (usually ;Notes and ;Bibliography or similar in the ==References== section, when Harvard-style referencing is used). However editors often object to the cluttering up of the Table of Contents by these relatively 'trivial' level-3 headings. Often we can't use {{ TOC limit}} because there are other, 'important', headings at level-3 that ought to be in the TOC. In such cases, the best compromise has been found to mark up the pseudo-headings as bold. This delivers the visual distinction that the editors crave, while creating a minimal annoyance to screen reader users (they can have announcing bold/italic/etc. turned off). That means the screen readers can't navigate directly to the sub-headers (nor can anyone else!) because they are not marked up as headers, which is sub-optimal, but it may be the best we can achieve when the article editor is determined to achieve a particular visual appearance. -- RexxS ( talk) 21:57, 26 September 2015 (UTC)
I believe a table such as
COL | Colonel | LT | Lieutenant | SGM | Sergeant-Major | CPL | Corporal |
---|---|---|---|---|---|---|---|
LTC | Lieutenant Colonel | 1LT | First Lieutenant | 4SG | Fourth Sergeant | PVT | Private |
MAJ | Major | 2LT | Second Lieutenant | SGT | Sergeant | QM | Quartermaster |
CPT | Captain | CNT | Cornet | 3CPL | Third Corporal | AQM | Assistant Quartermaster |
straddles between being a data table (abbreviation and value) and a layout table (using multiple columns to save space). My reading is that this is not accessible, but it's not clear from the section on layout tables whether this is the case. Could someone clarify? Thisisnotatest ( talk) 09:12, 26 September 2015 (UTC)
scope="row"
is also used for the plainrowheaders style on Wikipedia.
nyuszika7h (
talk)
20:16, 27 September 2015 (UTC)
<th>...</th>
, and yet others would give preference to a cell marked as scope="row"
. Similar issues would affect column headers. So to maximise the chance of any particular screen reader using the cell we designate as the row/column header, we give the advice to mark up the column and row headers with both '!' and 'scope'. Redundancy never makes the issues worse and usually gives the desired result, even with older software. Hope that helps. --
RexxS (
talk)
21:32, 27 September 2015 (UTC)So it looks like Jaws correctly handles scope markups. What about other readers? Anyway, thanks for the explanation on the included table; perhaps removing scope from that table is the best move? Thisisnotatest ( talk) 05:19, 28 September 2015 (UTC)
Apparently this is just a publicity contest where I'm penalized for not being able to write in English. Anyway, I'd like to make a Dab solver tool (+ WP:DPL) for alt text. Automatic colorblindness is more uncertain (keep finding mistakes in papers), but we'd have something and hopefully more resources. — Dispenser 17:06, 27 September 2015 (UTC)
Wouldn't Windows-1252 symbols be unpronouncable to Mac or Unix screen readers? Would it be better to restrict non-imaged/non-templatized symbols to Latin-1? Thisisnotatest ( talk) 21:43, 26 September 2015 (UTC)
{{†|alt=wicket keeper}}
to mark the wicket keeper. It's sometimes good to use {{
Hash-tag}} in a similar way. Cheers --
RexxS (
talk)
23:07, 26 September 2015 (UTC)
Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.
- Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
- Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
- Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
with:
Many screen readers will read most special characters as a question mark or not at all.
- Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
- Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
- Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
- Safe symbols to use without a template are any of the following: !£$%^&*()-=_+/@~#<>?\|{} as well as A through Z, a through z, and 0 through 9.
Thisisnotatest ( talk) 01:22, 27 September 2015 (UTC)
Visual Editor has decided that ordinals must be superscripted. I usually see a couple of non-VE edited articles a day using superscripts and today there were 20+ VE articles. Before I file a bug ticket only to have the ticket dumped on the backlog queue to never see the light of day again, I'd thought I'd add accessibility info. Maybe that would help fix the problem. Do screen readers have issues with superscripted ordinals..... 2nd vs 2nd ? Bgwhite ( talk) 06:38, 15 October 2015 (UTC)
<nowiki>
tags in refs (ie <ref><nowiki>{{cite web |.... }}</ref></nowiki> would be important to fix. Others bugs, such as Content Translator wikilinking dates, are a MOS issue on English Wikipedia and are not important. So, if the ordinal issue were accessibility rather than MOS, it might get fixed rather than be put on the backlog queue.
Bgwhite (
talk)
04:55, 16 October 2015 (UTC)
<cite>
tags (not templates) and whatever [[Paris|P]]<nowiki/>aris
and [[Rome|Rom]]<nowiki/>a
is supposed to be.
Bgwhite (
talk)
21:08, 16 October 2015 (UTC)Wikipedia:Manual of Style/Mathematics#Using LaTeX markup recommends using association list formatting to fake a visual indentation for mathematics formulae. Do you all think that it's worth changing this (e.g., to something that provides the visual cue but uses {{ indent}} or CSS formatting)? WhatamIdoing ( talk) 18:26, 15 December 2015 (UTC)
"More complicated formulas, or formulas used in more technical articles, are often better off with the default alt text."I don't know what genius thought that up, but I fail to see who would be better off with the default alt text of "\int _{0}^{\infty }e^{-x^{2}}\,dx." (as used in the example in Wikipedia:Manual of Style/Mathematics #Using LaTeX markup) rather than something like "integral from 0 to infinity of e to the minus x-squared dx". I'm tempted to just remove that sentence. -- RexxS ( talk) 00:40, 16 December 2015 (UTC)
<math display="block">
provides the indentation without adding odd spaces or list formatting.
WhatamIdoing (
talk)
18:49, 24 December 2015 (UTC)I can create a list from dump files that show which articles have a blank line inside an unordered list. The list must be done in wikicode. AWB can fix the vast majority of these cases. AWB will only fix if the the blank line contains only a newline. Any spaces or tabs before the newline and AWB won't fix. Is this a good enough idea to get bot approval? I'm sure there will people who complain, so I'd like to get all my ducks in a row. Bgwhite ( talk) 09:36, 24 December 2015 (UTC)
For your tinkering (and proving what it does to people who don't believe you) pleasure, I present:
<dl>
description/definition/association lists.— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 09:46, 26 February 2016 (UTC)
The role
attribute was whitelisted back in 2013, especially for use with layout tables (Phabricator
T26583 and
merge). I added a recommendation to use the role
attribute, as an extra precaution against screen readers interpreting them as data tables. Sorry if this was overbold!
Matt Fitzpatrick (
talk)
07:02, 12 April 2016 (UTC)
On this page, it says "Do not make pseudo-headings using semicolon markup and try to avoid using bold markup." But at Help:Punctuation#Semicolon, it says "A leading semicolon ‹;›, in column 1 of a line, causes the line to be displayed as a bolded, non-indexed section header." What resolves the contradiction? Stevie is the man! Talk • Work 20:21, 8 April 2016 (UTC)
<dt>
term inside a <dl>
description list. MediaWiki's default CSS bolds <dt>
elements, so to sighted users, ;XYZ
resembles '''XYZ'''
. To screen readers, though, yikes! Many, if not nearly all, screen reader users navigate pages by skipping from heading to heading, but <dl><dt>XYZ</dt></dl>
isn't read or navigated like a heading, it's read and navigated as a list.
Help:Punctuation should be changed; I'd consider this use of a semicolon in an article to be an accessibility error.
Matt Fitzpatrick (
talk)
10:54, 12 April 2016 (UTC)
'''foo'''
or <b>bar</b>
. If they want strong emphasis they can use <strong>baz</strong>
or {{
strong|quux}}
. If people want to indent something short, they can use {{
in5}}; if they want to do a block indent, they can use {{
block indent}}
, and should not abuse block quotation markup for that. Talk pages are kind of a lost cause at this point, but we should use better formatting in articles. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
00:41, 16 April 2016 (UTC)Please see
Template talk:Collapse top#RfC: Heading centered or left by default?, for a discussion that would affect the default text-align
of the headers/titles of various content-box templates. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
13:43, 19 April 2016 (UTC)
Please comment at Talk:Glossary of video game terms#RfC: Replacing pseudo-headers. -- Izno ( talk) 12:03, 27 April 2016 (UTC)
Please comment at Template talk:FlagIOCathlete#Option to move flag. The discussion is about adding template parameters to enable displays like the following, which in the second column reverse the position of the flag and country, simply for the sake of a mirrored visual effect:
Jane Smith | United States | vs. | France | Jeanne Deaux | ||
Xian Chen | China | vs. | Honduras | Juana Perez |
There may (or may not) be information architecture, usability, and accessibility concerns with this.
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:21, 7 June 2016 (UTC)
Where images requiring attribution are used in a decorative way, such as in Template:Portal bar where the images merely repeat the information in adjacent text, a conflict arises. The licensing requires a link, but best practice is empty alt text for decorative images and, by extension, no link. To help prevent irrelevant audible clutter interrupting the flow of text, I think the accessibility MoS should encourage the use of elements not requiring attribution (e.g. public domain images) for decorative use. Matt Fitzpatrick ( talk) 23:16, 20 June 2016 (UTC)
A user raised a concern at Talk:Lightning that one of the images on the page, File:Lightnings sequence 2 animation.gif, may violate the MOS for accessibility, particularly MOS:ANIMATION. Where is the best place to get an opinion on whether there are too many flashes in that GIF? — C.Fred ( talk) 23:51, 25 July 2016 (UTC)
A discussion regarding the use of {{ Flatlist}} or {{ Hlist}} in various music infoboxes is ongoing at Template talk:Infobox album#Harmonization with other music templates. Comments regarding their benefit are welcome. — Ojorojo ( talk) 13:25, 2 August 2016 (UTC)
MOS:LISTGAP says don't do this:
* Support. I like this idea. [[User:Example]] :: Question: What do you like about it? [[User:Example 2]]
Is that the same as doing this?
* Support. I like this idea. [[User:Example]]: : Question: What do you like about it? [[User:Example 2]]
An example of how this is used in TV articles is at Supergirl (TV series)#Cast and characters. -- AussieLegend ( ✉) 11:39, 13 August 2016 (UTC)
<ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a></li> </ul> <dl> <dd> <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl> </dd> </dl>
<ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a>:</li> </ul> <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl>
* Support. I like this idea. [[User:Example]]: *: Question: What do you like about it? [[User:Example 2]]
<ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a>: <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl> </li> </ul>
** Support. I like this idea. [[User:Example]]: :: Question: What do you like about it? [[User:Example 2]] ** Oppose. I hate this idea. [[User:Example3]]: :: Question: What do you hate about it? [[User:Example 4]] <ul> <li> <ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a>:</li> </ul> </li> </ul> <dl> <dd> <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl> </dd> </dl> <ul> <li> <ul> <li>Oppose. I hate this idea. <a href="/info/en/?search=User:Example3" title="User:Example3">User:Example3</a>:</li> </ul> </li> </ul> <dl> <dd> <dl> <dd>Question: What do you hate about it? <a href="https://en.wikipedia.org/?title=User:Example_4&action=edit&redlink=1" class="new" title="User:Example 4 (page does not exist)">User:Example 4</a></dd> </dl> </dd> </dl>
*First item of unordered list
*:Definition list nested inside first list item
*::Definition list nested inside definition list
*Second item of unordered list
*First unordered list
:*Unordered list inside definition list
::*Unordered list inside definition list nested inside definition list
*Second unordered list
"What we should have is probably..."
- Why not just:
* Support. I like this idea. [[User:Example]]: ** Question: What do you like about it? [[User:Example 2]]
-- ? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 13 August 2016 (UTC)
* Support. I like this idea. [[User:Example]]: : Question: What do you like about it? [[User:Example 2]]
* Support. I like this idea. [[User:Example]]:
*: Question: What do you like about it? [[User:Example 2]]
<dl>...</dl>
inside the first <li>...</li>
of the existing <ul>...</ul>
, which remains open for its second <li>...</li>
(not shown above). --
Redrose64 (
talk)
10:15, 14 August 2016 (UTC)
<br>
to get a new line. --
RexxS (
talk)
20:32, 14 August 2016 (UTC)@
Adamstom.97: "a single bullet for the actor and character name, followed by a single colon for the extra information"
- that's two lists, with one item each. Not good.
Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits
13:42, 30 August 2016 (UTC)
I thought that this might interest some of you. Last year, Google started transcoding websites, including Wikipedia, to reduce page weight (and therefore the cost of reading and page loading time) for people using mobile devices with slow connections. There's some information on their blog. You can compare the results here:
It seems to remove Javascript as well as all images. (Also @ Guy Macon:, who has been interested in issues of page weight in the past). (Please ping me if you need my attention; I'm not watching this page.) Whatamidoing (WMF) ( talk) 08:36, 30 August 2016 (UTC)
Please see " Wikipedia talk:Manual of Style#RfC: What (if anything) to do about quotations, and the quotation templates?". Some specific accessibility issues have been raised about particular templates, and there's a test of a mild background shading to the default {{ Quote}} template. Please examine the entire RfC; someone later opened a "voting" section about one particular template, but it does not address the majority of the questions and concerns raised in the RfC. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:46, 11 September 2016 (UTC)
I've updated WP:MOS#Scrolling lists and collapsible content, the first major re-examination it has had in a long time (and much has changed, like the Google transcoding in Asian countries mentioned above at WT:ACCESS). Overview at WT:MOS#Updated "Scrolling lists and collapsible content" section, and diff here]. It's possible this updating may need to be reflected in MOS:ACCESS. It might even be desirable to move some of that into MOS:ACCESS and make the segment at the main MOS page shorter, though most of the additional material is footnotes. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 09:32, 11 September 2016 (UTC)
I have updated {{
Based on}} to use a Lua module which automatically uses {{
Unbulleted list}} for multiple writers rather than semantically incorrect line breaks which were previously recommended by the template documentation. Someone might want to run over existing transclusions with a bot and replace <br />
(and variations) with |
, i.e. use separate parameters for multiple writers.
nyuszika7h (
talk)
14:06, 13 October 2016 (UTC)
There is a discussion at WikiProject_Albums regarding headings. The advice is not to use basic mark up for MOS:DEFLIST type situations because "Screen readers and other machines can only use correctly formatted headings for navigation." A while ago I downloaded a screen reader to see what the issue was, the reader treated "==" and ";" formatted headings the same. I tried another one again today ( http://www.nvaccess.org/download/) and that is also fine. Is it the case that when the screen reader details were added (back in 2012 I think) that such readers couldn't deal with the ";" formatting, but they can now? Would it appropriate for a bunch of us to try out various screen readers to see what issues are created when using them while reading Wikipedia? SilkTork ✔Tea time 13:29, 13 November 2016 (UTC)
;The Beach Boys
followed by *
Al Jardine ...
, the html introduces a definition list, <dl>
; then gives a definition, <dt>
The Beach Boys</dt>
; but then closes the definition list <dl>
without ever defining anything! It then begins a separate bulleted list <ul>
<li>
Al Jardine ...</li>
, etc.===The Beach Boys===
followed by *
Al Jardine ...
(i.e. a heading followed by a bulleted list); or (2) ;The Beach Boys
followed immediately by :
Al Jardine
... (which makes a complete definition list). But half of one and half of the other makes no sense at all.But these lists are not meant to be in sections. Think of them like sentences: "The session musicians were Arnold Belnick on violin, Chuck Berghofer on string bass" but converted to a list to make reading easier, as described in WP:Def list, which says they are more accessible for screen readers. In the sentence "Do not make pseudo-headings using semicolon markup" I think there is a misunderstanding regarding what is meant by pseudo-headings. We don't advocate using pseudo-headings on Wikipedia. The sentence is being interpreted as meaning "do not use semicolon markup as this is unable to be read by screen readers". But I don't think the guide here is saying "don't use def list mark up", it is saying "don't do something [create "pseudo-headings"] that we don't do on Wikipedia anyway". I don't think we need a special accessibility instruction for something we don't advocate doing anyway. But we do need compatibility between guidelines, and some clarity on when and how to use def lists appropriately to help all readers. Personally I prefer prose, but I understand that most readers prefer some details to be presented in lists, and I can handle that. But we shouldn't be forcing association lists into section headings because that's going a stage too far, and making reading more awkward for all. SilkTork ✔Tea time 09:43, 14 November 2016 (UTC)
The lists in
Pet Sounds are clearly in sections (or sub-sections to be accurate) and if you're going to give them a (sub)heading, you ought to use a (sub)header.
WP:Def list says "Properly formatted definition lists are more
accessible to people using
screen readers ..."
. That's properly formatted definition lists, not a ';' on its own or mixed in with unordered lists. Are you able to read html? If you are, inspect the the following three examples:
Can you see that the first example has a section heading and one unordered list of four items? That the second example has one list (an association list) with an association term and four 'associations'? And that the third example has two separate lists: the first being an association list comprising an association term but no associations; and the second being an unordered list of four items?
Why would we want to tell someone using assistive technology that there are two lists in each section?
An association list <dl>...</dl>
is the only list in html that has its own in-built header <dt>...</dt>
to go with the list items <dd>...</dd>
. And we are sometimes misuse that <dt>...</dt>
to try to create headings for other sorts of lists (pseudo-headers), which are visually acceptable but which are never going to be read properly by screen readers because the underlying html is bolixed. That's why we have the advice not to use ';' for pseudo-headings. --
RexxS (
talk)
12:06, 14 November 2016 (UTC)
I'm not clear on what is intended to be meant by pseudo-headers. Does it mean "appropriate headings created using inappropriate mark-up", or "inappropriate headings created using inappropriate markup" or "inappropriate headings created using appropriate markup"? As this is an accessibility guideline I am assuming it means "appropriate headings created using inappropriate mark-up", in which case perhaps we should simply say that to avoid confusion. That would be a start. That we could guide people toward how they should be presenting the headings.
SilkTork
✔Tea time
11:15, 17 November 2016 (UTC)
Production
or this
Production:
It reads it as "Production list of four items link Bruce Botnick engineer..." which seems to me to be fine as the meaning will be understood. I don't see why we need to have in bold, as that doesn't necessarily assist meaning for a sighted reader. Personally I would prefer a prose sentence: "The production engineers were
Bruce Botnick,
Chuck Britz,
H. Bowen David, and
Larry Levine." But people like lists. We could have:
The production engineers were:
Guest musicians were:
Sessions musicians were:
Would that be acceptable? SilkTork ✔Tea time 12:22, 17 November 2016 (UTC)
<h3>...</h3>
, etc.). It can result in something that looks like a heading to a sighted reader, but which has no semantic markup available for assistive technology or for other automated tools. --
RexxS (
talk)
18:54, 17 November 2016 (UTC)==== Production ==== * [[Bruce Botnick]] – engineer * [[Chuck Britz]] – engineer * [[H. Bowen David]] – engineer * [[Larry Levine]] – engineer '''Production''' * [[Bruce Botnick]] – engineer * [[Chuck Britz]] – engineer * [[H. Bowen David]] – engineer * [[Larry Levine]] – engineer ;Production : [[Bruce Botnick]] – engineer : [[Chuck Britz]] – engineer : [[H. Bowen David]] – engineer : [[Larry Levine]] – engineer
big
headers. --
Jennica✿
talk /
contribs
05:32, 20 November 2016 (UTC)
<big>...</big>
tags are
obsolete in HTML5. They're not exactly against our
MOS:FONTSIZE, although better ways exist. On another matter, the section in question has {{
col-start}}
{{
col-break}}
and {{
col-end}}
- but these are rather pointless when there is only one column. --
Redrose64 (
talk)
10:31, 20 November 2016 (UTC)I identified an opportunity to improve the way that redirect information is presented at Template_talk:Redirect#Targeting_the_message. It was suggested that I mention the idea here in case it spurred interest from anyone is in the accessibility crowd. If so, feel free to pick up the discussion there, or here if more appropriate. -- Ed Brey ( talk) 17:26, 21 November 2016 (UTC)
I'm wondering wether {{ Legend}} is even compatible with WP:ACCESS. It's a template that allows the creation of color-based only legends with no other means to provide the same information. This seems to be in direct contradiction to the spirit of this guideline for obvious and logical reasons. So I question whether this template should be recommended, let alone used. Any thoughts? T v x1 20:51, 22 November 2016 (UTC)
Could somebody with more HTML/colour experience than I have weigh in at Talk:Dust Bowl#A map, at long last regarding the accessibility problems with {{ color sample}}? Thanks. Graham 87 15:55, 15 January 2017 (UTC)
The use of colored backgrounds for purely cosmetic purposes when {{ Episode table}} is used should be discouraged and forbidden when the background is darkened to the point that the descriptive text is forced to white. As when one prints the page readability can suffer due to printing being limited to either CMYK or grayscale only. An alternative would be to have the print export view disable CSS elements but that could affect the article layout. 101.98.165.25 ( talk) 01:41, 24 January 2017 (UTC)
comments at Talk:Upper East Side#listgaps are welcome. Frietjes ( talk) 16:03, 24 January 2017 (UTC)
@ TheDJ, Psiĥedelisto, Graham87, and RexxS:
The problem with listgaps, as I understand it, is that blank lines, which are often meant to provide some visual clues to list structure,
But the HTML <br>
tag can produce the same sort of visual break without introducing any actual (as far as code can tell) blank lines. And so it occurred to me that it might be wise to suggest this tag in
MOS:LISTGAP as a way to add gaps for visual readers without hindering screenreader users. I started to draft an alternative version of that section in my userspace, and realized further that even without mentioning <br>
, the section would benefit from showing the display of each acceptable ( ) and not acceptable ( ) example and not just the wikicode.
Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists says
<br>
). Use {{
plainlist}} / {{
unbulleted list}} if the list is to remain vertical; or consider {{
flatlist}} / {{
hlist}} if the list could be better rendered horizontally (in-line) as described in the following two sections.But I believe that that refers to using <br>
to visually simulate a vertical list, and for exactly the same reason that I'm suggesting it to visually simulate a gap: that it has a visual effect but not a semantic one.
My draft is in User:Thnidu/Draft: Safe blank lines. I added new paragraphs in boldface, then (facepalm) realized that that probably doesn't help anyone using a screenreader, so I wrapped my additions in plaintext labels "[BEGIN ADDED]" and "[END ADDED]". I haven't expanded all the examples, but if people think this is a good idea, the additional expansions would be pretty obvious to implement.
Please {{Ping}} me to discuss. -- Thnidu ( talk) 02:10, 1 February 2017 (UTC)
<br>
to your last example, and 2) even adding it makes no difference to the display on my screen. However, adding two <br>
s does add extra space. I suspect that different browsers will interpret <br>
differently. —
Gorthian (
talk)
03:27, 1 February 2017 (UTC)
There's some accessibility issues for the Chart module. We need some focus on CSS override and print-ability. — Dispenser 05:55, 6 February 2017 (UTC)
Maybe I'm being dumb, but can someone advise how to apply this template without inadvertently setting the Table of Contents above the Lead? I just experimented at Revolver (Beatles album), ended up with this. Thanks, JG66 ( talk) 16:47, 7 February 2017 (UTC)
{{
TOC limit|3}}
must be the last item in the lead section - you were putting it between infobox and introductory text. The easiest way to do this is to first ensure that you have "Add an [edit] link for the
lead section of a page" enabled at
Preferences →
Gadgets. Then edit the lead section of the article, and in the edit box, go to the very end of the text. Add the {{
TOC limit|3}}
on a line of its own, and save. --
Redrose64 🌹 (
talk)
17:05, 7 February 2017 (UTC)
Hello, all. I re-started a discussion at the reflist template a little while ago, to see if we could improve accessibility on different screen widths/font sizes. I think that RexxS has a solid solution in that template's sandbox. It's a very widely used template, so I really don't want to screw this up or have to make more than one change. If there's anything else that ought to happen here, or if you have any thoughts on the change, could you please join the discussion over there and let us know? Thanks, WhatamIdoing ( talk) 21:16, 20 February 2017 (UTC)
From a recent Tech news:
"You will be able to show references from
<references />
tags in more than one column on your wiki. This is the list of footnotes for the sources in the article. How many columns you see will depend on how big your screen is. On some wikis, some templates already do this. Templates that use<references />
tags will need to be updated, and then later the change can happen for all reference lists. [14] [15]"
— Preceding unsigned comment added by Pigsonthewing ( talk • contribs) 21:09, 20 March 2017 (UTC)
this is a giant leap backward for accessibility. we have spent so much time taking infoboxes that use <br>
to delimit years, teams, caps, ... and convert them to use number-suffixed versions for
WP:ACCESSIBILITY. now,
Primefac has reversed this progress on
Template:Infobox rugby union biography and from all the safesubst: it looks like the intention is to make this permanent. for
Template:infobox football biography we had transition code to support both syntax forms to allow for the conversion to the accessible version. we should do that for
template:infobox rugby biography as well, and not step backward in time.
Frietjes (
talk)
18:41, 20 March 2017 (UTC)
|history=
parameter was better than numbered histories. If this is indeed not the case, I will happily go back to the sandbox. I'm just slightly annoyed that the template has been ready for merging for almost two weeks and only after I start substing does anyone say anything.
Primefac (
talk)
18:45, 20 March 2017 (UTC)
This page 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. |
Hi folks, and @ Graham87: in particular. I was wondering if I could get some input on this bug ticket, regarding the usage of tabIndex, especially when it comes to the sidebar collapsibles. In my opinion, we might as well set them to 0 now that the rest of the section has been elevated to be under an H2. — TheDJ ( talk • contribs) 09:48, 1 June 2013 (UTC)
Much of this page pertains directly to articles, but could just as easily apply to project pages or Talk pages. What is its scope? Where should it apply, and where should it not? Is there a limit? Personally, I think the scope should be as wide as possible, and the site should be universally accessible to everyone. But some editors clearly disagree with my take, so I’d like to hear theirs, free of all of the above drama. And obviously, if it applies to Talk pages, any edits to anyone else’s comments would be governed by WP:TPO. — Frungi ( talk) 06:45, 1 June 2013 (UTC) edited 19:38, 10 June 2013 (UTC)
Articles Only, But... I do think we should and must encourage accessibility across the entire encyclopedia, articles, talk pages, project pages, etc. However, I don't believe that a broad mandate across all those spaces fits within the Manual of Style, which is pretty exclusively dedicated to the article space. It may be worth considering promoting this section outside of the Manual of Style, but I really do have some concern about pushing the Manual of Style outside of article space. -- j⚛e decker talk 22:47, 2 June 2013 (UTC)
Article space only unless explicit. Some of the guidelines should apply to all pages. However, the one we are talking about (elsewhere on this talk page; technically not here) detracts from readability and editability by sighted, but possibly otherwise disabled, readers and editors. I would have to ask Graham whether the blank lines make it easier for a blind editor to, well, edit the talk page, but I agree that the "Wall of text" could be, and in fact, has been, a problem for me. (Note that I'm violating the guideline here, as I've started a new list.) — Arthur Rubin (talk) 13:39, 3 June 2013 (UTC)
<div>
s or something would make much more sense. I’m not sure how the nesting could be implemented for screen readers, though. Still a bit off topic here, but is there anything we can do about that beyond Bugzilla (or just waiting for a new system)? This bug (
T6521) is six and a half years old. —
Frungi (
talk)
15:12, 3 June 2013 (UTC)Article space only However its use can be encouraged elsewhere and any accessibility solutions should be consistent with it. WP:TALK and Help:Using talk pages are the right places to put things about talk pages and if there is a common accessibility problem in talk pages then that is the place for a guideline about it even if just a short description of the problem with the usual solutions and a link to a section here about it. Dmcq ( talk) 14:02, 3 June 2013 (UTC)
Everywhere: Whatever arguments are adduced in support of accessibility considerations for those reading articles apply with exactly the same reasoning to all other pages on Wikipedia. That is assuming that disabled readers are just as welcome on other pages - and I've seen no arguments contradicting that view yet. -- RexxS ( talk) 16:05, 3 June 2013 (UTC)
Everywhere but it won't be mandatory for talk pages rather than for articles. It would be a guideline for talk pages, maybe like a how-to. Ramaksoud2000 ( Talk to me) 01:46, 4 June 2013 (UTC)
I have a concern. Recently, several editors who are involved in this RfC were involved in a failed attempt to expand the accessibility guidelines that were specifically written for Wikimarkup lists so that they apply to all talk pages, arguing that the talk page you are reading right now is really a list, the comment you just wrote is really a list item, and thus the guideline that was written to apply to Wikimarkup lists applies to your talk page comments. Now I do not want to re-hash the merits of that argument in another place, but I am concerned that votes that agree with statements like "the scope should be as wide as possible" and "this guideline should be applied everywhere" might not be interpreted as meaning "the guideline on lists should apply to lists on articles, lists on talk pages, lists on template pages, etc." but rather "the guideline on lists should apply to lists, talk page comments, and various other elements to be specified later." Now I could very well be completely wrong on this, and there might not be anything to be concerned about, but if enough people vote for "apply the guidelines everywhere" and if such a result is interpreted the way I think it will be, then we are going to end up having Yet Another Battle, this time over whether those who voted on this RfC knew what they were voting for. -- Guy Macon ( talk) 02:47, 4 June 2013 (UTC)
Request to all participants in this RfC: Let's not yet discuss the specifics of how any particular part of the guideline may or may not apply to any particular quirk of the software outside of article pages. It's simply a waste of time while it's unclear whether the guideline applies outside of article pages, and muddies up the discussion. — Frungi ( talk) 13:51, 4 June 2013 (UTC)
Everywhere, but of course within reason. We want all users to be able to read all the pages. we don't want to tell some users that their participation is unwelcome or should be needlessly painful. This statement is true regardless of whether the issue is quietly indenting the newbie's comments with the correct number of colons (which we do hundreds of times a day, without anyone getting upset) or quietly removing blank lines that slow down the page for people using screen readers. This statement is true regardless of whether the question is an AFD or a talk page or an article. Everyone should be welcome everywhere, not just in articles. We don't have to be nasty about any of this, and it doesn't have to be "important" or take time away from article writing, but we should fix it when it when we run across it, or at least not object to other people fixing such problems. (In fact, the ideal solution to the LISTGAP problem on talk pages IMO is to have the archiving bots fix it. They're already removing stray blank lines after section headings.) WhatamIdoing ( talk) 19:10, 6 June 2013 (UTC)
off-topic replies by Dmcq and Frungi hidden by Frungi
|
---|
|
<pre>...</pre>
block due to an unintentional leading space. I’m with WAID: I don’t see how this is anything new. There’s already plenty of opportunity to screw up in trivial ways that are easily fixed. Likewise, there are countless wrong ways to “fix” these errors, mostly by drawing unnecessary attention to them—we don’t fix a newbie’s colon count with an edit summary of, “editor was violating
WP:INDENT; corrected and left a stern warning on his Talk.” That kind of nonsense would be unacceptable, and there’s no reason that it would be any more likely to happen with LISTGAP or any other accessibility-related matters. —
Frungi (
talk)
22:36, 9 June 2013 (UTC)
TPO has said that list markup can be corrected for months now. See the item that begins "Fixing format errors that render material difficult to read" (and, if necessary, take particular notice that it's not just "renders material difficult to read for sighted readers"). Fixing list markup was explicitly added about six months ago, but the general concept has been there for years. There was no objection to this fixing other people's lists— I've done it hundreds of times without a single complaint—until Guy and Walter discovered that indented threads are technically lists (something I hadn't realized until this dispute, either), and decided that the presence or absence of blank lines in a discussion at [[Template talk:Track listing] was critically important. WhatamIdoing ( talk) 19:53, 10 June 2013 (UTC)
(This cross-post is identical to the note at the WikiProject Accessibility page.)
The WP:VisualEditor is designed to let people edit without needing to learn wikitext syntax. The articles will look (nearly) the same in the new edit "window" as when you read them (aka WYSIWYG), and changes will show up as you type them, very much like writing a document in a modern word processor. The devs currently expect to deploy the VisualEditor as the new site-wide default editing system in early July 2013.
A couple thousand editors have tried out the early test versions so far, and feedback overall has been positive. Right now, the VisualEditor is available only to registered users who opt-in, and it's a bit slow and limited in features. You can do all the basic things like writing or changing sentences, creating or changing section headings, and editing simple bulleted lists. It currently can't either add or remove templates (like fact tags), ref tags, images, categories, or tables (and it will not be turned on for new users until common reference styles and citation templates are supported). These more complex features are being worked on, and the code will be updated as things are worked out. Also, right now you can only use it for articles and user pages. When it's deployed in July, the old editor will still be available and, in fact, the old edit window will be the only option for talk pages (I believe that WP:Flow is ultimately supposed to deal with talk pages).
The developers are asking editors like you to join the alpha testing for the VisualEditor. This is especially important for people who deal with accessibility, because it always takes a while to write, test, and deploy code—so it's important to get any major problems on the list sooner rather than later. Please go to Special:Preferences#mw-prefsection-editing and tick the box at the end of the page, where it says "Enable VisualEditor (only in the main namespace and the User namespace)". Save the preferences, and then try fixing a few typos or copyediting a few articles by using the new "Edit" tab instead of the section [Edit] buttons or the old editing window (which will still be present and still work for you, but which will be renamed "Edit source"). Fix a typo or make some changes, and then click the 'save and review' button (at the top of the page). See what works and what doesn't. We really need people who will try this out on 10 or 15 pages and then leave a note Wikipedia:VisualEditor/Feedback about their experiences, especially if something mission-critical isn't working and doesn't seem to be on anyone's radar.
Also, the screenshots and instructions for basic editing will need to be completely updated. The old edit window is not going away, so help pages will likely need to cover both the old and the new. The WMF is committed to this long-requested improvement, and it's my impression that nothing short of a complete collapse of the servers will cause it to be reversed, so we need information that will help them get it right. The new editing system will become the default, not the only option.
If you have any other questions and can't find a better place to ask them, then please feel free to leave a message on my user talk page, and perhaps together we'll be able to figure it out. Thanks, WhatamIdoing ( talk) 01:08, 7 June 2013 (UTC)
Currently, the guideline reads "If a space is needed, insert an extra line consisting of the same number of colons.", please look at the wikimarkup for the following tests in your editing window and then look at the HTML source:
TEST A
Comment (level 0)
Comment (level 0)
TEST B
Comment (level 0)
Comment (level 0)
TEST C
Comment (level 0)
Comment (level 0)
TEST D
Comment (level 0)
Comment (level 0)
As expected, test D is far worse than A, B, or C, but it turns out that it matters whether "the same number of colons" means the same number as the comment above or below. TEST C renders to the same HTML as TEST A, BUT TEST B does not. IMO, if we are going to tell people how to tweak the wikimarkup so that it produces a particular HTML rendering, exactly how they should do this should be clarified, with examples.
BTW, I really like the lines with colons idea, and am going to start doing it that way (test C) in my posts. -- Guy Macon ( talk) 21:21, 10 June 2013 (UTC)
Hi, please see this discussion at WikiProject Military history. We wish to style the † symbol properly, in a way that looks more like the 2nd or 5th example in - the default sans-serif version (†) usually looks like the 1st example, which has caused many problems and raised various questions. Please reply there (to keep everything centralized), with suggestions on how to best implement this, and if it is possible to achieve high-percentage reliable styling across browsers. (I've not kept up-to-date with CSS over the last few years, but my tests can be seen a few replies down, in the thread). Much thanks.
what's the consensus on this sort of thing? I reverted as possibly problematic, but could use some additional feedback, especially if I am wrong about it being a problem. I, personally, find plain text easier to read, and image maps better for inclusion in articles where the information is also presented in plain text. Frietjes ( talk) 21:01, 14 June 2013 (UTC)
When a single source is cited multiple times in the same article, getting back from the references section to the right section of prose requires guesswork. This is (imo) a bad thing and I have prosed to change it.
For a detailed explanation see Wikipedia:Village pump (technical)#Multiple references to the same source. You are invited to participate in the discussion there. Thryduulf ( talk) 00:36, 16 June 2013 (UTC)
Just a brief note: I know there are rumors floating about that all users will be required to use WP:VisualEditor when WP:Flow rolls out. None of it's true. The design for Flow has always included a fallback for users who use screen readers or don't have Javascript or otherwise cannot use VisualEditor. Even assuming that the Flow team decides to use VisualEditor (which I understand is likely, but not set in stone yet), there will be options for people who have special accessibility issues. Whatamidoing (WMF) ( talk) 04:17, 15 July 2013 (UTC)
...I present to you The Web Accessibility WCAG Theme Song. Enjoy! -- Guy Macon ( talk) 16:55, 4 June 2013 (UTC)
I was wondering about what the experience is like, for a typical regular screenreader user. Does anyone have a particularly good example video, to demonstrate to editors who are semi-familiar with screenreaders, what standard high-speed usage is like? I know Graham has mentioned skipping or clipping off the end of items, but I'm not sure what that sounds like in practice. The best two videos I've found after a while of searching youtube, are
(Note that I did watch many more videos, and there an abundance of poor quality recordings, or labored introductions to the topic aimed at non-geeks.) I'm hoping to find something right in between those two; something that demonstrates 2–5 minutes of normal use, by an advanced or smart user. Maybe even something that we could link to from the WP:ACCESS page itself. – Quiddity ( talk) 06:03, 5 June 2013 (UTC)
I was unaware of this, so I suspect many others as well. It's actually possible to use role="presentation" on tables, if they are used for presentational purposes. Considering adding this to *mbox... — TheDJ ( talk • contribs) 08:40, 13 August 2013 (UTC)
See Template talk:Flatlist#Accessibility. Frietjes ( talk) 15:54, 22 August 2013 (UTC)
I've recently done a write-up about accessibility problems on Wikipedia in the Signpost's tech report, and flowing from that, I've started a bot request discussion to fix some accessibility issues that I noted in the write-up. Any comments at the bot request discussion would be appreciated. Graham 87 05:16, 7 September 2013 (UTC)
see Template talk:Cross-Tipped Churches. Frietjes ( talk) 20:00, 16 September 2013 (UTC)
We have ...
Images should contain a caption, either using the built in image syntax or a secondary line of text. The caption should concisely describe the meaning of the image, the essential information it is trying to convey.
... meanwhile, we also have ...
- Periodic table snippets for each element – no caption needed
- Images of Element samples in the element infobox – no caption needed
- Images of plants and animals, protists etc. in infoboxes – caption optional
- Infobox images with mission insignia – no caption needed, but if there is a description of the symbolism, it should be included on the image description page
- Other images (especially within infoboxes) where the purpose of the image is clearly nominative, that is, that the picture serves as the typical example of the subject of the article and offers no further information – no caption needed.
It seems that these conflicts require some arbitration (e.g. sub-clausing the WP:CAP#Special_situations items: "except where there is no WP:ALT content" – the basis upon which I acquiesced a recent revert spat, regarding music release cover-art).
Any ideas folks? I'm very interested in technology to accommodate the differently enabled (e.g. abatement of sight-impairment), but have much to learn, in terms of all the prevalent combinations of abilities and aids (e.g. screen readers). – Ian, DjScrawl ( talk) 23:07, 14 October 2013 (UTC)
Just in case anybody interested doesn't have the WikiProject page on their watchlist, see this thread about an ongoing Signpost interview with the project. Graham 87 02:34, 18 October 2013 (UTC)
Can someone explain to Ken at User_talk:Dennis_Brown#Would_you_take_a_look.3F that inserting a {{ col-break}} in the middle of a list causes a WP:LISTGAP? Thank you. 174.56.57.138 ( talk) 05:35, 18 October 2013 (UTC)
The section at WP:ACCESS#Resolution primarily deals with ensuring that users with low-resolution screens won't be hindered in their Wikipedia experience. Should the same care extend to users with high-resolution screens? For example, {{ track listing}} creates a simple table for combining multiple sets of data about a musical album's track listing (track number, track title, writing credits, lyric credits, track notes, track length, etc.). However, when the same template is only used for a few fields (just track title and track length), on a higher-resolution screen, this can cause an ungodly amount of empty space between the two sets of data in the table. And that space gets larger as the screen size increases since the table is formatted to fill the entire screen, whatever the size. Should this MOS be updated to include concerns about higher-resolution screens as well? Fezmar9 ( talk) 01:09, 28 October 2013 (UTC)
see Talk:Catalogue of Women. thank you. Frietjes ( talk) 17:27, 10 November 2013 (UTC)
WP:Manual of Style/Accessibility#Text says:
That presumably prohibits adding single line breaks to the end of sentences. The essay Wikipedia:Don't use line breaks gives pros and cons of line breaks within article source text, but despite the title does not come to a conclusion. A poll on Wikipedia talk:Don't use line breaks shows editors about equally split, maybe slightly leaning to line breaks if they are only used at the end of sentences. The main "pro" argument is that diffs are easier to follow if there are line breaks in the source text and the main "con" argument is that they make the source text look even more different from what is displayed. The essay does not discuss accessibility.
My eyesight and coordination are not great: I sometimes find it hard to position the cursor precisely using the mouse. I swap text around a lot when I am working on an article until I am satisfied with the sequence. If each sentence is followed by a line break I find it easier to select the sentence, then cut it and paste it somewhere else. I click and hold in the white space after the end of the line, pull the mouse back to the start of the sentence on the left of the edit box, then CTRL+X, CTRL+V to move it. It is harder for me to select and move text that is embedded in a line or lines because I have to position the cursor more precisely. I also prefer not to overcite. Two or three sentences may have a cite at the end of the last sentence. Before moving one of these sentences somewhere else, I have to copy the cite to the end of it too, which is easier for me with line breaks at the end of each sentence:
On the other hand line breaks, even when only placed at the end of sentences, make editing with a screen reader a bit more awkward. This seems like a trade-off between making editing a bit easier for some editors at the cost of making it a bit harder for others. I would prefer to change this statement in the guideline to:
Comments? Aymatth2 ( talk) 14:56, 6 November 2013 (UTC)
The following discussion is closed. Please do not modify it. Subsequent comments should be made on the appropriate discussion page. No further edits should be made to this discussion.
I have decided to start a centralized discussion about collapsing track lists, and the effect this has on users with disabilities. Talk:Long. Live. ASAP#Collapsed sections and Talk:Music_of_the_SaGa_series#Collapsed_sections contain previous discussions about the issue which I plan to continue here. I am not sure how this discussion should be moved over here, so if someone can do that it would be appreciated. -- Jax 0677 ( talk) 00:09, 1 October 2013 (UTC)
I would like to add the following section under text:
Comments? — Edokter ( talk) — 18:03, 4 January 2014 (UTC)
<sup>
, <sub>
and reference section that use {{
Reflist}} or <references />
... Anotherwords, wherever the font size is reduced, it should be avoided to reduce even more. Bugs me to no end that some reference sections are so small that I can't read the dang thing.
Bgwhite (
talk)
19:22, 4 January 2014 (UTC)2nd draft:
I think it may be important enough to include it in both pages. — Edokter ( talk) — 20:07, 4 January 2014 (UTC)
<small>
tag and the {{
small}} template reduces text by."
Bgwhite (
talk)
07:17, 7 January 2014 (UTC)<small>...</small>
HTML tag) produces a font-size of 85% of its surrounding text. The resulting font size should not drop below 85% of the page fontsize: Text should never appear smaller then this.I've created quite a few articles on braille, using either Unicode or images. It seems rather ridiculous that the blind can't read them because braille readers can't process Unicode braille. I wouldn't mind adding brackets or something to the braille so that the blind could distinguish between linear and braille script in the articles, but how do you make the braille itself accessible? Or do we simply need to wait for braille displays to catch up? (This is also a problem elsewhere; if you email a blind person in braille, they can't read it.) — kwami ( talk) 19:43, 7 January 2014 (UTC)
Hi.
How can we have exponentiation in an accessible manner? i.e. in a manner that screen readers read 28 as "two power eight" instead of "twenty eight"?
Best regards,
Codename Lisa (
talk)
13:58, 17 January 2014 (UTC)
I've found a page titled
DUKEDOM OF GRAFTON which has severe contrast issues. The colours are set using <body text="#FF0000" bgcolor="#666633" vlink="#800080" alink="#000000">
. In case you can't get to the page, and don't know what that HTML tag does, it means that plain text is coloured like this , for a contrast ratio of 1.49; unvisited links are coloured like this , for a contrast ratio of 1.57; active links are coloured like this , for a contrast ratio of 3.51; and visited links are coloured like this , for a contrast ratio of 1.58. Perhaps we should use it as An Example of Very Bad Contrast? --
Redrose64 (
talk)
20:44, 23 January 2014 (UTC)
There's a new proposal to re-design MediaWiki's toolbar, code-named Winter; comments about it are welcome at the proposal's talk page. Here is a prototype; I have already raised a few accessibility concerns about it. Graham 87 10:30, 28 January 2014 (UTC)
Someone has just gone through Arthur C. Clarke Award, a featured list, to denote the winners with a blue ribbon icon ( ), rather than with a * character like it was before. (The colored backgrounds have always been there in addition to the mark). Is this sort of marking acceptable from an ACCESS perspective? -- Pres N 18:20, 19 March 2014 (UTC)
|alt=
parameter and set default alt text, so it should be more accessible now. Unfortunately the icon is GPL and requires attribution, so we can't suppress the link.|alt=winner
) was supplied for every occurrence. I wouldn't bother re-reverting though! Cheers --
RexxS (
talk)
20:06, 19 March 2014 (UTC)Would someone please look at Wikipedia:Administrators' noticeboard/Header, specifically the "Are you in the right place?" section? I'm not certain, but I believe that it's a table of one column and sixteen rows, each cell of which contains a one-item list. If I'm right about how that template's working, then we really ought to simplify it. WhatamIdoing ( talk) 16:53, 1 March 2014 (UTC)
I attempted to add alt-text support for the map at {{ infobox language family}} ("map" or "map2" and "mapalt" or "mapalt2"). I don't know what behaviour to expect. Is it working correctly? — kwami ( talk) 20:14, 25 March 2014 (UTC)
|mapalt
had not been set. When that happens, you need to code it in the template as {{{mapalt|}}}
. The pipe character can be read as "or default to". In other words if mapalt isn't supplied, it then returns what's to the right of the pipe - i.e. null in this case. I've
made a tiny amendment to the template to insert the pipe character to {{{mapalt}}}
and {{{mapalt2}}}
. If you purge your browser you can see that in e.g.
Austroasiatic languages there is no alt text, but in
Germanic languages (where I've added |mapalt
to the infobox) the alt text is displaying as expected. --
RexxS (
talk)
20:51, 25 March 2014 (UTC)Please see Wikipedia talk:WikiProject Accessibility#Background colours on templates for a discussion on the use of background colours in templates (such as those used to mark closed discussions) which can cause accessibility issues when various text colours are used in the discussion. It is suggested that the use of such background colours should be avoided and that this may be introduced as a guideline or even a policy. — sroc 💬 06:49, 21 April 2014 (UTC)
Though this might not be directly related if anyone wishes to weigh in on this discussion to improve accessibility at Template:Infobox album please see the discussion here Template_talk:Infobox_album#Consistancy. → Lil-℧niquԐ 1 - { Talk } - 22:02, 30 April 2014 (UTC)
Regarding this recent edit and the corresponding one at MOS:FONTSIZE, please see Wikipedia talk:Signatures#On the topic of "Appearance and color" and line-height, and post comments there. -- Redrose64 ( talk) 20:25, 26 June 2014 (UTC)
I thought that Wikipedia:Manual of Style/Accessibility#Headings (or MOS:HEAD?) used to say that having multiple, identical section headings was an accessibility issue. Is that no longer the case? WhatamIdoing ( talk) 22:51, 27 July 2014 (UTC)
can someone look at the horizontal list in Trawniki men? I tried to change it to use actual list markup, rather than images as bullet points, but was reverted. is there a different method that I am not considering? I will start a thread on the talk page as well. Frietjes ( talk) 14:12, 9 August 2014 (UTC)
A discussion pertaining to WP:COLOR is taking place at Wikipedia talk:WikiProject Tropical cyclones/Tracks#Wikipedia:Manual of Style/Accessibility#Color compliance. Feedback from knowledgeable or interested editors is welcome. -- Netoholic @ 02:00, 15 August 2014 (UTC)
Template:lang-de-AT is used in only Austrian Empire. Because no other pages use it, I'm torn between proposing deletion and leaving it alone for several years. I tried to replace the template with simple formatting, but someone reverted it and cited this guidelines as a reason. Shall we follow this guideline, or shall we consider usefulness and effectiveness of the template? -- George Ho ( talk) 23:40, 14 August 2014 (UTC)
lang-*
are often not utilized very often while others in the same series are used constantly. The less frequently needed ones are there for completeness (both for user and automated tool expectation/need). There is no principle that a template must be frequently used to be useful. A template doesn't have to make excuses for how often it's needed.
WP:DROPTHESTICK. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
03:08, 19 August 2014 (UTC)
George Ho has nominated several {{Lang-xx-YY}}
templates for deletion, despite being advised against doing so above. They are grouped together near the top of
Wikipedia:Templates for discussion/Log/2014 August 13. Some respondents there have made accessibility (e.g. screen reader) arguments regarding such templates, so participants here may be interested in those TfDs, pro or con.
See also:
Ho raised related issues in a number of other forums (most of these deal with {{lang-xx-YY}}
templates in particular, while the one at WT:NOT is more general):
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:08, 19 August 2014 (UTC)
There is no guideline to add alt text, so I propose to add the text to an accessibility icon. Examples:
84.127.80.114 ( talk) 12:23, 15 September 2014 (UTC)
any advice/help in cleaning up English translations of Homer is welcome. the lack of section headings is crazy, and the fact that the highest level table headings is all the way at the top of the article is also a mess. also, the width of the article is impossible on a narrow screen, not to mention the massive number of small tags. thank you. Frietjes ( talk) 14:16, 4 October 2014 (UTC)
Is there much/any support for these in real screen readers? I'm wondering if, for example, our code layout templates should be using style="speak-punctuation: code;"
. Also, a <dt>
template like {{
Term}} maybe should be using style="richness: 75;"
and perhaps a slight pause-before
and pause-after
. Would such tweaks actually be helpful? —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
02:21, 30 October 2014 (UTC)
I'd be interested in the accessibility arguments pro and con regarding:
E=MC²
(with Unicode character for superscript-2), E=MC²
(with HTML code for same character), E=MC²
(with character entity code for same character), E=MC{{
sup|2}}
(template), and E=MC<sup>2</sup>
(the underlying markup behind the template, using HTML superscript). These render respectively as "E=MC²", "E=MC²", "E=MC²", "E=MC2", and "E=MC2".1⅔
(with Unicode two-thirds character), 1⅔
(with HTML code for same character), {{
frac|1|2|3}}
(commonly used template), {{
sfrac|1|2|3}}
(alternative template), 1<sup>2</sup>⁄<sub>3</sub>
(the underlying markup behind both templates, using HTML superscript and subscript markup, and the character entity code for fraction-slash), 1<sup>2</sup>⁄<sub>3</sub>
(same but with Unicode fraction-slash), 1<sup>2</sup>⁄<sub>3</sub>
(same but with HTML code for the fraction-slash), plain-text 1 2/3
, and plain-text with thin-space 1 2/3
. These render respectively as "1⅔", "1⅔", "1+2⁄3", "1+2/3", "12⁄3", "12⁄3", "12⁄3", "1 2/3", and "1 2/3". [The form "1-2/3" is sometimes encountered, but too easy to interpret as "1 minus 2/3", because the hyphen (-
) is commonly used as a stand-in for the proper minus character (−
, not distinguishable from hyphen in most fonts), and has been intended to serve double-duty since the dawn of computing.]My general impression is that the Unicode characters can often be problematic, their HTML and entity code equivalents a little less so (mainly from an OS and browser support, not accessibility, point of view). — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 03:22, 20 October 2014 (UTC)
<sup>2</sup>
.
Bgwhite (
talk)
21:57, 20 October 2014 (UTC)
&
-codes from a reader perspective (they're both bad for screen readers if the character represented isn't in ISO Latin-1's character set), other than in editing mode the &
-code version will be read out in a way that a sight-impared editor can tell what it is? This would seem to indicate that when we must use such a character, that it should be encoded, not given as bare Unicode. Exactly the opposite is the current general practice. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
01:03, 30 October 2014 (UTC)
am I the only one who finds this excessive? Frietjes ( talk) 20:38, 7 November 2014 (UTC)
At the List of Seattle bridges FLC, a question occurred to me as I was reviewing it: in List of Seattle bridges the table is using bold and/or italics to call out if a bridge is a national/city landmark. Does that work for screen readers, or does it need to be a dagger/* after the year instead? -- Pres N 03:09, 20 December 2014 (UTC)
I've reverted the bold addition of the sentence "Likewise, do not switch between list marker types (e.g. asterisks and colons), unless embedding lists starting at the highest level." partly because it was not discussed beforehand, partly because the last clause is ambiguous. -- Redrose64 ( talk) 14:43, 6 January 2015 (UTC)
*'''Keep''' because etc.
*'''Delete''' because etc.
*:Comment on vote
*::Comment on comment
*'''Merge''' with X because etc.
There was no reason for you to revert me other than "discuss before adding", which means there was no reason for you to revert me.
The wording you removed specifically allows for nesting such as in your example ("embedding lists starting at the highest level"
). The problem addressed is the broken nesting of lists, such as:
*'''Keep''' because etc.
*'''Delete''' because etc.
**Comment on vote
:::Comment on comment
*'''Merge''' with X because etc.
-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 17:26, 6 January 2015 (UTC)
The link to the data table tutorial is useful, but there's no such link for layout tables. Do any examples exist anywhere? Xaxafrad ( talk) 07:27, 10 January 2015 (UTC)
The accessibility of {{ Tiny ping}} is being discussed. Please make your views known there. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 11:37, 31 January 2015 (UTC)
Please see T18691 Section headings should have some clickable anchor for passing links, particularly my comment there. Graham 87 15:05, 1 March 2015 (UTC)
@
Graham87,
Redrose64,
Plastikspork, and
Frietjes: I add {{
paragraph break}} into articles where <p>
is used inside footnotes. It will get removed because of "no consensus", even though the template says this is for accessibility reasons. If the template is important for accessibility, can this be added to Accessibility MOS page?
Bgwhite (
talk)
23:03, 9 May 2015 (UTC)
<p>
tag. Personally I would have named it
Template:Visual break, to show it's got nothing to do with paragraphs, but that's just me. Naturally, I'd support the use of this template over raw html that carries unintended semantics with it, and I'd support adding it to MOS:ACCESS. --
RexxS (
talk)
23:19, 9 May 2015 (UTC)
<li>...</li>
element; they are not semantically paragraphs. As far as a sighted editor is concerned, bundled references display just as well using <div></div>
to force a new visual line as they would using <p>
, so for the sighted, it shouldn't really matter which is used. I suspect though that a screen reader user might be initially confused by hearing a new paragraph announced for each bundled reference - I'd defer to
Graham87 on how annoying or confusing that might be, but I'm guessing he'll tell us it's not a big deal. I do understand your concern about load times - if you recall, we discussed this about the cite templates before they were converted to Lua. However, the {{
paragraph break}} template is extremely light-weight; I just previewed this page after adding 1,000 of the templates and the increase in load time was around a fifth of a second. So I wouldn't worry about load times in this case, as I doubt any article will be using enough bundled references for anyone to notice. James will always be concerned for translations when a new template is used on en-wp, and I share his concern when many our templates now depend on Lua modules, which complicates any attempt to port them to other languages. The good news here is that {{
paragraph break}} is an extremely simple template and can be copied into any language Wikipedia without having to worry about internationalisation or dependencies. It is a slow process to improve the infrastructure of small Wikipedias - I struggle on occasion trying to help porting into the Welsh Wicipedia, without speaking Welsh! - but it's worthwhile in the long run. Has any of that been any use in providing some perspective on the issues? Cheers --
RexxS (
talk)
01:31, 10 May 2015 (UTC)<p>...</p>
.
Bgwhite (
talk)
06:17, 10 May 2015 (UTC)
<p>
for bundled references, but I don't believe it's such a vital issue that it's worth getting into conflict with other editors who, in all good-faith, don't accept that it's a net benefit. Life's too short. --
RexxS (
talk)
10:15, 10 May 2015 (UTC)
Sarah (SV)... This has nothing to do with AWB editing or the pump discussion. AWB does not add the template, close with a </p>
or remove the <p>
in these cases. AWB will only remove <p>
if it is in open text (ie not in a template or ref tags) and replace it with a blank line. I arrived at the page due to a broken bracket and a template variable being used... {{{variable|arg}}}
. This was detected by CheckWiki. CheckWiki will
detect <p>
tags in open text, but does not check for <p>
inside template or ref tags. I added {{
Paragraph break}} manually days later after the AWB edit. Doc James removed them by saying get consensus. I then asked here if this was important enough to pursue.
Yes, it would make sense to fix the problem causing this issue. It took over eight years to fix this problem that was happening inside <blockquote>
and {{
quote}} type templates. It was only fixed because of VE. There is a
T57674 ticket open on this current problem, that I commented on in 2013. When I took over maintenance of CheckWiki in ~2012 and removed CheckWiki detecting <p>
where bugs were filed. I was only made aware of {{
Paragraph break}} and also the disability reasons around 8 months ago. I do not actively look for this and only add the template when I see an "issue".
Having User:RexxS and/or Graham comment at T57674 would be helpful... They pull alot more weight. Stating the problem does cause a disability issue may help in getting it fixed sooner rather than later. Bgwhite ( talk) 23:23, 10 May 2015 (UTC)
<p>...</p>
anyway. Semantically, bundled references ought to be a list (i.e. a nested list within the overall list of references), and the best way to mark them up would be to use an unbulleted list, {{
ubl}}. That would probably be optimal for screen readers and would display acceptably for sighted users:There are eight planets orbitng the sun in our solar system. [1]
The sun is pretty big, but the moon is not so big. The sun is also quite hot. [2]
The moon is most visible at night. [3]
- ^ Miller, Edward. The Solar System. Academic Press, 1999, p. 1.
- ^
- For the sun's size, see Miller, Edward. The Sun. Academic Press, 2005, p. 1.
- For the moon's size, see Brown, Rebecca. "Size of the Moon", Scientific American, 51(78):46.
- For the sun's heat, see Smith, John. The Sun's Heat. Academic Press, 2005, p. 2.
- ^ Miller, Edward. The Moon. Academic Press, 2009, p. 17.
I don't understand the logic of enabling short ones without controls. In my experience, short ones can be worse, because they can flash more often. In my experience, the transition between the ending frame and the startying frame tends to be the painful part, the rest tends to just be distracting. 71.191.163.95 ( talk) 20:33, 28 May 2015 (UTC)
You are invited to join a discussion: Complex tables cannot be made accessible in Wikipedia and what to do about it Thisisnotatest ( talk) 21:13, 7 June 2015 (UTC)
Under the "Bulleted vertical lists" section, at the end it states, "Do not separate list items with line breaks (<br>). Use one of the following methods." Problem is, it doesn't give any following methods. Bgwhite ( talk) 23:37, 8 July 2015 (UTC)
<br>
with: {{
plainlist}}/{{
unbulleted list}} if the list is to remain vertical; or consider {{
flatlist}}/{{
hlist}} if the list could be better rendered horizontally (in-line). I'll try to clarify that. Feel free to tweak if you can improve it --
RexxS (
talk)
00:32, 9 July 2015 (UTC)More input is sought at Wikipedia talk:WikiProject Accessibility#Expert review needed. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 15:36, 18 July 2015 (UTC)
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:29, 29 July 2015 (UTC)
any suggestions about what to do about [4] [5] [6] [7] [8] [9] [10] [11] [12] [13] ... ? Frietjes ( talk) 17:14, 26 July 2015 (UTC)
-- [[
User:Edokter]] {{
talk}}
17:28, 26 July 2015 (UTC)
Is there any reason nobody notified me ahead of time?@ Frietjes: All these are on my watch list, I didn't see any talk messages. That would have been nice. Wikipedia is full of styling, almost all navboxes for universities and other institutions of higher learning have a colored style. Below linked are examples of these. They have been this way for a long time, with no objection. I see no injury done by styling, and the styling I used was not arbitrary, each was representative of the symbols of their respective jurisdictions.
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)
I've reverted the rather WP:POINTy removal of the parenthetical wording from the colour-section's hatnote "This section is about the use of colors in articles (though the advice on contrast ratios is applicable more generally).". This, being part of WCAG, quite clealry applies to al web content, and there are incoming links from relevant discussions.
As noted at the head of the page:
The WMF's Non discrimination policy...
"is approved by the Wikimedia Foundation Board of Trustees to apply to all Wikimedia projects. It may not be circumvented, eroded, or ignored by local policies".and says:"The Wikimedia Foundation prohibits discrimination against current or prospective users... on the basis of... disability".
-- Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 15:54, 20 September 2015 (UTC)
@ BethNaught: It's worth noting that WP:ACCESS is kind of a weird guideline because it derives its "authority" from a WMF policy that cannot be changed via local consensus. No matter what we write in the guideline itself or decide as a community, inaccessible colors cannot be used anywhere on the project where alternatives exist, as the WMF's non-discrimination policy is clear that we must make the site accessible to all potential readers whenever feasible. That policy is preceded by a statement that local consensus cannot override or erode it in any way. It's always tricky where we have WMF policies conflict with our preferred dispute resolution method, but this is an area where consensus has a much lesser role than it does elsewhere. ~ Rob Talk 07:27, 23 September 2015 (UTC)
The Text section of this project page contains the following instruction:
Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is {{ †}}; see Category:Image insertion templates for more.
However, Category:Image insertion templates appears not to have any content and in fact bears the message "Note: This category should be empty."
So how does one get a handy list of Image insertion templates? And would whoever knows please be so kind as to update that item? Or else fix Category:Image insertion templates so it shouldn't be empty and isn't, if that is the actual problem.
Thisisnotatest ( talk) 06:40, 23 September 2015 (UTC)
It is a real improvement for screen readers when we replace pseudo-headings with real headings (usually ;Notes and ;Bibliography or similar in the ==References== section, when Harvard-style referencing is used). However editors often object to the cluttering up of the Table of Contents by these relatively 'trivial' level-3 headings. Often we can't use {{ TOC limit}} because there are other, 'important', headings at level-3 that ought to be in the TOC. In such cases, the best compromise has been found to mark up the pseudo-headings as bold. This delivers the visual distinction that the editors crave, while creating a minimal annoyance to screen reader users (they can have announcing bold/italic/etc. turned off). That means the screen readers can't navigate directly to the sub-headers (nor can anyone else!) because they are not marked up as headers, which is sub-optimal, but it may be the best we can achieve when the article editor is determined to achieve a particular visual appearance. -- RexxS ( talk) 21:57, 26 September 2015 (UTC)
I believe a table such as
COL | Colonel | LT | Lieutenant | SGM | Sergeant-Major | CPL | Corporal |
---|---|---|---|---|---|---|---|
LTC | Lieutenant Colonel | 1LT | First Lieutenant | 4SG | Fourth Sergeant | PVT | Private |
MAJ | Major | 2LT | Second Lieutenant | SGT | Sergeant | QM | Quartermaster |
CPT | Captain | CNT | Cornet | 3CPL | Third Corporal | AQM | Assistant Quartermaster |
straddles between being a data table (abbreviation and value) and a layout table (using multiple columns to save space). My reading is that this is not accessible, but it's not clear from the section on layout tables whether this is the case. Could someone clarify? Thisisnotatest ( talk) 09:12, 26 September 2015 (UTC)
scope="row"
is also used for the plainrowheaders style on Wikipedia.
nyuszika7h (
talk)
20:16, 27 September 2015 (UTC)
<th>...</th>
, and yet others would give preference to a cell marked as scope="row"
. Similar issues would affect column headers. So to maximise the chance of any particular screen reader using the cell we designate as the row/column header, we give the advice to mark up the column and row headers with both '!' and 'scope'. Redundancy never makes the issues worse and usually gives the desired result, even with older software. Hope that helps. --
RexxS (
talk)
21:32, 27 September 2015 (UTC)So it looks like Jaws correctly handles scope markups. What about other readers? Anyway, thanks for the explanation on the included table; perhaps removing scope from that table is the best move? Thisisnotatest ( talk) 05:19, 28 September 2015 (UTC)
Apparently this is just a publicity contest where I'm penalized for not being able to write in English. Anyway, I'd like to make a Dab solver tool (+ WP:DPL) for alt text. Automatic colorblindness is more uncertain (keep finding mistakes in papers), but we'd have something and hopefully more resources. — Dispenser 17:06, 27 September 2015 (UTC)
Wouldn't Windows-1252 symbols be unpronouncable to Mac or Unix screen readers? Would it be better to restrict non-imaged/non-templatized symbols to Latin-1? Thisisnotatest ( talk) 21:43, 26 September 2015 (UTC)
{{†|alt=wicket keeper}}
to mark the wicket keeper. It's sometimes good to use {{
Hash-tag}} in a similar way. Cheers --
RexxS (
talk)
23:07, 26 September 2015 (UTC)
Screen readers without Unicode support will generally read a character outside Latin-1 and Windows-1252 as a question mark, and even in JAWS, the most popular screen reader, Unicode characters are very difficult to read.
- Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
- Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
- Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
with:
Many screen readers will read most special characters as a question mark or not at all.
- Provide a transliteration for all text in a non-Latin writing system where the non-Latin character is important in the original context such as names, places, things etc.
- Do not use unpronounceable symbols such as ♥ (a heart symbol); use images with alt text instead.[1]
- Symbols that cause problems for screen readers may already have templates created to produce an image and alt text. An example is the dagger template † (see Category:Single-image insertion templates for more).
- Safe symbols to use without a template are any of the following: !£$%^&*()-=_+/@~#<>?\|{} as well as A through Z, a through z, and 0 through 9.
Thisisnotatest ( talk) 01:22, 27 September 2015 (UTC)
Visual Editor has decided that ordinals must be superscripted. I usually see a couple of non-VE edited articles a day using superscripts and today there were 20+ VE articles. Before I file a bug ticket only to have the ticket dumped on the backlog queue to never see the light of day again, I'd thought I'd add accessibility info. Maybe that would help fix the problem. Do screen readers have issues with superscripted ordinals..... 2nd vs 2nd ? Bgwhite ( talk) 06:38, 15 October 2015 (UTC)
<nowiki>
tags in refs (ie <ref><nowiki>{{cite web |.... }}</ref></nowiki> would be important to fix. Others bugs, such as Content Translator wikilinking dates, are a MOS issue on English Wikipedia and are not important. So, if the ordinal issue were accessibility rather than MOS, it might get fixed rather than be put on the backlog queue.
Bgwhite (
talk)
04:55, 16 October 2015 (UTC)
<cite>
tags (not templates) and whatever [[Paris|P]]<nowiki/>aris
and [[Rome|Rom]]<nowiki/>a
is supposed to be.
Bgwhite (
talk)
21:08, 16 October 2015 (UTC)Wikipedia:Manual of Style/Mathematics#Using LaTeX markup recommends using association list formatting to fake a visual indentation for mathematics formulae. Do you all think that it's worth changing this (e.g., to something that provides the visual cue but uses {{ indent}} or CSS formatting)? WhatamIdoing ( talk) 18:26, 15 December 2015 (UTC)
"More complicated formulas, or formulas used in more technical articles, are often better off with the default alt text."I don't know what genius thought that up, but I fail to see who would be better off with the default alt text of "\int _{0}^{\infty }e^{-x^{2}}\,dx." (as used in the example in Wikipedia:Manual of Style/Mathematics #Using LaTeX markup) rather than something like "integral from 0 to infinity of e to the minus x-squared dx". I'm tempted to just remove that sentence. -- RexxS ( talk) 00:40, 16 December 2015 (UTC)
<math display="block">
provides the indentation without adding odd spaces or list formatting.
WhatamIdoing (
talk)
18:49, 24 December 2015 (UTC)I can create a list from dump files that show which articles have a blank line inside an unordered list. The list must be done in wikicode. AWB can fix the vast majority of these cases. AWB will only fix if the the blank line contains only a newline. Any spaces or tabs before the newline and AWB won't fix. Is this a good enough idea to get bot approval? I'm sure there will people who complain, so I'd like to get all my ducks in a row. Bgwhite ( talk) 09:36, 24 December 2015 (UTC)
For your tinkering (and proving what it does to people who don't believe you) pleasure, I present:
<dl>
description/definition/association lists.— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 09:46, 26 February 2016 (UTC)
The role
attribute was whitelisted back in 2013, especially for use with layout tables (Phabricator
T26583 and
merge). I added a recommendation to use the role
attribute, as an extra precaution against screen readers interpreting them as data tables. Sorry if this was overbold!
Matt Fitzpatrick (
talk)
07:02, 12 April 2016 (UTC)
On this page, it says "Do not make pseudo-headings using semicolon markup and try to avoid using bold markup." But at Help:Punctuation#Semicolon, it says "A leading semicolon ‹;›, in column 1 of a line, causes the line to be displayed as a bolded, non-indexed section header." What resolves the contradiction? Stevie is the man! Talk • Work 20:21, 8 April 2016 (UTC)
<dt>
term inside a <dl>
description list. MediaWiki's default CSS bolds <dt>
elements, so to sighted users, ;XYZ
resembles '''XYZ'''
. To screen readers, though, yikes! Many, if not nearly all, screen reader users navigate pages by skipping from heading to heading, but <dl><dt>XYZ</dt></dl>
isn't read or navigated like a heading, it's read and navigated as a list.
Help:Punctuation should be changed; I'd consider this use of a semicolon in an article to be an accessibility error.
Matt Fitzpatrick (
talk)
10:54, 12 April 2016 (UTC)
'''foo'''
or <b>bar</b>
. If they want strong emphasis they can use <strong>baz</strong>
or {{
strong|quux}}
. If people want to indent something short, they can use {{
in5}}; if they want to do a block indent, they can use {{
block indent}}
, and should not abuse block quotation markup for that. Talk pages are kind of a lost cause at this point, but we should use better formatting in articles. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
00:41, 16 April 2016 (UTC)Please see
Template talk:Collapse top#RfC: Heading centered or left by default?, for a discussion that would affect the default text-align
of the headers/titles of various content-box templates. —
SMcCandlish ☺
☏
¢ ≽ʌⱷ҅ᴥⱷʌ≼
13:43, 19 April 2016 (UTC)
Please comment at Talk:Glossary of video game terms#RfC: Replacing pseudo-headers. -- Izno ( talk) 12:03, 27 April 2016 (UTC)
Please comment at Template talk:FlagIOCathlete#Option to move flag. The discussion is about adding template parameters to enable displays like the following, which in the second column reverse the position of the flag and country, simply for the sake of a mirrored visual effect:
Jane Smith | United States | vs. | France | Jeanne Deaux | ||
Xian Chen | China | vs. | Honduras | Juana Perez |
There may (or may not) be information architecture, usability, and accessibility concerns with this.
— SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 20:21, 7 June 2016 (UTC)
Where images requiring attribution are used in a decorative way, such as in Template:Portal bar where the images merely repeat the information in adjacent text, a conflict arises. The licensing requires a link, but best practice is empty alt text for decorative images and, by extension, no link. To help prevent irrelevant audible clutter interrupting the flow of text, I think the accessibility MoS should encourage the use of elements not requiring attribution (e.g. public domain images) for decorative use. Matt Fitzpatrick ( talk) 23:16, 20 June 2016 (UTC)
A user raised a concern at Talk:Lightning that one of the images on the page, File:Lightnings sequence 2 animation.gif, may violate the MOS for accessibility, particularly MOS:ANIMATION. Where is the best place to get an opinion on whether there are too many flashes in that GIF? — C.Fred ( talk) 23:51, 25 July 2016 (UTC)
A discussion regarding the use of {{ Flatlist}} or {{ Hlist}} in various music infoboxes is ongoing at Template talk:Infobox album#Harmonization with other music templates. Comments regarding their benefit are welcome. — Ojorojo ( talk) 13:25, 2 August 2016 (UTC)
MOS:LISTGAP says don't do this:
* Support. I like this idea. [[User:Example]] :: Question: What do you like about it? [[User:Example 2]]
Is that the same as doing this?
* Support. I like this idea. [[User:Example]]: : Question: What do you like about it? [[User:Example 2]]
An example of how this is used in TV articles is at Supergirl (TV series)#Cast and characters. -- AussieLegend ( ✉) 11:39, 13 August 2016 (UTC)
<ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a></li> </ul> <dl> <dd> <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl> </dd> </dl>
<ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a>:</li> </ul> <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl>
* Support. I like this idea. [[User:Example]]: *: Question: What do you like about it? [[User:Example 2]]
<ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a>: <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl> </li> </ul>
** Support. I like this idea. [[User:Example]]: :: Question: What do you like about it? [[User:Example 2]] ** Oppose. I hate this idea. [[User:Example3]]: :: Question: What do you hate about it? [[User:Example 4]] <ul> <li> <ul> <li>Support. I like this idea. <a href="/info/en/?search=User:Example" title="User:Example">User:Example</a>:</li> </ul> </li> </ul> <dl> <dd> <dl> <dd>Question: What do you like about it? <a href="https://en.wikipedia.org/?title=User:Example_2&action=edit&redlink=1" class="new" title="User:Example 2 (page does not exist)">User:Example 2</a></dd> </dl> </dd> </dl> <ul> <li> <ul> <li>Oppose. I hate this idea. <a href="/info/en/?search=User:Example3" title="User:Example3">User:Example3</a>:</li> </ul> </li> </ul> <dl> <dd> <dl> <dd>Question: What do you hate about it? <a href="https://en.wikipedia.org/?title=User:Example_4&action=edit&redlink=1" class="new" title="User:Example 4 (page does not exist)">User:Example 4</a></dd> </dl> </dd> </dl>
*First item of unordered list
*:Definition list nested inside first list item
*::Definition list nested inside definition list
*Second item of unordered list
*First unordered list
:*Unordered list inside definition list
::*Unordered list inside definition list nested inside definition list
*Second unordered list
"What we should have is probably..."
- Why not just:
* Support. I like this idea. [[User:Example]]: ** Question: What do you like about it? [[User:Example 2]]
-- ? Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 20:47, 13 August 2016 (UTC)
* Support. I like this idea. [[User:Example]]: : Question: What do you like about it? [[User:Example 2]]
* Support. I like this idea. [[User:Example]]:
*: Question: What do you like about it? [[User:Example 2]]
<dl>...</dl>
inside the first <li>...</li>
of the existing <ul>...</ul>
, which remains open for its second <li>...</li>
(not shown above). --
Redrose64 (
talk)
10:15, 14 August 2016 (UTC)
<br>
to get a new line. --
RexxS (
talk)
20:32, 14 August 2016 (UTC)@
Adamstom.97: "a single bullet for the actor and character name, followed by a single colon for the extra information"
- that's two lists, with one item each. Not good.
Andy Mabbett (Pigsonthewing);
Talk to Andy;
Andy's edits
13:42, 30 August 2016 (UTC)
I thought that this might interest some of you. Last year, Google started transcoding websites, including Wikipedia, to reduce page weight (and therefore the cost of reading and page loading time) for people using mobile devices with slow connections. There's some information on their blog. You can compare the results here:
It seems to remove Javascript as well as all images. (Also @ Guy Macon:, who has been interested in issues of page weight in the past). (Please ping me if you need my attention; I'm not watching this page.) Whatamidoing (WMF) ( talk) 08:36, 30 August 2016 (UTC)
Please see " Wikipedia talk:Manual of Style#RfC: What (if anything) to do about quotations, and the quotation templates?". Some specific accessibility issues have been raised about particular templates, and there's a test of a mild background shading to the default {{ Quote}} template. Please examine the entire RfC; someone later opened a "voting" section about one particular template, but it does not address the majority of the questions and concerns raised in the RfC. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 06:46, 11 September 2016 (UTC)
I've updated WP:MOS#Scrolling lists and collapsible content, the first major re-examination it has had in a long time (and much has changed, like the Google transcoding in Asian countries mentioned above at WT:ACCESS). Overview at WT:MOS#Updated "Scrolling lists and collapsible content" section, and diff here]. It's possible this updating may need to be reflected in MOS:ACCESS. It might even be desirable to move some of that into MOS:ACCESS and make the segment at the main MOS page shorter, though most of the additional material is footnotes. — SMcCandlish ☺ ☏ ¢ ≽ʌⱷ҅ᴥⱷʌ≼ 09:32, 11 September 2016 (UTC)
I have updated {{
Based on}} to use a Lua module which automatically uses {{
Unbulleted list}} for multiple writers rather than semantically incorrect line breaks which were previously recommended by the template documentation. Someone might want to run over existing transclusions with a bot and replace <br />
(and variations) with |
, i.e. use separate parameters for multiple writers.
nyuszika7h (
talk)
14:06, 13 October 2016 (UTC)
There is a discussion at WikiProject_Albums regarding headings. The advice is not to use basic mark up for MOS:DEFLIST type situations because "Screen readers and other machines can only use correctly formatted headings for navigation." A while ago I downloaded a screen reader to see what the issue was, the reader treated "==" and ";" formatted headings the same. I tried another one again today ( http://www.nvaccess.org/download/) and that is also fine. Is it the case that when the screen reader details were added (back in 2012 I think) that such readers couldn't deal with the ";" formatting, but they can now? Would it appropriate for a bunch of us to try out various screen readers to see what issues are created when using them while reading Wikipedia? SilkTork ✔Tea time 13:29, 13 November 2016 (UTC)
;The Beach Boys
followed by *
Al Jardine ...
, the html introduces a definition list, <dl>
; then gives a definition, <dt>
The Beach Boys</dt>
; but then closes the definition list <dl>
without ever defining anything! It then begins a separate bulleted list <ul>
<li>
Al Jardine ...</li>
, etc.===The Beach Boys===
followed by *
Al Jardine ...
(i.e. a heading followed by a bulleted list); or (2) ;The Beach Boys
followed immediately by :
Al Jardine
... (which makes a complete definition list). But half of one and half of the other makes no sense at all.But these lists are not meant to be in sections. Think of them like sentences: "The session musicians were Arnold Belnick on violin, Chuck Berghofer on string bass" but converted to a list to make reading easier, as described in WP:Def list, which says they are more accessible for screen readers. In the sentence "Do not make pseudo-headings using semicolon markup" I think there is a misunderstanding regarding what is meant by pseudo-headings. We don't advocate using pseudo-headings on Wikipedia. The sentence is being interpreted as meaning "do not use semicolon markup as this is unable to be read by screen readers". But I don't think the guide here is saying "don't use def list mark up", it is saying "don't do something [create "pseudo-headings"] that we don't do on Wikipedia anyway". I don't think we need a special accessibility instruction for something we don't advocate doing anyway. But we do need compatibility between guidelines, and some clarity on when and how to use def lists appropriately to help all readers. Personally I prefer prose, but I understand that most readers prefer some details to be presented in lists, and I can handle that. But we shouldn't be forcing association lists into section headings because that's going a stage too far, and making reading more awkward for all. SilkTork ✔Tea time 09:43, 14 November 2016 (UTC)
The lists in
Pet Sounds are clearly in sections (or sub-sections to be accurate) and if you're going to give them a (sub)heading, you ought to use a (sub)header.
WP:Def list says "Properly formatted definition lists are more
accessible to people using
screen readers ..."
. That's properly formatted definition lists, not a ';' on its own or mixed in with unordered lists. Are you able to read html? If you are, inspect the the following three examples:
Can you see that the first example has a section heading and one unordered list of four items? That the second example has one list (an association list) with an association term and four 'associations'? And that the third example has two separate lists: the first being an association list comprising an association term but no associations; and the second being an unordered list of four items?
Why would we want to tell someone using assistive technology that there are two lists in each section?
An association list <dl>...</dl>
is the only list in html that has its own in-built header <dt>...</dt>
to go with the list items <dd>...</dd>
. And we are sometimes misuse that <dt>...</dt>
to try to create headings for other sorts of lists (pseudo-headers), which are visually acceptable but which are never going to be read properly by screen readers because the underlying html is bolixed. That's why we have the advice not to use ';' for pseudo-headings. --
RexxS (
talk)
12:06, 14 November 2016 (UTC)
I'm not clear on what is intended to be meant by pseudo-headers. Does it mean "appropriate headings created using inappropriate mark-up", or "inappropriate headings created using inappropriate markup" or "inappropriate headings created using appropriate markup"? As this is an accessibility guideline I am assuming it means "appropriate headings created using inappropriate mark-up", in which case perhaps we should simply say that to avoid confusion. That would be a start. That we could guide people toward how they should be presenting the headings.
SilkTork
✔Tea time
11:15, 17 November 2016 (UTC)
Production
or this
Production:
It reads it as "Production list of four items link Bruce Botnick engineer..." which seems to me to be fine as the meaning will be understood. I don't see why we need to have in bold, as that doesn't necessarily assist meaning for a sighted reader. Personally I would prefer a prose sentence: "The production engineers were
Bruce Botnick,
Chuck Britz,
H. Bowen David, and
Larry Levine." But people like lists. We could have:
The production engineers were:
Guest musicians were:
Sessions musicians were:
Would that be acceptable? SilkTork ✔Tea time 12:22, 17 November 2016 (UTC)
<h3>...</h3>
, etc.). It can result in something that looks like a heading to a sighted reader, but which has no semantic markup available for assistive technology or for other automated tools. --
RexxS (
talk)
18:54, 17 November 2016 (UTC)==== Production ==== * [[Bruce Botnick]] – engineer * [[Chuck Britz]] – engineer * [[H. Bowen David]] – engineer * [[Larry Levine]] – engineer '''Production''' * [[Bruce Botnick]] – engineer * [[Chuck Britz]] – engineer * [[H. Bowen David]] – engineer * [[Larry Levine]] – engineer ;Production : [[Bruce Botnick]] – engineer : [[Chuck Britz]] – engineer : [[H. Bowen David]] – engineer : [[Larry Levine]] – engineer
big
headers. --
Jennica✿
talk /
contribs
05:32, 20 November 2016 (UTC)
<big>...</big>
tags are
obsolete in HTML5. They're not exactly against our
MOS:FONTSIZE, although better ways exist. On another matter, the section in question has {{
col-start}}
{{
col-break}}
and {{
col-end}}
- but these are rather pointless when there is only one column. --
Redrose64 (
talk)
10:31, 20 November 2016 (UTC)I identified an opportunity to improve the way that redirect information is presented at Template_talk:Redirect#Targeting_the_message. It was suggested that I mention the idea here in case it spurred interest from anyone is in the accessibility crowd. If so, feel free to pick up the discussion there, or here if more appropriate. -- Ed Brey ( talk) 17:26, 21 November 2016 (UTC)
I'm wondering wether {{ Legend}} is even compatible with WP:ACCESS. It's a template that allows the creation of color-based only legends with no other means to provide the same information. This seems to be in direct contradiction to the spirit of this guideline for obvious and logical reasons. So I question whether this template should be recommended, let alone used. Any thoughts? T v x1 20:51, 22 November 2016 (UTC)
Could somebody with more HTML/colour experience than I have weigh in at Talk:Dust Bowl#A map, at long last regarding the accessibility problems with {{ color sample}}? Thanks. Graham 87 15:55, 15 January 2017 (UTC)
The use of colored backgrounds for purely cosmetic purposes when {{ Episode table}} is used should be discouraged and forbidden when the background is darkened to the point that the descriptive text is forced to white. As when one prints the page readability can suffer due to printing being limited to either CMYK or grayscale only. An alternative would be to have the print export view disable CSS elements but that could affect the article layout. 101.98.165.25 ( talk) 01:41, 24 January 2017 (UTC)
comments at Talk:Upper East Side#listgaps are welcome. Frietjes ( talk) 16:03, 24 January 2017 (UTC)
@ TheDJ, Psiĥedelisto, Graham87, and RexxS:
The problem with listgaps, as I understand it, is that blank lines, which are often meant to provide some visual clues to list structure,
But the HTML <br>
tag can produce the same sort of visual break without introducing any actual (as far as code can tell) blank lines. And so it occurred to me that it might be wise to suggest this tag in
MOS:LISTGAP as a way to add gaps for visual readers without hindering screenreader users. I started to draft an alternative version of that section in my userspace, and realized further that even without mentioning <br>
, the section would benefit from showing the display of each acceptable ( ) and not acceptable ( ) example and not just the wikicode.
Wikipedia:Manual of Style/Accessibility § Bulleted vertical lists says
<br>
). Use {{
plainlist}} / {{
unbulleted list}} if the list is to remain vertical; or consider {{
flatlist}} / {{
hlist}} if the list could be better rendered horizontally (in-line) as described in the following two sections.But I believe that that refers to using <br>
to visually simulate a vertical list, and for exactly the same reason that I'm suggesting it to visually simulate a gap: that it has a visual effect but not a semantic one.
My draft is in User:Thnidu/Draft: Safe blank lines. I added new paragraphs in boldface, then (facepalm) realized that that probably doesn't help anyone using a screenreader, so I wrapped my additions in plaintext labels "[BEGIN ADDED]" and "[END ADDED]". I haven't expanded all the examples, but if people think this is a good idea, the additional expansions would be pretty obvious to implement.
Please {{Ping}} me to discuss. -- Thnidu ( talk) 02:10, 1 February 2017 (UTC)
<br>
to your last example, and 2) even adding it makes no difference to the display on my screen. However, adding two <br>
s does add extra space. I suspect that different browsers will interpret <br>
differently. —
Gorthian (
talk)
03:27, 1 February 2017 (UTC)
There's some accessibility issues for the Chart module. We need some focus on CSS override and print-ability. — Dispenser 05:55, 6 February 2017 (UTC)
Maybe I'm being dumb, but can someone advise how to apply this template without inadvertently setting the Table of Contents above the Lead? I just experimented at Revolver (Beatles album), ended up with this. Thanks, JG66 ( talk) 16:47, 7 February 2017 (UTC)
{{
TOC limit|3}}
must be the last item in the lead section - you were putting it between infobox and introductory text. The easiest way to do this is to first ensure that you have "Add an [edit] link for the
lead section of a page" enabled at
Preferences →
Gadgets. Then edit the lead section of the article, and in the edit box, go to the very end of the text. Add the {{
TOC limit|3}}
on a line of its own, and save. --
Redrose64 🌹 (
talk)
17:05, 7 February 2017 (UTC)
Hello, all. I re-started a discussion at the reflist template a little while ago, to see if we could improve accessibility on different screen widths/font sizes. I think that RexxS has a solid solution in that template's sandbox. It's a very widely used template, so I really don't want to screw this up or have to make more than one change. If there's anything else that ought to happen here, or if you have any thoughts on the change, could you please join the discussion over there and let us know? Thanks, WhatamIdoing ( talk) 21:16, 20 February 2017 (UTC)
From a recent Tech news:
"You will be able to show references from
<references />
tags in more than one column on your wiki. This is the list of footnotes for the sources in the article. How many columns you see will depend on how big your screen is. On some wikis, some templates already do this. Templates that use<references />
tags will need to be updated, and then later the change can happen for all reference lists. [14] [15]"
— Preceding unsigned comment added by Pigsonthewing ( talk • contribs) 21:09, 20 March 2017 (UTC)
this is a giant leap backward for accessibility. we have spent so much time taking infoboxes that use <br>
to delimit years, teams, caps, ... and convert them to use number-suffixed versions for
WP:ACCESSIBILITY. now,
Primefac has reversed this progress on
Template:Infobox rugby union biography and from all the safesubst: it looks like the intention is to make this permanent. for
Template:infobox football biography we had transition code to support both syntax forms to allow for the conversion to the accessible version. we should do that for
template:infobox rugby biography as well, and not step backward in time.
Frietjes (
talk)
18:41, 20 March 2017 (UTC)
|history=
parameter was better than numbered histories. If this is indeed not the case, I will happily go back to the sandbox. I'm just slightly annoyed that the template has been ready for merging for almost two weeks and only after I start substing does anyone say anything.
Primefac (
talk)
18:45, 20 March 2017 (UTC)