哪个屏幕阅读器最适合测试网站可访问性以及如何配置屏幕阅读器来测试网站(或默认屏幕阅读器设置可以)以及哪个浏览器应该用于测试屏幕阅读器的可访问性?
免费或商业无所谓.哪个可以提供最佳测试,那么所有其他屏幕阅读器应尽可能在全世界访问网站?
我的目的是尽可能地建站点.
我想我理解Javascript如何工作以便在第508节中没问题.但我一直无法找到相关问题的答案:我的网站是否需要在没有Javascript的情况下工作才能符合508条款?
举一个极端的情况,如果没有Javascript的用户无法登录,是否违反了508条款?如果是这样,文本中的位置是什么解释?
我知道所有内容都必须通过屏幕阅读器,键盘和鼠标用户等访问.但是,没有Javascript的用户是否需要访问所有内容?
iOS 7.1包含一个新的"辅助功能"设置,调用"按钮形状"可以使某些按钮文本自动加下划线.有没有办法检测这种模式,或为个人UIButtons 定制?
(这允许更改按钮标签,例如破折号或下划线,以便在加下划线时,它们看起来不像等号等)
我们已开始在https://developer.android.com/guide/topics/ui/accessibility/services.html上查看适用于Android的Building Accessibility Service .根据此文档,我们可以代表用户执行自定义手势,如"为用户执行操作"部分所述,网址为https://developer.android.com/guide/topics/ui/accessibility/services.html#act-for -Users.我们根据此文档提出以下问题.
1)据我们了解,用户会执行手势,我们的代码会听.我们称这些听力手势.然后,我们的代码可以为用户执行手势.我们称这些表演手势.问题是表演手势的影响 - 触摸和探索层还是触摸和探索层下面?有关其他信息,触摸和探索是Android操作系统的功能,可由辅助功能服务请求.
2)Performing Gesture是否会触发通知Accessibility Service的任何AccessibilityEvent?如果是,如果Listening Gesture和Performing Gesture都是相同的,那么可能会有递归.那就是Listening Gesture可以向右滑动,触发一些事件.进行手势也可以说是向右滑动.现在,这也将依次触发相同的事件处理程序.
3)我们如何确定Performing Gesture成功执行?如果Performing Gesture发生在触摸和探索层下面,那么整个事情就具有重要意义.
任何帮助将不胜感激.
浏览器“阅读器模式”重新格式化网页,使其根据个人用户的需求(间距、对比度、字体等)更易于访问/阅读。
虽然每个浏览器实现的阅读器模式都不同,但总的来说,它们都是文章风格的网站,如 Medium、纽约时报、Lifehacker 等。
但是在 StackOverflow 上,阅读器模式几乎都以各种方式中断,通常只显示问题和/或第一个答案;其他内容根本没有。
具体来说,SO/SE 页面的 HTML 结构是什么混淆了浏览器阅读器模式?
换句话说,如何更改页面的 HTML 结构以允许浏览器阅读器模式正确解析和显示所有问题/答案内容?
通过比较各种浏览器,*移动和桌面,阅读器模式使用某种简单的启发式方法来确定要显示的内容,例如“仅显示文本最多的元素,并隐藏所有其他内容”。或者,“仅显示文本最多的元素,但更靠近页面顶部的元素显示权重。”
* 目前已尝试过(移动和桌面):Firefox、Safari 和 Chrome(请注意,Chrome 仅在移动设备上具有本机功能,并将其称为“简化视图”)。在 Firefox 和 Safari 上访问阅读器模式在 URL 栏中;如果支持,Chrome 中的访问位于屏幕底部。
但也有可能对元素标签/类/id 进行一些扫描,以寻找重要内容的语义指示。
通过在浏览器 DevTools 中摸索,我注意到似乎有两个包装器<div>包含所有问答内容,而各个问题和答案也都有自己的<div>. 这令我感到困惑,因为通常这是第一个问题,并说得到展示,而我希望一个第一个答案或其他-或为读者检测包装和显示的所有内容。
虽然所有浏览器都以不同的方式实现这一点,因为它们都可以毫无问题地处理文章风格的网站,删除非内容元素,我正在寻找对 SO/SE 页面的结构或语义的调整,这同样会引起浏览器阅读器模式来捕获所有内容。
SE 最近扩大了所有 SE/SO 站点的行距以促进可访问性(例如,对于有阅读障碍的读者)。我在这里的问题是我在meta 上的帖子的技术姐妹问题,其中我建议 SE 站点更好地支持读者视图。(请注意,我不赞成或反对格式更改;我只是想研究一种通过阅读器模式支持用户确定的格式。)我希望这个问题将作为该帖子的技术调查推论,并会产生一些关于可以进行哪些修改以支持浏览器阅读器模式的可操作信息。
要求用户阅读扭曲文本的CAPTCHA对于有视力的人来说是好的,但对于那些失明或有其他残疾的人来说是一个可怕的障碍.音频备选方案偶尔可用,但仍然无法帮助那些聋哑人和盲人,并且很难使用屏幕阅读器(已经在向您朗读文字).
存在一对夫妇使用人类解决代表用户,如的CAPTCHA解决方案的WebVisium和Solona,但这些依靠志愿者运营商的可用性(例如,Solona显然只有一个志愿,所以你必须希望他当你需要帮助时醒着).
在我看来,盲人所需的CAPTCHA解决方案的数量非常低 - 我猜想在像英国这样的人口稠密的国家每天不到几百个.这意味着,与想要在短时间内多次执行动作的坏人不同,为盲人提供的CAPTCHA援助服务可以承担相当大的计算资源 - 例如,亚马逊EC2中的计算机云- 来识别所呈现的文本.
我的问题是:假设你不太关心速度,并且你有很多可用的计算机,是否有算法可以让你解决今天常见的文本失真CAPTCHA,比如reCaptcha使用的那些?或者即使有大量的资源和时间,这些问题是否真的难以解决?
几点说明:
在这一点上,我的问题只是理论上的,但显然任何此类服务都必须谨慎控制访问以防止垃圾邮件发送者.也许只有注册的盲人才会被允许使用它.
我知道几年前使用一台算法在一台计算机上运行几秒钟就破坏了旧的Yahoo CAPTCHA.我在问现代CAPTCHA是否可以打破,可能更慢,资源更多.
在iOS设备中,可以在"辅助功能设置"中设置"大文本".用户可以在此处指定不同的字体大小.我想在我的应用程序中使用这个字体大小.我在"辅助功能计划指南"中找不到有关在我的应用中访问此字体大小的任何信息.它只提到标准Apple应用程序Mail,Contacts,Calendars等正在使用它.有谁知道在开发应用程序时是否可以访问此信息?
当设置大文本功能时,UIFont的静态-FontSize方法也不会返回不同的值.
(注意:不要与iOS 7的新动态类型混淆.在辅助功能设置下,这是一个不同的旧选项.)

