Yahoo!用户界面博客（YUIBlog）

搜索直接访问

几个月前，我们推出了直接搜索的第一个beta版本。 这种新产品，探讨了实时反馈的概念，即刻交付用户每次击键的答案。 由于雅虎的受众的多样性，我们希望使搜索尽可能方便直接。 最初，我们相信，这将是一件容易的事，因为这种产品将在3 YUI的JavaScript库，将其DNA出炉的无障碍。 作为一名工程师，我的期望相反，这个任务竟然是比我们预期的更困难。

搜索直接介绍

虽然搜索直接从地面建成使用YUI的组件基础设施，其最明显的突出的界面是基于YUI自动完成构件右出框，其中包括许多辅助功能。 一个特定的查询有关的建议，显示在此自动完成实施。 搜索直接还设有一个内容面板，又名丰富的面板 ，在有关建议的内容显示。 丰富的面板的意图是从自动完成清单的建议，被选中时向用户提供一个直接的答案。

一套新的建议显示在名单上的每一个按键，默认情况下选中的第一个建议。 这个默认选择被称为软选择 。 软选择和后续交互的建议名单，决定，内容丰富的面板呈现。 在现实中，事情是一个比较复杂的（性能优化，额外的缓存层等），但为简单起见，我们可以假设，这是常见的工作流程。

辅助功能

在搜索直接访问的追求，我们期待在执行搜索助理，技术，雅虎开创了一个几年前，以及锐本地的辅助功能。

本次调查结束后，三个主要的辅助功​​能提出直接搜索：

• 使用YUI国际化的实用服务本地化的内容。
• 设置内自动完成构件的元素，需要确定和屏幕阅读器处理的role和aria-*属性。
• 使用一个隐藏的div ，表示现场地区（ aria-live ）事情发生时通知用户。 例如，提供建议，选定的建议等;

该计划是通知用户直接在搜索界面的任何变化，并提供一组键盘快捷键来浏览以下的可视化组件：

• 搜索框
• 提交按钮
• 建议列表
• 丰富的面板

像微风的声音，对不对？ 那么，让我们退后一步。

问题

我们这里有两个异步的过程-其中一个更新的建议集和检索相应答案的另外一个-他们都非常快。 我们谈论250ms的端到端。 由于接口改变，在这样一个快速的步伐，保持跟踪的一切是很困难的一个屏幕阅读器的用户。 它得到了一个数量级更复杂的异步更新发生时，近实时的方式。 因为屏幕阅读器被通知在接口的每一个变化，由此产生的颤很难理解发生了什么事情。

由于缺乏一个可以接受的解决方案，我们就开始与合作，雅虎的居民无障碍大师，：维克多Tsaran（ @ vick08 ）尝试，并拿出一些更好。

我们第一次观看维克多与搜索直接交互，我马上就明白了，他的重点，大部分的建议名单，而不是丰富的面板上。 这对我来说是一个惊喜，因为我们被视为“真理之源”的名单。 在我们的会议之一，我们的运气，当我们发生了禁用列表中的所有辅助功能。 尽快搜索列表介绍了噪声削减，直接开始使维克多的意义！

屏幕阅读器的用户如何看待搜索直接

意识到我们正试图解决错误的问题后，我们又回到原来的用户的故事：“作为一个用户，我可以得到一个答案，因为我键入”。 获取用户的答案是当务之急。 重新定义的问题后，我们集中我们的辅助屏幕阅读器的建议名单优先于丰富的面板内容的实施工作。

例如，如果用户类型"miami wea"屏幕阅读器会告诉他们两件事：

• 10项建议。
• 天气迈阿密，佛罗里达州。 今天，零星雷暴​​，89华氏度77°F。 明天，局部地区性雷暴，90华氏度74华氏度...

然后，它会继续读出丰富的面板内容的其余部分。 用户并不需要预先知道的所有10项建议，每次名单更新。 如果他们想知道的信息是易于通过键盘导航。

为了确保我们的建议名单，增值的经验，确保第一句，在丰富的面板密切相关，其相应的建议。 例如，基于前面的例子， "weather miami"是在丰富的建议面板的第一句：“迈阿密的天气”。

雅虎无障碍实验室，维克多Tsaran，说明如何在Firefox与NVDA屏幕阅读器：

屏幕阅读器的经验为我们的应用程序更容易遵循，因为我们现在只集中在以下两个可视化组件：

• 搜索框
• 丰富的面板

作为一个整体的自动完成列表的变化，不再跟踪，并提交按钮被忽略，因为用户可以随时打当前查询输入或使用键盘快捷键（蒂尔达访问键： [control, alt or shift] + ~输入元素和丰富的面板之间切换。 这些键盘导航选项时，搜索框被承认的屏幕阅读器的用户透露。

从工程的角度来看，这种变化极大地简化了的事情。 DOM操作中最活跃的组成部分的金额大大减少，提高整体性能直接搜索。 下面是一个执行的例子：

函数SDAAria（）{
     VAR节点= this._liveRegion = Y.Node.create（“<div role="status" class="off-screen" aria-live="assertive"> </ DIV>”）;
     / /创建的ARIA活区...
     y.one（'身体'）追加（节点）;
     / /听咏叹调：实时信息更新现场区域
     this.on（咏叹调：活'，this._handlerMsg，本）;
     / /听八卦：刷新公布的许多建议如何
     this.on（“闲话：this._handleGossipRefresh，这刷新”，）;
 }
 SDAAria.ATTRS = {
     字符串：{
          valueFn：函数（）{
             返回Y.Intl.get（“SD-ARIA”）;
          }
      }
 };
 SDAAria.prototype = {
     _ariaSay：功能（stringId，潜艇）{
         VAR消息= this.get（“字符串”+ stringId）| |';
         this._liveRegion.setContent（潜艇Y.Lang.sub（消息，潜艇）：消息）;
     }，
     _handlerMsg：功能（E）{
        如果（e.id）{
             this._ariaSay（e.id，e.subs）;
         }
     }，
     _handleGossipRefresh：函数（）{
        尺寸大小（）。= this.get（'建议'）;
         this._ariaSay（（> 0的建议“：”NO_SUGGESTIONS'）{
             N：大小
         }）;
     }
 };

吸取的经验教训

当创建一个访问接口，重要的是要提出正确的问题。 使每一点你的应用程序访问，未必是正确的做法。

屏幕阅读器的用户，从早期的反馈要求 - 不假设你有你的基地覆盖，直到你得到一些用户的反馈。 利用各种工具和功能，在您的处置，可能没有预期的效果。

屏幕阅读器的用户可能会遇到困难，跟踪实时更新，尤其是当屏幕阅读器的通知轰炸。 在这些情况下，少可以成多。 什么是重要的，而不是试图复制的屏幕阅读器的应用程序的原始经验的用户识别和集中。

作者简介：雅虎搜索直接首席前端Caridy帕蒂诺，。 他一直是一个长期的YUI所提供和鼓泡库YUI的扩展，以及旅客在YUIBlog.com博客分享一些他建立广泛的高性能Web应用程序的经验的作者。 载入策略，事件驱动的架构和SSJS一些其中Caridy花费他的大部分时间，这些天的主题。

找到的谈话： bloglines technorati

共享和扩展： 书签del.icio.us Digg它！ | reddit！