Wikipedia talk:WikiProject Accessibility

1. 
2. Collaborations
3. WikiProjects
4. Accessibility

About merged cells in table

I was recently highlighted to accessibility issues with regards to merged cells in tables, particularly with regards to WP:DTT. I like to ask, using a similar example, Jordan Chan#Film and television, the filmography table contain merged cells for the year. It was deemed not accessible to screen readers and using this example, to unmerge and listing each year individually for each row. In terms of accessibility, should the years be left unmerged?

I searched the archive but what I found is about more complex tables with nothing on this common merging of years. If I had misread or missed out, appreciate if someone can point me to the correct archive for my question. Thanks! Justanothersgwikieditor (talk) 01:41, 20 September 2022 (UTC)

@Justanothersgwikieditor: Merged cells like this aren't a problem for screen reader users. I see that at User talk:Justanothersgwikieditor/Archive 2#Do not merge cells, Treysand mistakenly cited this section of the data tables tutorial (which is not a guideline), but that section refers to tables *within* tables (i.e. two table tags inside each other in the HTML), not row/colspans, as clearly described at the cited source. Graham87 06:44, 20 September 2022 (UTC)

@Graham87 : Thank you for your explanation but I must admit that initially I missed out the section linked by Treysand and my understanding of nested tables to be quite different. Hence I am asking for clarification here. Once again, thanks! Justanothersgwikieditor (talk) 06:57, 20 September 2022 (UTC)

@Justanothersgwikieditor: Take it from me - if Graham87 says there is no problem, you can rest assured on that 100%. --Redrose64 🌹 (talk) 20:12, 20 September 2022 (UTC)

Discussion of Strong template on its talk page

There is a continuation of the discussion of the proper usage of the Strong template with respect to the Lead section and the name and aliases of the article subject. A change was made to the documentation today that a) removed the instruction on how and why to use it and b) made a note that there is no consensus to use it in the Lead, with a citation.

I think the lack of widespread usage of this template, and the Em template, may have something to do with it not being in the MOS examples when it should be used, eg. MOS:LEAD. It's not enough to make a comment in the template documentation. If this is an accessibility issue, and it is, then using it should be a clear yes. However, I used it recently in a Lead of an article I have been working with, and a long-time editor removed that change. – Elizabeth (Eewilson) (tag or ping me) (talk) 14:53, 10 November 2022 (UTC)

@Eewilson: I've left a comment over there. You're right; leaving a brief comment on accessibility on a template's documentation is useless if it's all but an orphan, with no mentions of its apparent importance in the Very Big Very Important Please Look Here Manuals of Style we have. Who's going to discover such templates frequently enough to make that worthwhile? Only editors digging around in the Template undergrowth are going to discover them that way.—Ineffablebookkeeper (talk) ({{ping}} me!) 17:11, 10 November 2022 (UTC)

New calendar template

Calendar for year with 1 January on a Sunday

2023
Date					Jan	May	Aug	Feb	Jun	Sep	Apr
					Oct			Mar		Dec	Jul
								Nov
1	8	15	22	29	Sun	Mon	Tue	Wed	Thu	Fri	Sat
2	9	16	23	30	Mon	Tue	Wed	Thu	Fri	Sat	Sun
3	10	17	24	31	Tue	Wed	Thu	Fri	Sat	Sun	Mon
4	11	18	25		Wed	Thu	Fri	Sat	Sun	Mon	Tue
5	12	19	26		Thu	Fri	Sat	Sun	Mon	Tue	Wed
6	13	20	27		Fri	Sat	Sun	Mon	Tue	Wed	Thu
7	14	21	28		Sat	Sun	Mon	Tue	Wed	Thu	Fri

The above calendar-table is produced by {{One page calendar}}, which I have just published (the template will generate a calendar for any Gregorian year). How would you improve its accessibility? Feel free to edit the Lua module directly. Andy Mabbett (Pigsonthewing); Talk to Andy; Andy's edits 16:47, 11 November 2022 (UTC)

