Repository navigation
Check accessibility of custom controls #27
Description
Activity
ce53fa2 adds an implementation of Active Accessibility for the custom tab-like controls in the front-end.
8370a64 adds more accessibility names to the top-level controls of the front-end window, e.g. the toolbars.
Areas still requiring attention:
- The contents pane.
- The source pane, when showing a sub-set of the whole source.
- The testing pane.
- The story pane.
- Find and replace dialogs.
- Find All dialog.
- The preferences dialog.
I'm very reassured to see this open, I've been having a lot of problems with accessing custom controls in b5. The issue is less to do with the names (which work perfectly, thanks btw) and more to do with actually being able to focus in them. E.G. many important panes containing imbedded web documents are no longer browsable with the system caret as of b5. some just read their label (e.g. "report page"), others read nothing. The documentation pane is a good example of the latter, the only way to view it is to use the screen reader's cursor to navigate between paragraphs contained inside tables. Which, while a rather creative use for them, is quite frustrating. :)
The index on my system doesn't have this same issue. The web documents for the index pages are properly browsable as webpages, although their visual usage of punctuation and non-standard usage of HTML elements makes the index hard enough to read that I don't often use it. But that's really a separate issue. :)
I've tested this with NVDA and JAWS, the two most popular screen readers. Both have issues focusing on custom controls, or even finding some of them, such as the console tab, which no longer seems to be next to the report tab.
I know you've probably got a lot already going on with this project, what with the release of Inform 10. I'm submitting this feedback in the hopes that I and other screen reader users will be able to use the updated frontend when it is released.
Thanks for your hard work,
Peregryn
Windows 10 Pro 64 bit, Inform 7 6M62 b5 and b3, NVDA 2021.3.5, JAWS 2020The accessibility of HTML in the documentation and index is a tricky one, since these (and similar) are generated either by the Inform compiler, or its build infrastructure. It might be worth raising this as an issue in the new bug tracker for the core Inform system (there is a link to it at https://github.com/ganelson/inform).
That's good to know, thanks, I'll do that. Do you know what's going on with the controls themselves? I don't mean the HTML presentation, I can see what you mean about it being generated by the compiler. I mean the places in the interface where the documents are actually imbedded. I'll gladly admit my ignorance, but I'm almost certain the compiler doesn't do that part? It puts together the reports, but the IDE has to display them. Something changed between b3 and b5 which causes my screen reader to no longer see panes like the documentation window and report page as web documents. The screen reader won't move the system caret inside them, basically I can't scroll through them with the arrow keys the way I could in b3 and earlier. I suppose it could be a CEF issue, but I've never seen this in any other apps which use it. I'm sorry about being so vague, GUI design is definitely not one of my strengths.
There aren't any obvious changes between b3 and b5 that would have that effect. At some point I did upgrade to the (then) latest build of CEF, which might have had issues. At some point I need to experiment with NVDA, but at the moment I can't make any promises as to when that might be.
All right, it may very well be CEF and the way NVDA is interacting with it, I'll ask over there as well. Thanks for responding to this, your consideration of accessibility is very appreciated. :)
For anyone else reading this, I've found something of a workaround for this issue in the mean time, at least with NVDA. Try simulating a left single click on the document object, this should bring it into focus until you navigate out of the window. You'll have to do it again upon re-entering but you do get the old browsable document. I've tried it with JAWS, but I have an old version and results have been inconsistent. Someone else may have better luck.
The Windows front-end uses a lot of custom controls (e.g. the skein window). These should all be checked to make sure they expose Active Accessibility objects so that they are visible to screen readers, etc.