请考虑以下标记.
<label for="i1" class="inforLabel">This is a label</label>
<input id="i1" type="text" class="inforTextbox" aria-label="Title, not label" />
Run Code Online (Sandbox Code Playgroud)
对我来说,这个标记是在我的自定义工具提示控件之后生成的.我在IE上看到JAWS的问题是它只读取"标题,而不是标签",但是对于其他屏幕阅读器,例如,标签和文本框上的语音都aria-label被读取.我认为它应该同时阅读.
这是一个设置还是一个错误?或者还有别人可以推荐的东西吗?
自从我开始使用HTML,CSS等以来,我一直注意到的一个一致的事情是导航条似乎几乎总是以列表形式呈现,在某些变体中:
HTML:
<ul>
<li><a href="link1.html">link 1</a></li>
<li><a href="link2.html">link 2</a></li>
<li><a href="link3.html">link 3</a></li>
<li><a href="link4.html">link 4</a></li>
</ul>
Run Code Online (Sandbox Code Playgroud)
还有<li>里面的<a>
CSS:
ul{list-style-type:none;}
li{display:inline-block;}
Run Code Online (Sandbox Code Playgroud)
现在HTML5基本上是相同的,但在<nav>标签或任何说"这是浏览器/屏幕阅读器的一些导航内容"的任何东西.
我的问题是他们是否需要具有现代HTML5语义和ARIA可访问性角色的列表,还有什么好处?当然是一个链接列表,但还有其他任何实际原因吗?
我找到的理由:
语义,屏幕阅读器和可访问性:意见各不相同,特别是它如何使屏幕阅读器更好(或更糟糕......).但是不应该<nav>在链接周围使用HTML5 和/或相关的ARIA角色吗?是否还需要专门显示为链接列表(无序或其他)?
美学:在带有默认项目符号的垂直列表中,或者没有CSS,是的.但是,否则替代标记(例如<a>in <nav>)而不是<li>in <ul>将会如期望的那样容易或更容易.
现有用途:它在现有网站中使用很多(例如StackExchange站点,MDN,还有更多......).
W3C <nav>规范:说链接不必在列表中,但它可以.但它也指定了<nav>"链接部分" 的内容,它还需要是"链接列表"吗?
向后兼容性:它经常被使用,因此应得到广泛支持,HTML5和ARIA可能无法供旧浏览器/屏幕阅读器使用.
各种帖子:
我正在使用遵循以下语法的脚本在我的页面中设置选项卡式内容部分:
<!-- Clickable tab links -->
<ul class="js-tablist">
<li id="tab1" class="js-tab active"><a href="#tabpanel1">Tab 1</a></li>
<li id="tab2" class="js-tab"><a href="#tabpanel2">Tab 2</a></li>
<li id="tab3" class="js-tab"><a href="#tabpanel3">Tab 3</a></li>
</ul>
<!-- Tab panels -->
<div id="tab-set" class="js-tabpanel-group">
<section id="tabpanel1" class="js-tabpanel">__CONTENT__</section>
<section id="tabpanel2" class="js-tabpanel">__CONTENT__</section>
<section id="tabpanel3" class="js-tabpanel">__CONTENT__</section>
</div>
Run Code Online (Sandbox Code Playgroud)
我会设置各种ARIA角色(role="tablist",role="tab",role="tabpanel"在这种结构性标记通过JavaScript等)(因为如果没有脚本则没有标签),但我不确定相当哪里把我的"咏叹调-控制"的属性.他们应该继续 <li>元素还是<a>子元素?或者没关系?事实上,同样的问题可以问role="tab"及tabindex="0"-应这些东西在列表项或锚去?
accessibility ×10
css ×2
html ×2
wai-aria ×2
android ×1
blind ×1
captcha ×1
disability ×1
html-lists ×1
html5 ×1
ios ×1
ios7 ×1
javascript ×1
navigation ×1
section508 ×1
tabs ×1
text ×1
usability ×1
xhtml ×1