I can't make head or tail of it on either JAWS or NVDA ... and I honestly have no idea how to even start making it more intuitive for screen reader users, if that's even possible (my HTML table knowledge is about a 2 out of 10 and my lua knowledge is about a 0.002). The unusual month order is a problem, for a start, let alone trying to figure out what the columns and rows mean. I'm obsessed with calendars to the point that I once wrote date calculation functions in the JAWS Scripting Language, for which it is absolutely not designed, and even *I* can't understand this template. My friend Codeofdusk, who's also blind, can't either; he told me that he just doesn't have the spacial reasoning skills to process it. I'm just not sure that a one-page calendar is really the best idea for general use; {{Calendar}} is perfectly accessible. Graham87 03:22, 12 November 2022 (UTC)

"Click" versus "select" in technical writing

Users with disabilities have different options for interacting with a user interface. They can use a mouse device, trackpad, touchscreen, voice, and possibly more. Because the word "click" is traditionally associated with a mouse, some technical writing style guides now say that "click" should be used only for mouse devices, while a more generic word such as "select" should be used if the device is not known. For example, assuming that users have different ways to interact with a program, we could ask users to "select" a button, menu item, or keyboard key. A substantial effort would be required to revise documentation in this way. The question is: Will this effort bring significant value to users? Do users with disabilities want to see "click" replaced with "select"? 2600:8800:7109:1500:81D0:8BA1:BCA6:46FB (talk) 22:06, 28 November 2022 (UTC)

Speaking only for myself, I think it's a relatively minor issue. Graham87 06:04, 29 November 2022 (UTC)

Is Template:switcher WCAG-friendly?

I was wondering, whether {{switcher}}'s use on Tennis Masters page causes any issues with screen readers. Qwerty284651 (talk) 18:28, 10 December 2022 (UTC)

It's fine with screen readers because it's just a standard radio button. I didn't know that was even possible with wikitext, though. Graham87 03:23, 11 December 2022 (UTC)

Yes, it's possible with wikitext. See here. Note: the two parameters data-switcher-label-style and data-switcher-top-choices listed in the "Testing nee features" subsection are not in the live gadget code at MediaWiki:Gadget-switcher.js so they cannot affect the gadget. Don't know how much this info is useful, but decided to share it anyway, in case you planned on using it. Qwerty284651 (talk) 03:47, 11 December 2022 (UTC)

There is a related discussion at Template talk:Switcher#TOC not working with switcher with subsections. --Redrose64 🌹 (talk) 09:36, 11 December 2022 (UTC)

@Redrose64, I am the one who started that discussion.Qwerty284651 (talk) 14:30, 11 December 2022 (UTC)

Wikipedia:Mobile communication bugs listed at Requested moves

A requested move discussion has been initiated for Wikipedia:Mobile communication bugs to be moved to Wikipedia:Communication bugs. This page is of interest to this WikiProject and interested members may want to participate in the discussion here. —RMCD bot 19:49, 16 January 2023 (UTC)

To opt out of RM notifications on this page, transclude {{bots|deny=RMCD bot}}, or set up Article alerts for this WikiProject.

Non-Scrolling Sidebar

Wikipedia now uses a non-scrolling sidebar, which can trigger motion sickness and migraines if users scroll. If users have already blocked "smooth" scrolling, some workarounds are to 1. only navigate using page down, and/or 2. in Firefox or a few other browsers, reduce the frame rate; since Firefox prefs also use a non-scrolling sidebar, they ose the same problem. I think *if* Wikipedia is going to use a non-scrolling sidebar, then rather than requiring users to avoid the mouse and/or adjust browser settings, it should have an easily-discoverable button to hide the sidebar, which does not use its own animation when hiding or showing the sidebar. 173.73.0.102 (talk) 21:38, 20 January 2023 (UTC)

