qgil wrote on 2014-04-21 05:12:47 (UTC)

@twkozlowski, it would be great if you could reply upstream.

https://secure.phabricator.com/T4843#4

"Is this a hypothetical concern, or do you have users who use screen readers who are reporting difficulty with the software? If you do, we'd love to hear about exactly what they're having trouble with.

I think we can probably fix this stuff pretty easily (e.g., we have a small total number of non-textual navigational elements, they're just fairly prominent), but if we don't actually have any users using assistive technologies guiding us through the issues and telling us when we've provided satisfactory fixes, I worry we're sort of just flailing around. I would guess that there are a lot of non-obvious, easy-to-fix things that we'll never catch without direct feedback from the affected users. For example, the way the dialog interaction works might be quite bad -- and is probably very easy to fix -- but implementing WCAG/WAI or similar won't guide us to that."

twkozlowski wrote on 2014-04-21 10:52:35 (UTC)

Thanks @Qgil, I added a comment upstream.

qgil wrote on 2014-04-30 14:19:32 (UTC)

Moving to "Not critical for the RfC" because upstream is taking this problem seriously (priority "Normal" and a first patch under review exists already). @Graham87's reports in Phhabricator itself suggest that, even if Phabricator is lacking and confusing in some aspects, overall is usable with assistive technology.

qgil wrote on 2014-05-13 18:41:37 (UTC)

@Graham87, could you help us identify the specific blockers for our Wikimedia Phabricator Day 1 release? We are looking specifically at accessibility regressions: problems in Phabricator that are not an issue in Bugzilla.

graham87 wrote on 2014-05-15 00:07:15 (UTC)

@Qgil: the most serious problems have been fixed (i.e. the inability to gt to the settings dialogue with screen readers). The main problems as far as I can tell are with form fields, which are being worked on upstream ... I wouldn't say they were *blockers* to Fabricator being implemented for MediaWiki, however.

qgil wrote on 2014-05-15 16:50:49 (UTC)

Thank you, @Graham87. It is good to know that the current situation is not a blocker for Day 1. For what is worth, I'm following the task upstream.

Related: "Display Preferences" will offer an item "Accessibility: Use High Contrast Colors" after our next code pull (upstream https://secure.phabricator.com/T8614, https://secure.phabricator.com/D13363 )

Pale Moon 25.6.0 and Firefox 41 have implemented a font icon fallback (Bug 789788) for the "Allow pages to choose their own fonts" option.

@jayvdb has proposed this task at T135327: Decide Phabricator improvements to be funded by WMF Technical Collaboration, but it is unclear here or in the related upstream task what would need to be done exactly. Since we are talking about funding a task, such details are required.

In T109#2307844, @Qgil wrote:

@jayvdb has proposed this task at T135327: Decide Phabricator improvements to be funded by WMF Technical Collaboration, but it is unclear here or in the related upstream task what would need to be done exactly. Since we are talking about funding a task, such details are required.

That would be @Jay8g, not me, I think. I do endorse that suggestion, but dont want to do the extra work required... ;-)

What is unclear? The Phabricator developers could study https://www.mediawiki.org/wiki/Accessibility_guide_for_developers (and the standards it references) and implement what's missing.

In T109#2307898, @Nemo_bis wrote:

What is unclear?

Making upstream developers go through some generic list is not a good use of time and money.
This task requires reporting issues experienced by a person in order to be actionable. Upstream has explained already that they are interested in solving specific actual problems but not "X does not conform to standard Y".

A short list of things I immediately found using VoiceOver:

1. I get no indication for the interactive elements of notifications (in the top bar)
2. The search options dropdown has no label
3. After opening the dropdown with voiceover, I can't close it.
4. The subtitles in the search options dropdown are skipped
5. The icons in front of elements in the dropdown of search are read as text
6. The remove button for actions in "Take Action" does not have a label indicating its function
7. The same for the x on the label of users and project tags
8. The icons in front of tags are read as 'text' and don't have a label
9. There is meaning to the color of tags, but this is not communicated (in this case could probably be as simply as pronouncing the color)
10. The modal dialogs do not carry a role identifying them as dialogs
11. When opening a modal dialog, your focus jumps you straight to the submit button. User has no indication that a dialog has opened.

There are probably a ton more.

That is helpful. Thank you a lot, TheDJ!

• Tokenizer is difficult to use with VoiceOver
• Policy dropdown is hard to use with VoiceOver
• Project tags are missing information with VoiceOver

tasks have been created in upstream.

This project is selected for the Developer-Wishlist voting round and will be added to a MediaWiki page very soon. To the subscribers, or proposer of this task: please help modify the task description: add a brief summary (10-12 lines) of the problem that this proposal raises, topics discussed in the comments, and a proposed solution (if there is any yet). Remember to add a header with a title "Description," to your content. Please do so before February 5th, 12:00 pm UTC.

Just a small clarification:

Can a people really having accessibility issues help here? I ask that, since I tried to proactively fix things in the past, but then a blind friend of my insulted me heavily, because I was implementing alternative text "by feeling", without realizing that, the more alternative texts I was implementing, the more the screen reader was reading aloud unuseful stuff.

Turning into concrete:

Nothing ever shows on cursor hover, and none of the popular images

↑ "Nothing" is clearly not much constructive. I will rephrase that.

avatars

↑ For example, the Avatar in the menu bar probably really does not need an alternative text, otherwise any smart screen reader will repeat your username twice.

Phabricator logo

↑ That has sense

Edit menu buttons

↑ This is another example that is probably not OK. For example an edit button Edit This Task does not need any alternative text for the icon, otherwise, a screen reader will say "Edit Edit This Task" with "Edit" twice.

It's not to say that we cannot improve the situation, it's just to say that probably the current description is somehow too sensationalistic, and not much actionable

I'm not a heavy Phabricator user but I can't think of anything that needs to be fixed accessibility-wise these days. I use the latest version of JAWS for Windows as my screen reader under Chrome 113. I haven't tested it thoroughly though and I don't have any particular accessibility expertise beyond lived experience.

Wow. @Graham87 This is definitely the most unexpected, relaxing, beautiful comment I could read in the last 6 months. Thanks for your live tests.

Premising that I like in Mastodon the images that have transcription. So for example this meme would really deserve a transcription for screen reader folks:

Example transcription:

This is a velociraptor-free workplace. It has proudly been 42 days since the last velociraptor-related incident! (The 42 is written on a sticky note, probably ready to be updated).

I'm really not an expert, but at the moment that meme has the same value for title and alternative name, and that is probably not useful. So, maybe a potential improvement could be, putting that transcription in alternative text. So, introducing an "alternative text" field in the meme for that.

Does the meme make you laugh? Would you enjoy reading these things or would you rather ignore them? (feel free to beat me up with heavy alternative hammer).

Yeah the transcript should be in the alt text in a case like this ... that's how I've encountered that sort of thing on Mastodon. Nah it didn't make me personally laugh but it'd be good for the transcript to be there for people who are amused by it. This is getting waaaaaay off-topic though ...

In T109#8875540, @Graham87 wrote:

Yeah the transcript should be in the alt text in a case like this ... that's how I've encountered that sort of thing on Mastodon.

Thanks for this information. This specific accessibility bug request is now filed upstream:

https://we.phorge.it/T15416

Nah it didn't make me personally laugh

Fair :)