Add ARIA role / label to post editor buttons

Question

From a comment on As a blind user accessing the site with a screen reader, how can I upload pictures for identification?:

I am blind, and as far as I know I haven't found anything that my screen reader says is an image uploader. I use <a href="http://nvda-project.org/">NVDA</a>. – The Harmonic Rainbow 2018-01-26 22:10:05Z

We can "fix" this problem with ARIA tags!!! … Yeah, yeah, I know:

When a feature in the host language with identical role semantics and values is available, and the author has no compelling reason to avoid using the host language feature, authors SHOULD use the host language features rather than repurpose other elements with WAI-ARIA. — WAI-ARIA 1.2 spec

I am suggesting a hack. However, it's low-effort, unlikely to break anything for existing users, and might be an improvement. (Migrating to the Stacks Editor would cause problems, because contenteditable is really janky and the Stacks Editor has no way to switch that off.)

The hack is as follows. In Markdown.Editor.js, find the code that reads:

var makeButton = function (id, title, XShift, textOp) {
    var button = document.createElement("li");
    button.className = "wmd-button";
    button.style.left = xPosition + "px";
    xPosition += 25;
    var buttonImage = document.createElement("span");
    button.id = id + postfix;
    button.appendChild(buttonImage);
    button.title = title;
    button.XShift = XShift;
    if (textOp)
        button.textOp = textOp;
    setupButton(button, true);
    buttonRow.appendChild(button);
    return button;
};

Somewhere in that – probably just after the button.title line, insert:

    button.setAttribute("role", "button");
    button.setAttribute("aria-label", title);

(You can use button.role and button.ariaLabel if you only want to support browsers from the past two years.)

This hack won't make the buttons navigable, so it's not a real fix – but at least it should make it possible to coax a screen reader to read out the keybindings. (I'd suggest adding tabindex=0 too, but the site already has a lot of tabindex nonsense going on, so I'm not confident that would be an improvement.)

---

These elements are already (really buggy) buttons, conceptually. However, I'm pretty sure implementing this change will reduce the number on your automated accessibility test tool, because it adds role=button semantics to elements that aren't interactive, breaking the third rule of ARIA use:

All interactive ARIA controls must be usable with the keyboard.

For example, if using role=button the element must be able to receive focus and a user must be able to activate the action associated with the element using both the enter (on WIN OS) or return (MAC OS) and the space key.

However, this isn't introducing a problem: only revealing it to the computer. A more in-depth fix would involve changing the <span>s to <button>s, moving the click event to them, updating .wmd-button > span references in primary.css, and probably lots more restyling on top of that…

If you can migrate this to semantic HTML, then great! That wouldn't quite make the editor usable, since the site uses global (positive) taborder, and fixing that requires copious user studies (it's clearly there for a reason); but it would be a significant improvement.