P.S. Even at only 1 frame/second, it can be disorienting. 173.73.0.102 (talk) 21:50, 20 January 2023 (UTC)

P.P.S. Okay, it has the hide button. Even so, it can cause severe motion sickness *before* people notice that it won't scroll and needs to be hidden. 173.73.0.102 (talk) 21:59, 20 January 2023 (UTC)

The hide button doesn't work in eink-browser. 173.73.0.102 (talk) 04:37, 23 January 2023 (UTC)

Let's remove "disorder" language

Hi. I noticed there are plently of templates with the label "disorder". I strongly suggest editing those templates to remove such label. For example, instead of "bipolar disorder" it should read only "bipolar". "Borderline personatiy disorder" should be "borderline personality". And so on.

Psychiatry tends to categorize as disorder anything that it doesn't like, ignoring the likelihood that they are not disorders at all but different ways that the brain has to work. Also, Psychiatric diagnosis many times are completely unscientific and tend to do a lot of harm to some people in their self-esteem, career, social life, and even desire to live.

You can check the article Neurodiversity and Psychiatric survivors movement for more context. Regards, Thinker78 (talk) 16:50, 24 January 2023 (UTC)

References

Recent Article layout changes make navigation very slow for visually impaired using screen magnification!

Tracked in Phabricator
Task T328480

I have used assistive tech (text-to-speech screen reading and screen nagnification) for over 25 years. Wikipedia articles appear to have been reformatted such that the Contents panel (that typically formerly appeared after the headline article summary) has disappeared. As a severely visually impaired user (registered Blind in the UK in 1995) I have used my residual vision to quickly find the article section of interest. All articles I have accessed in the past week (since late January 2023) omit the Contents panel and hence either require me to scroll through the article or instigate a search to possibly find where my interest lies. This is very inefficient when having to use x5 magnification on a 24" screen! In the words of UK's 'Points Of View'.... "Why, oh why....?" did you have to break something that did not need fixing?....IMHO, of course.

Please bring back the shortcut-embedded Contents panel!

Sincerely,

PVR. 31/01/2023 86.20.143.27 (talk) 10:29, 31 January 2023 (UTC)

This is the new :Vector 2022 skin. There are instructions for going back to the old skin in the above link. If you'd like an account so you can go back to the old look, you can email me at grahamwpgmail.com and I can help set one up for you (and help you bypass all the CAPTCHAs. It does indeed have a new table of contents but I have no sight at all and don't used the skin so I don't know how to help you use it. Graham87 15:24, 31 January 2023 (UTC)

Hi, PVR! I'd suggest creating an account so that you can switch to the old skin and save that preference; Graham87 has given the instructions above. If you don't want to create an account, however, the Table of Contents is hidden inside a pop-up that can be opened using a hamburger button next to the page title. This is the case for screens smaller than 1000 pixels post-scaling (that is, after the page has been resized due to zoom). It seems that the accessibility of this has been questioned in the past, but no concrete solution has been found as of now. I'll copy over your message to the related issue report to give it more visibility, both to other users and to the Wikimedia Foundation employees working on the new skin. Chlod (say hi!) 17:54, 31 January 2023 (UTC)

On second glance, the linked task might only be related, not exactly the root of the issue. I'll see if this warrants a new task (should no other task for this exist) and update accordingly. Chlod (say hi!) 18:05, 31 January 2023 (UTC)

I've created this Phabricator task to investigate and track this specific issue. Feel free to leave comments there, especially with your (i.e. anyone reading this') experiences with the new table of contents. Chlod (say hi!) 18:48, 31 January 2023 (UTC)

I've just had more of a play with this using the information in the Phabricator task up above with JAWS and NVDA. In JAWS the button to get to the table of contents is called "Unlabelled button 0" and in NVDA it's read out as "Menu button". This is not exactly ideal. Graham87 02:18, 1 February 2023 (UTC)

