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.

This is indeed a hypothetical concern on my part, but I already asked a well–known English Wikipedia administrator who uses JAWS to access the Internet to help with this task in his spare time so as to make Phabricator as inclusive as possible.

I sent him a link to this request, and I'm hoping he'll be able to help.

Hello, I'm the above-mentioned blind English Wikipedia admin. I'd be happy to help out with testing Fabricator, especially if somebody could give me specific things to check. The above-mentioned issues are significant problems; here are a few others I found while poking around on the Wikimedia Foundation labs test suite:
*On the homepage, link titles such as "Calendarβ" use "β" rather than "s", causing JAWS to pronounce them in an unusual manner (due to the final "β" character).
*Also in the jump nav user guide, JAWS pronounces the ◉ in the title as "Japanese tainum bullet" so the title sounds like ""◉ Jump Nav User Guide"
*When commenting, between the "Actions" combo box and the edit box in the HTML, JAWS reads several strange lines like "T145#", which IIRC indicate links without labels. Are they the toolbar?

Thanks!

In the application links, the symbol "β" is "greek small letter beta", and is intended as "beta", to indicate applications which have some missing features or are still in development. The form of the glyph is similar to the german eszett symbol "ß", so maybe JAWS interprets it as one, possibly to correct cases where sites misuse one glyph for the other.

It looks like we might not have any space in the markup, so a simple fix might be adding a space. How is the next line after this one read?

Example β

If that is read as "Example Beta", we can probably just add a space in the markup. However, since this information isn't very important and the menu is a primary navigation menu, maybe we should just use a background image (or "aria-hidden") to remove this information from the aural version instead. The information is available elsewhere (like on the list in the Applications application), so that interface could still be used to check which applications are beta, while streamlining aural navigation.

The page titles can be changed to use application names instead of glyphs like "Japanese tainum bullet" by navigating to: Settings, Display Preferences, Page Titles. That should produce titles like "Differential Query: All Revisions" and similar, instead of "Small Gear Query: All Revisions". We can probably make this easier to get to, some discussion below.

Between the "action" combo box and the comment editing area there are two possible sets of elements which might be causing a problem.

The first set of elements is a toolbar, with buttons like "bold", "italic", and so on. These use background images. Overall, the intent of these buttons is to make it easier to learn the markup rules that Phabricator uses, and they operate by inserting text into the plain text area below. For example, the bold button inserts text like "star star example bold text star star", hinting to the user that asterisks can be used to emphasize text.

We could put aural-only text in them instead, but maybe they're not very useful at all, or more time consuming to navigate past than they are helpful? Would you prefer we annotate them, replace them with a single "formatting help" link to the documentation, or remove them entirely?

The second set of elements which might be causing the problem between "action" and "Comments" is that there are some hidden elements in the markup. For example, if you choose the "Change Status" action, we reveal a dropdown menu to select a new task status. If these are causing a problem we can adjust how they're presented in the page markup.

On the related task, the accessibility of the main menu (which appears on every page as the first content element) was brought up. The elements in this menu are: a link back to the home page, a link to notifications, a link to messages, a search bar, a link to your profile, a link to quickly create a new object like a task, a link to settings, and a logout link. Since most of these elements are block-layout links with background images, I would expect they are difficult or impossible to use right now. Is that true?

The easiest fix for this is probably to put screenreader-only text in them, but I suspect some of the links might benefit from further adjustments. For example, the "notifications", "messages" and "create new object" links all pop out javascript dropdown menus, and these menus may be appended to the document in an unrelated place, like at the end of the document. With these menus, or with other similar menus, is your experience that JAWS can read them effectively? Or would it be better for us to hide the links which reveal dropdowns and provide alternate screen-reader only text instead, like a link that says "6 unread notifications."?

Finally, how important is streamlining content order in general? For example, we could move rarely used links in the main menu (like logout and settings) to the bottom of the page in the aural representation. Is this sort of thing generally helpful, or is it better to leave them in the header?

It'd be best if the "β" characters were removed (at least from the point of view of screen readers), because they read as "esp setr" ather than "beta" when they're separated by spaces.

It would probably be better if the application names were in the titles by default, rather than the glyphs.

The toolbar appears to be causing the problem with the unlabelled links. I'd prefer it to be annotated ... some screen reader users may find them useful, at least at first, and most screen reader users can easily move directly to the edit box if need be.

