More accessibility support

[guikubivan]

I tried testing this with Chromevox and it has issues with reading the icons (title icon reads as "times" and close icon reads as "multiplication button". Also when dialog is closed, focus is not returned to previous state (it's lost basically so user is not sure where they are in the page).

[niemyjski]

Can you please submit a pull request for this.

[dougmoscrop]

As maintainers I think we need to appreciate that not everyone is going to be able to fix the issues they identify.

I'd also classify lack of accessibility as a defect, not a feature, to be precise.

[dougmoscrop]

(I think other projects use a 'help wanted' type label or system?)

[niemyjski]

@dougmoscrop, our audience is developers and help is appreciated. I don't think this is a defect as it doesn't break anything, it's an enhancement.

[dougmoscrop]

I get that our audience is developers, I just meant there's a difference between someone opening an issue that is like, "Please update [some dep] to [some ver]" where the Issue basically represents the same amount of work as the PR itself, whereas something like this ... someone can identify that something does not work but not have the capacity to actually fix it.

We're probably splitting hairs on terminology, but anything that doesn't include accessibility concerns is fundamentally incomplete or broken by design: I'm guessing you mean defect/broken in the sense of "regression" in which case, I agree, this project is as broken as it has always been - that's not an indictment of anyone, nobody should feel bad, but we should establish accessibility support and then all future work needs to understand that it's a requirement, not something you tack on after the fact.