Thanks for filling that task and testing this out! I've sent a response in phab saying the same thing, but the missing label is definitely a regression and we will be fixing that soon. I also mentioned a few related tasks (i.e. adding a notice when the ToC is moved, ensuring the ToC is always accessible via navigation region) that the team would like to implement that should help with the concerns brought up here. Let me know if you have any other questions! BWang (WMF) (talk) 16:32, 3 February 2023 (UTC)

HTML tags like ins

I've just come across the <ins> tag; WP:REDACT states that "Any inserted text should be marked with <ins>...</ins>, which renders in most browsers as underlined text, e.g., inserted".

Does the text read out in a screenreader as having been inserted? Or is it relying on the presence of a visual underline, with no semantic features, to communicate that text has been inserted?—Ineffablebookkeeper (talk) ({{ping}} me!) 20:12, 31 January 2023 (UTC)

@Ineffablebookkeeper: The <ins>...</ins> and <del>...</del> tags have been part of HTML since HTML 4.0 (they were proposed for HTML 3.0 but didn't make it into the HTML 3.2 specification), which means that they have been supported by browsers for over 25 years. The present HTML 5.2 spec may be found at either W3C Recommendation, section 4.6 or WhatWG HTML Living Standard, section 4.7.

Compared to non-semantic purely visual methods like underline and strikethrough, there are at least two benefits to using the ins and del elements: (i) they have semantic meaning - screen readers will call them out as insertions and deletions; (ii) they may enclose block elements such as lists and tables. They are, in fact, the only HTML elements which may both enclose block elements and be enclosed by inline elements. --Redrose64 🌹 (talk) 22:37, 31 January 2023 (UTC)

Both the main Windows screen readers, JAWS and NVDA, now support reading out ins/del elements. Graham87 02:26, 1 February 2023 (UTC)

It's also supported by VoiceOver/Safari on iOS (but not on macOS yet) —TheDJ (talk • contribs) 12:32, 3 February 2023 (UTC)

Good to know all of this; I might add this to MOS:ACCESS and the relevant wikiguides that mention these tags. Thanks!—Ineffablebookkeeper (talk) ({{ping}} me!) 11:18, 4 February 2023 (UTC)

More Realistic Text to Speech - TorToiSe

Recently an open source text-to-speech engine called TorToiSe was released -- repo here -- that has much more realistic prosody (pacing, intonation) than previous TTS. The main downside is it is more computationally intensive to create recordings, about maybe four to eight hours per article on a midrange ($500-1000) GPU. I've been toying around with it, having it read Wikipedia articles, which you can listen to here as a podcast RSS feed of mp3 files. As part of that I've also been working with a few python text processing libraries to "normalize" the speech, that is, to make it easier for a TTS engine to read it without mistakes, which you can see at this github repo. The repo also has scripts to facilitate setting up a system to have TorToiSe read them. That is still a work in progress that I'm chipping away at when I have time. I just wanted to mention it someplace wikipedia-ish in case it is of interest to anyone, and to point others to it as something to be thinking about. At right this moment, TorToiSE seems to be at a sort of an odd place significantly beyond the fast-but-robotic TTS of the past, but not quite 100% to the point of a human. It seems easy to imagine, though, that in the coming years it, or something like it, could be used to generate placeholder audio files for the many unfulfilled Spoken Wikipedia Requests, until they can be read by a human. James Betker, the guy who wrote TorToiSe as a hobby is now working at OpenAI, so likely at some point there will be a more refined (and hopefully faster, and still open-source) version out in the world. xenotrope (talk) 06:51, 3 February 2023 (UTC)

Are you familiar with Wikispeech ? User:Sebastian Berlin (WMSE) knows quite a bit about it and might have some interest. —TheDJ (talk • contribs) 12:24, 3 February 2023 (UTC)

Thanks for the info (and the ping). Something to keep an eye on for Wikispeech. Hopefully we can add it as a TTS engine when it's fast enough. Sebastian Berlin (WMSE) (talk) 14:20, 3 February 2023 (UTC)

Is there a working demo for Wikispeech? I did look at it a few days ago, and again today. Just seems to be a single demo page that said "Could not load audio" when I clicked play. xenotrope (talk) 22:44, 3 February 2023 (UTC)

My personal Wikipedia timeline

I've made a personal timeline of my Wikipedia activities, which might interest some editors here because I've written about the various accessibility challenges I've had on this site over the years, among other things. Graham87 12:51, 13 February 2023 (UTC)

Your suspicions were correct. Merci, amigo. ―Justin (koavf)❤T☮C☺M☯ 19:44, 13 February 2023 (UTC)

I've only read down to the bottom of the "Early technology access and encyclopedic experiences" section, but it's a pretty good read so far. --Redrose64 🌹 (talk) 12:03, 14 February 2023 (UTC)

Thank you Graham. That's very insightful and what a great idea to write something like this down ! —TheDJ (talk • contribs) 13:21, 14 February 2023 (UTC)

Wikipedia is now blocking Lynx

Lynx (web browser) is a browser used by blind people. In March 2023 I found I can no longer read Wikipedia with Lynx because somebody has configured Wikipedia servers to hang indefinitely on any browser connection that identifies itself as Lynx, probably because they were given mistaken advice that Lynx is a hacking tool or something. I have to set my browser to lie about what it is, which is not good practice and it makes me feel guilty about lying. Could somebody please look into this and consider unblocking the Lynx browser for accessibility, many thanks. 80.44.31.71 (talk) 08:40, 2 March 2023 (UTC)

I don't know of a single blind person who uses Lynx these days. They all use modern browsers. It's not even mentioned in the latest this screen reader survey by WebAIM. Graham87 15:05, 2 March 2023 (UTC)

I use Lynx. WebAIM's survey is quite small and likely has a US bias. They also chose to group a bunch of browsers into an "Other" category instead of listing them. 80.44.31.71 (talk) 00:22, 3 March 2023 (UTC)

Hi IP — I've just navigated to this page using Lynx (2.9.0dev.6, SSL-MM 1.4.1), so it doesn't appear to be an issue targeting Lynx at the very least.. — TheresNoTime (talk • they/them) 15:10, 2 March 2023 (UTC)

it's working for me again now as well. Maybe they fixed it, thanks 80.44.31.71 (talk) 00:22, 3 March 2023 (UTC)

Problem with text to speech

I use Microsoft Edge, and it has a text to speech option to read me articles, but it keeps mentioning the numbers of the sources, which is really irritating. I hope someone can help me here, since this is probably a problem for people with disabilities too. I would be grateful for a solution :) Ramka8707 (talk) 14:49, 2 March 2023 (UTC)

