Experiment with a version of the Windows APIs for mozilla::TextRecognition
Categories
(Core :: DOM: Core & HTML, task, P3)
Tracking
()
People
(Reporter: gregtatum, Unassigned)
References
(Blocks 1 open bug)
Details
In Bug 1759201 I added a macOS-only mozilla::TextRecognition component. I think a first step here would be to naively copy/paste this and get it working with the Windows APIs.
The Windows OCR APIs: https://docs.microsoft.com/en-us/uwp/api/windows.media.ocr?view=winrt-22000
Examples of using UWP APIs: widget/windows/WindowsUIUtils.cpp
A follow-up from there would be create a base class for mozilla::TextRecognition, with implementations for each supported OS, similar to the nsPrinterListBase. (this step might belong in a separate bug).
Reporter | ||
Updated•3 years ago
|
Reporter | ||
Updated•2 years ago
|
Reporter | ||
Comment 1•2 years ago
|
||
There have been some difficulties with getting screen readers on Mac to work nicely with the modal implementation in Bug 1782578. If and when we implement in Windows, we'll make sure to optimize this problem for that platform.
Based on feedback from :jamie in https://phabricator.services.mozilla.com/D153396
One challenge here is that the document (or something inside it) needs to get focus in order for Windows screen reader users to be able to access it. So, we'd either need to:
Make the document focusable and hope the user thinks to try tabbing to it.
Make the document focusable and focus it when the results are available. This might be confusing for sighted users, though.
Make the document include the Close button so that when the Close button gets focus, focus is "inside" the document.Assuming the Close button is already focused in the current patch, 3) is probably the least disruptive.
The entire conversation in phabricator would be good to read for complete context. We should make sure and continue this discussion and resolve any issues with Windows. For now we're only doing macOS.
Updated•1 years ago
|
Description
•