为什么叙述者不会将自己报告为Windows的屏幕阅读器?

时间:2010-09-29 01:05:48

标签: windows winapi accessibility

我正在尝试检测屏幕阅读器是否连接到我的应用程序,以便我可以改善盲人和低视力用户的体验。我正在使用这个win32 api(http://msdn.microsoft.com/en-us/library/ms724947%28VS.85%29.aspx),并指定SPI_GETSCREENREADER作为uiAction。电话看起来像这样:

int iAction = 70; // SPI_GETSCREENREADER constant;
int iParam = 0;
int iUpdate = 0;
bool result = false;
bool bReturn = SystemParametersInfo(iAction, iParam, &result, iUpdate);

如果JAWS正在运行,或者就放大器实用程序而言,此API会报告连接了屏幕阅读器。但是,如果我只运行内置的屏幕阅读器(MS讲述人),则此API会报告没有连接任何屏幕阅读器。

这真的发生了吗?微软的人真的决定不将内置的屏幕阅读器报告为屏幕阅读器吗?

2 个答案:

答案 0 :(得分:1)

我无法测试代码,但遗憾的是你可能是正确的。讲述人是一个非常基本的屏幕阅读器,除了允许您查看主屏幕阅读器是否已崩溃之外,它几乎不提供任何有用的功能。有传言称,微软最初希望将其作为一款功能齐全的屏幕阅读器,但是对已经生产屏幕阅读器的公司可能存在的反垄断问题做出了回应。请注意,这是我在过去的一些失明电子邮件列表中所听到的,但无法验证是否有任何真相。如果这是真的,它将解释为什么讲述者一瘸一拐,没有真正的改进,只要我记得。我不担心讲述者,如果用户正在使用你的应用程序,他们将使用像Jaws这样的体面的屏幕阅读器。我一直在使用屏幕阅读软件,并且从未认识任何人使用Narrator作为主屏幕阅读器。如果您希望使用免费的屏幕阅读器进行测试,我建议使用NVDA根据我的经验,它不如下颚好,但它是一个非常实用的屏幕阅读器而没有高价格。

答案 1 :(得分:1)

如果有人陷入这个可怕的陷阱。讲述人在开始运行时会设置一个互斥锁(这完全没有记录,但如果你需要检测ms叙述者它似乎有效)

wstring m_wstrMutexKey = L"NarratorRunning";

// security attributes are part of windows API for CreateMutex
LPSECURITY_ATTRIBUTES securityAttributes = new _SECURITY_ATTRIBUTES();
securityAttributes->bInheritHandle = false;
securityAttributes->lpSecurityDescriptor = NULL;
securityAttributes->nLength = sizeof(LPSECURITY_ATTRIBUTES);

// initialize values
bool isRunning = false;

// CreateMutex returns a windows application HANDLE
HANDLE m_applicationHandle = CreateMutex(securityAttributes, false, m_wstrMutexKey.c_str());

// This should never happen
if (m_applicationHandle == NULL) {
    isRunning = false;
}
// This condition indicates that narrator is running. 
if (GetLastError() == ERROR_ALREADY_EXISTS) {
    isRunning = true;
}

if (isRunning)
{
    cout<<"Narrator is running.";
} else {
    cout<<"No Mutex found. Narrator is not running.";
}

delete(securityAttributes);