@Ramka8707: To remove the footnote numbers you can use User:Zhaofeng Li/RefToggle. Most blind people would get used to the footnote numbers. Graham87 15:28, 2 March 2023 (UTC)

Honestly, it is quite shocking to me that people with disabilities have to deal with this stuff. Can I somehow escalate this to a higher authority that could potentially change the footnote problem? Thanks for your help so far :) Ramka8707 (talk) 16:49, 2 March 2023 (UTC)

@Ramka8707: I guess so ... see How to report a bug ... but whether it will be acted upon is another matter entirely. Blind people have as much of a right to follow footnotes as anyone else. Most of us use screen readers, which give far more control over how text is spoken/output to a refreshable Braille display than any browser's in-built text-to-speech feature ever could. Graham87 01:14, 3 March 2023 (UTC)

Of course blind people have a right to follow footnotes, never said they don't, but when it comes to accessibility it would really be a great feature, if one could simply deactivate the footnotes in order to let text to speech operate, no? Thank you for the link :) Ramka8707 (talk) 07:45, 3 March 2023 (UTC)

To operate effectively on the web and life in general, blind people and heavy text-to-speech users have to get used to way more than the occasional errant number. Graham87 13:57, 3 March 2023 (UTC)

You are quite right, but we got to enact change wherever we can, right? Anyway, don't want to tie you down with my silly war here. Thank you again for the help you have given me. I am kind of new, so it feels really cool to have such good help straight away :) Ramka8707 (talk) 22:55, 3 March 2023 (UTC)