The main menu is completely impossible to use with screen readers at the moment. JavaScript dropdown menus (like in Facebook) tend to work well with screen readers.

On your final point, it's best if the order of elements in the HTML matches their position in the document as closely as possible. This makes it easier for sighted users to describe the layout of pages to screen reader users, and avoids any nasty surprises where an element is in an ideal place for most users but in an awkward place in the HTML.

Oops, '"esp setr" ather' should be '"esp set" rather".

"Calendarβ"

Using the Orca 3.10 screenreader, the spoken output is "Calendar beta link" so this sounds like a bug in JAWS to me.

I wonder how relevant are the missing tooltips. Several Wikimedia community members landing in Phabricator for the first time are reporting that they miss tooltips in the header to understand what "a flame" or "+" mean. These elements are quite obvious once you see them in action once, but are descriptive enough for visually impaired users?

I need to update D8830 in response to feedback, but it removes them (for screen readers) and replaces them with text like:

No notifications.
You have 3 notifications.
No messages.
You have 9 messages.

We still have a long way to go here, but I think the two major issues (main menu, remarkup buttons) should be addressed if we got things right from a technical point of view. In particular:

• The main menu items should all have aural labels.
• The "notifications" and "messages" icons should have appropriate aural alternatives.
• The remarkup buttons above the text area should have aural labels.
• The "beta" mark should be muted for aural users (it conveys very little value, is in a presumably-common UI, and this information is available elsewhere).
• Image macros should now have appropriate alt text.
• Users can now specify an alt attribute when embedding images with {F123} syntax.

For visual users without screen readers, you can add ?__aural__=1 to a page to visually preview the aural information that's available for screen readers. For example, you can see the main menu labels (and muted "beta" marks, and so on) here:

https://secure.phabricator.com/?__aural__=1

Please let us is know if this is an improvement (that is, if we're generally on the right track here) and what else could use attention if anything specific is causing difficulty. Otherwise, we'll continue improving things over time. In particular:

• There are a lot of interfaces where we convey low-importance information exclusively through colors or icons. As we identify these, we can add aural labels. Most of this information is helpful to have, but I think it is usually not critical (for example, the indicator that you have unsubmitted draft comments on a review).
• Although we usually provide text labels for links and buttons, there are probably still some which are missing. The only one that jumped out at me after poking around for a bit is the application breadcrumb, which uses an application icon without an aural label. I'll fix this momentarily.
• There are some interactions (involving popups, dialogs, etc) that are probably still difficult to use. We might need to install a copy of JAWS to identify these effectively on our own.
• There are some interactions (gestures on mobile, adding inline comments in Differential, dragging cards between workboards) that are probably unrealistically difficult to use. As we identify these we can add accessible alternatives.

Thanks, this is much better!

I've found a few more issues, now that I can access the profile/settings panels:
In the profile:
*The label for the "blurb" field doesn't read out when tabbing/shift-tabbing.
In the settings section:
*It would be better if the title of the currently active tab was made into an HTML heading, to make it easier to quickly navigate to it.
*The edit fields in the password section do not read when navigating with tab/shift-tab;, neither does the edit field when adding a new email address.
*Display preferences: The "Show all textareas using the monospaced font defined above" radio button just says "enabled/disabled" when navigating to it with tab/shift-tab, probably because the group label is in a non-standard position. My hunch is that a check box would be more standard for this sort of thing.
*The homepage section is completely inaccessible when navigating with the tab/shift tab key. I don't know how best to fix this (I don't know much about HTML forms), and I don't think screen reader users would use it ... but perhaps users of screen magnifiers might get some benefit out of it.

Some ideas about how to make comments in differential more accessible (after discussion with a member of my team who is blind):

• (Better) Update the focus when using the "n" and "p" keyboard shortcuts to move to the next and previous comments. (Selecting a comment in this way allows the user to reply to the comment using the "r" keyboard shortcut, but "n" and "p" aren't very accessible because they just add a yellow border and scroll the page but don't change the focus.)
• (Would also be nice) Add the reply icon (to the right of the "Done" checkbox) to the tab order. (Tab currently stops on the "Done" checkbox on the comment.)

Navigation beyond comments: The other keyboard shortcuts ("j", "k", "J", "K", "t", etc) also do not seem to change the focus; changing the focus when one of these is pressed, too, would help a lot with navigation.