Accessibility for internal UI

[rb6502]

In reference to https://www.reddit.com/r/MAME/comments/ceitb9/blind_user_with_a_couple_questions/

The easiest route would probably be to add hooks so OSD can speak the name of the currently selected menu item using the Mac and Windows built-in speech synthesizers (and something like Festival or eSpeech on Linux). This probably will best be done after Nathan finishes his UI overhaul though.

[MooglyGuy]

I disagree that we should wait, since Nathan's UI overhaul effectively eliminates the internal UI in favor of a wxWidgets framework.

I was told not so long ago that any GPU hardware acceleration must have a software fallback for systems that lack 3D acceleration, because we apparently want to keep rendersw.hxx around as a fallback path. Just as much, it's important that MAME retain some sort of internally-rendered UI for systems that lack a viable wxWidgets port.

If I can sort out the Laserdisc problems that Tafoid reported, this sounds like something I'd actually rather like to look into this weekend, since I'm taking a vacation day on Friday.

Ultimately the API to pass speech-synthesis requests up to the OSD isn't going to be appreciably different whether we're using Nathan's new UI or not, so it's better to strike while the iron is hot and the motivation is there.

[npwoods]

What MG said. I'm bypassing the MAME UI, and I don't see how any text-to-speech enhancements would collide with my changes.

While I am doing quite a bit of refactoring, my work involves trying to better encapsulate the UI and addressing the knotty entanglements with the core.

-N

On Thu, Jul 18, 2019 at 10:34 AM MooglyGuy notifications@github.com wrote:

I disagree, since Nathan's UI overhaul effectively eliminates the internal UI in favor of a wxWidgets framework.

I was told not so long ago that any GPU hardware acceleration must have a software fallback for systems that lack 3D acceleration, because we apparently want to keep rendersw.hxx around as a fallback path. Just as much, it's important that MAME retain some sort of internally-rendered UI for systems that lack a viable wxWidgets port.

If I can sort out the Laserdisc problems that Tafoid reported, this sounds like something I'd actually rather like to look into this weekend, since I'm taking a vacation day on Friday.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/mamedev/mame/issues/5357?email_source=notifications&email_token=AEVW33XEUECYXYOMNTGBCRDQAB5QVA5CNFSM4IE3T6D2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD2IVVPQ#issuecomment-512842430, or mute the thread https://github.com/notifications/unsubscribe-auth/AEVW33SRRZSME7V2BRP5GXTQAB5QVANCNFSM4IE3T6DQ .

[rb6502]

Ok. I wasn't sure of the scope in terms of separating the existing UI's presentation from the business logic, but if you guys think it's OK and MG can do something this weekend I'm all for it.

[pitermach]

Hello,

I'm a blind Screen Reader user and I came here after wanting to open an issue about this exact topic and because I was just having a conversation about this with a few other people. There are many cases where having access to Mame's on-screen UI would be extremely helpful.

I initially came here to suggest Accesskit to do this, which is a library that lets you give accessibility to UI controls on Windows, Mac and Linux even if they're just directly drawn to the screen like in the case of Mame. There is an example for making an SDL-based app accessible in the directory for Accesskit's C binding which may be helpful.

However, I'm now also wondering if the WX Widgets based UI is still something that's being considered? This would also solve the problem, because WX actually offers decent accessibility on its own so if the menus were changed to use it chances are the screen readers would be able to read them with little to no changes required.

[jaybird110127]

Accessibility for the MAME UI is something I, too, would really like to see. A few days ago, the author of an Apple IIe/c/gs Print/Braille word processing package for the blind passed away. I'd love to create a package to show people what using this program was like, but one of the major stumbling blocks is that once you get to a certain point, you have to turn the program disk over, which in MAME's case, means switching to another disk image. Currently this can't be done in the UI. You can sort of fake it using save states, but that's less than optimal, and you need to know what you're doing. Has there been any progress on this?

[rb6502]

I'm sorry nothing has happened with this yet. MAME always has bigger ambitions than we end up having time to implement. The suggestion of AccessKit looks interesting, I'm going to have to digest that a bit.

@jaybird110127 Perhaps the program could be adapted to run from a larger volume like an 3.5 inch disk or hard drive to avoid the disk swapping? If you can point us to the program I suspect @peterferrie could take a look.