@Ramka8707: The MediaWiki software (which is what converts Wiki-markup into usable web pages) does its best to produce web pages that comply with the published recommendations for HTML. The web browser vendors should be writing their browsers in such a way that web pages are presented in a predictable manner according to those same standards, but they don't always do so. Microsoft are notorious for deviating from some of the practices that other browser vendors follow reliably. Sometimes the MediaWiki software will reluctantly introduce adjustments to handle browser quirks, and it can be a real nightmare for the developers to keep up to date with changes in published recommendations and changes in browser behaviour (there are many available most of which change several times a year), as well as ensuring that accessibility aids behave as they should. Third-party add-ons similarly need to keep up with the latest changes, but they can give a more satisfactory experience than a browser's inbuilt features.

The numbers in square brackets that are also linked and superscripted are, as far as web browsers are concerned, exactly that - they have no special meaning; they are just links to another part of the same page. Browsers don't know what references are, but they do know how to handle links; and to permit a link to be followed, they need to present the text within the link, and to distinguish one of these links from another, the MediaWiki software uses numbers.

If you really want to suppress all of the superscripted linked numbers in square brackets, you can do this by placing this CSS rule

sup.reference { display: none; }

into Special:MyPage/common.css and saving it. However, this means that you will also suppress the links to the article's sources, although the sources will still appear elsewhere on the page. --Redrose64 🌹 (talk) 22:01, 3 March 2023 (UTC)

You're completely right about your points. As someone who is sighted, I'm contemplating how easily individuals with disabilities or their family members can access the information you've shared to improve their Wikipedia experience. Have you ever considered why there isn't a readily available "FAQ" with the essential resources? You and I are aware that most people tend to leave after a few clicks, since they haven't learned to navigate this space effectively. I appreciate the work you do, but I'm slightly frustrated (which isn't your fault, I know you do great work, I saw your account). Ramka8707 (talk) 23:20, 3 March 2023 (UTC)

Also this question was first posted at the teahouse. Graham87 01:21, 3 March 2023 (UTC)

Strobing Animations

Some wikipedia articles include non-stop autoplaying gifs and/or pngs. It's usually posible to configure desktop browsers to block these. But it's not always possible to configure tablet browsers to block these.

I often use eink due to neuro issues, and with text and static images it helps, but unless I set a blurry "a2" display mode, with animation it starts rapidly flashing between white and black.

The current MOS is inadequate (and feels insulting) because it permits animations if they're no longer than 5 seconds (which is far too long) or or if they have control functions to turn them off (which may not be visible and/or operable in the middle of the blinding pain if you are even mildly affected).173.73.0.102 (talk) 06:23, 6 March 2023 (UTC)

This is (or should be) covered by MOS:ANIMATION. --Redrose64 🌹 (talk) 19:41, 6 March 2023 (UTC)

User has now raised the issue at Wikipedia talk:Manual of Style/Accessibility#Animations Aren't Safe, Especially on E-Ink. --Redrose64 🌹 (talk) 14:54, 13 March 2023 (UTC)

Accessibility specifically in editing Wikipedia?

Are there any resources, where I can learn about accessibility issues specifically for users who edit Wikipedia? For example, do some users have trouble using source editing vs. WYSIWYG editing, the Preview button, or edit summaries? What do I, as a Wikipedia editor, need to know about the challenges that my comrades might face? Mgnbar (talk) 22:21, 20 March 2023 (UTC)

There's a bit at m:WikiBlind User Group#Getting started as a blind editor which I helped out with. Graham87 07:53, 21 March 2023 (UTC)