SyntaxEdit and screen readers

Albert Wiersch

I have a customer that uses a screen reader and is having trouble using my application with them.

I am not sure how screen reader support works in Windows... but maybe the VCL has issues with it? Maybe SyntaxEdit isn't supporting them properly?

Is there anyway this can be improved? Shouldn't VCL components support Windows Narrator? I assume if they supported Narrator then they would support other readers as well... but again, I am not familiar with how all this works.

So any ideas about what I could or should do here? Thanks.

Below is part of a message sent by my customer:

What I’m finding is that no screen reader can detect the
font present.  I’ve tried Jaws, NVDA (a free open source screen reader)
and Narrator, which is built into Windows and is getting much better.
 There is a hotkey that should tell me the font attributes of the text
under the cursor.  All 3 say “no font.”

So, something in the way CSS HTML Validator is presenting
the text is hiding it from the screen readers.

I know you are not familiar with how screen readers do what
they do, but I’m thinking this is going to be an issue with something in the
way Validator is presenting the text.

I don’t understand the programming information either other
than screen readers used to use the Off Screen Model but don’t any longer…

Albert Wiersch

UPDATE: Customer says that the editor (SyntaxEdit) is the issue. They can hear line numbers but that is all.

Rafael Maricca (LMD)

LMD SyntaxEdit does not implement MSAA. If you need to support this, you need to derive a custom control which implements corresponding Windows interface (e.g. IAccessible, example can be found in this Stackoverflow request or this overview). 

Supporting all MSAA features  would be far too extensive, but implementing the interface at least some basics can be implemented easily (e.g. readonly of line by line etc.).  

>>Shouldn't VCL components support Windows Narrator?<<

There is no built-in IAccessible support in VCL which can be reused. There is automatic support for many VCL controls based on controls provided by OS (that's the reason why many controls work out of the box if they use standard control classes like BUTTON or EDIT), but for any custom control beyond that interfaces have to be implemented manually. 

Albert Wiersch

Thank you for the information. I'd like to support this but it's not a requirement and I just don't have the resources. It's really too bad the VCL support seems lacking for non-standard control classes.

If there is any way support (even if limited) could be added to SyntaxEdit then that would be great and would be better than requiring everyone to implement it manually.

I really wish you guys would start developing and investing in SyntaxEdit again. :-)

Albert Wiersch

My customer contacted a tech guy when it comes to accessibility. Here is what he said (maybe it will be helpful for something or at least interesting):

JAWS, NVDA and Window-Eyes use a couple methods to get to
the text on the screen. For older win32 applications, they would use their off
screen model (OSM). Meaning the screen reader simply intercepts all the win32
API calls to render anything to the screen and keeps a record of where
everything is. However, as newer technologies come out, such as Direct2D and
other acceleration techniques, the old win32 stuff is completely bypassed
making an OSM useless.

The backup method (or just alternative method) is to use the
DOM of the application (typically only used for major applications like Office
and browsers) or, more generically, UIA or IA2. MSAA didn’t really handle text
well. Of course using UIA or IA2 take a conscious decision to use it or at
least build off other widgets that already use the APIs.

So bottom line, either build off widgets which have already
done the grunt work to support UIA (I wouldn’t consider IA2 as it is getting
used less and less) or strap in and implement UIA directly.