web前端开发鼠标选中效果 网站WEB前端开发需要掌握什么技术？

最近经常有小伙伴私信询问web前端开发鼠标选中效果 网站WEB前端开发需要掌握什么技术？相关的问题，今天，我爱编程网小编整理了以下内容，希望可以对大家有所帮助。

刚学html，关于网页前端设计怎么实现这种效果？ 在同一个页面有两个登陆窗口，以及上面下拉出现很多

使用CSS的hover选择器可以实现这个方法，具体你需要多学多练习，直接看代码很难看懂的。
关于这个选择器，网上有很多介绍和例子。可以去看看。
解决思路是这样子的：默认情况下内容为隐藏，至于怎么隐藏，随你喜好，可以高度为零，也可以使用内容溢出到可见范围外，还可以调整display属性为none;
当鼠标激活hover选择器后，将内容转变为可视化就可以了。

如何开发无障碍的Web网页应用详细手册教程指南_html/css_WEB-ITnose

最近看到一篇非常好的文章，关于开发无障碍的web网页的内容，其实我们的工作中很少会去要求这方面的需求，但是其实如果我们能在开发过程中稍微留心的去安下文中的方法去做也耗费不了多少功夫，但是这么小的举动却可以帮助很多残疾人士，希望转载过来这篇文章可以让更多从事前端的同学看到。
Web无障碍设计（Accessibility in Web design，也叫网站可及性 ）是要让所创建的网站对所有用户都可用/可访问，不管用户的生理/身体能力如何、不管用户是以何种方式访问网站。
为什么无障碍如此重要（帮助残障人士） 为什么不是所有网站都能无障碍访问？你可能也会问自己为什么存在“无障碍”的问题，为什么不是所有网站都能让所有用户无障碍访问？要进行无障碍设计有许多不同原因，其中包括残疾人用户的需求、不同的人访问和使用互联网的不同途径和方式。
视障用户视障用户包括色盲用户、完全失明用户（盲人）。如果图片不带有相关文字描述，则视障用户在理解图片方面会存在问题。如果图片没有文字描述，看不见图片的盲人用户就无法知道图片表达的是什么。色盲用户在识别设计元素（包括文字）方面也会存在问题，因为色盲用户所能识别的色彩不足以辨别所有的设计元素（包括背景色和页面颜色）。
所开发的网站，如果没有考虑到适应于屏幕发音阅读器（ 读屏软件 ,如JAWS ）或“非可视”浏览器（或叫声音浏览器、读屏浏览器，如 MozBraille ）。读屏浏览器是一个可以发音阅读出网站的浏览器，帮助有视觉障碍的用户访问网站。一个在可视浏览器（如IE）上看起来良好的网站，在读屏浏览器下可能听起来非常糟糕。
听障用户听障用户在听觉上存在问题。用声音传达的信息无法被听障用户所理解，简单解决方法是提供另外途径的信息传达方式，而不仅仅是声音，例如用文字描述、用图片。
残障用户（肢体伤残的用户）如果你不是残障用户，你无法想象他们（残疾人）的网络体验。例如，你曾经试过不使用鼠标去访问网站吗？除非你很幸运的遇到一个无障碍访问良好的网站，否则你肯定觉得非常困难。残障用户经常无法使用鼠标，除非创建网站的导航和输入方式的需求中就考虑残障人士的需求，否则残障人士可能完全无法使用你的网站。
认知和神经障碍用户网站往往比较复杂，要想找到我们所想要的信息经常不太容易。如果网站设计的过于复杂、导航不一致、存在让人分心（抓狂）的重复性动画，情况会更加糟糕。这些设计元素会导致认知和神经有障碍的用户的使用问题，甚至会让这些用户完全无法使用网站。
残障人士之外（所有用户都能受益） 前面我们知道如果我们存在某方面残障，使用互联网是件困难的事情。然后，web无障碍访问不仅仅帮助到残障人士，良好理解和遵循Web无障碍设计，可以让所有用户都受益、更好的服务用户。
Web无障碍设计还可以让通过以下方式使用你的网站的用户受益：
使用移动手机、Web-TV和信息岗亭的用户
低带宽的用户
在吵杂环境下使用网站的用户
容易被“屏幕眩光”伤到眼睛的用户
开车时的用户
低文化水平的用户
第二语言访问的用户（国外用户）
不同学习方式和习惯的用户
处理好Web无障碍访问问题也可以改善：
页面传输和网站维护
内容索引
内容搜索
市场机会让你的网站具有可及性还有其它原因。根据目前数据，在许多国家残疾人用户占到人口的10%~20%，如果能吸收前面提到的残障人士成为你的网站的用户，可以提高你网站的市场占有率。
许多国家的老龄化人口都在增加，年龄的增大会带来更多的无障碍访问问题，包括视觉障碍、听觉障碍、记忆力下降等。如果你的网站能吸收老年人用户，也会大大提升你网站的市场占有率。
所以，无障碍访问是可以直接带来经济效益的。
无障碍Web标准 Web无障碍指南（WCAG）2.0定义了如何使残疾人士更方便地使用Web内容的方法。无障碍涉及广泛的残疾症状，包括视觉，听觉，身体，语言，认知，语言，学习以及神经残疾。尽管这些指南内容广泛，但它无法有效地满足所有类型的人群和残疾程度的人的需要。这些指南也适合老年人上网，还可让普通用户更好的使用。WCAG 2.0文档旨在满足需要稳定的，可参考的技术标准的人群。被称为支持文档的其他文档以WCAG 2.0文档为基础，可用于其他重要的用途，包括可进行更新的能力，以说明如何将WCAG用于新技术的应用。支持文档包括：
如何符合WCAG 2.0 - WCAG 2.0的可定制的快速参考，包括所有的指南、成功标准以及作者正在开发和评估网页内容时可用到的技巧。
理解WCAG 2.0 - 理解和实施WCAG 2.0的指南。对于WCAG 2.0的每一个准则和成功标准，这些主要议题都有一个简短的“理解”文档。
WCAG 2.0技巧 - -技术和常见失败集，对于每个技巧和常见失败，另附一份文档，其中包括描述，例子，代码和测试。
WCAG 2.0文档 - 对于如何关联和链接技术文档，给出 图示和说明。
参见 Web 内容无障碍指南（WCAG）概述 里关于WCAG 2.0支持材料的描述，包括WCAG 2.0相关的教育资源。附加资源包括了以下主题，Web无障碍商业案例，改善网站无障碍的规划实施，和无障碍政策。
开发无障碍可访问的 Web 网页应用 开发和测试可访问的 Web 应用主要的有以下几个步骤：
Webking 进行静态检查，通常由开发人员在单元测试时进行，检查 HTML 页面中不满足 CI162 所对应列表的项。目前由于 WebKing 不支持 ARIA，很多 ARIA 的标签不能被正确的识别，所以 WebKing 检查出的错误需要一一去检查区别是真正的违反 Checklist 还是由于 WebKing 不能识别 ARIA 的标签引起的。
键盘支持，要求所有能通过鼠标完成的操作用键盘都能达到同样的效果。
高对比度的支持：在高对比度模式下，屏幕只有黑白两色，要保证 Web 应用在这种模式下不丢失信息。
读屏软件的支持，通常由测试人员完成。测试人员模拟盲人使用读屏软件，要保证页面上的内容基本都能为读屏软件所识别，并且能完成各种操作。
页面头部必须包含的内容 为了保证页面的无障碍访问，首先需要在页面的头部加上 DTD 的声明以及页面默认的语言。清单 1 列出了如何在 HTML 页面中加入 DTD 声明及默认语言属性，清单 2 列出了如何在 XHTML 页面中加入 DTD 声明及默认语言属性。
清单 1. HTML 页面中加入 DTD 声明及默认语言属性清单 2. XML 页面中加入 DTD 声明及默认语言属性此外，页面的 title 属性值也是必须的，如清单 3 所示。
清单 3. 设置 title 属性关于 Image 1. 图片或者动画均需提供 Alt 信息，使得读屏软件可以将图片动画的内容清楚的读出来。如图 4 所示：
图 4.Cat 图片 对应的 HTML 如下：
清单 1. Image 的 HTML2. 对于某些用于装饰性的图片，则需设置 alt 为空，使得读屏软件可以忽略此元素。如图 5 的用于装饰页头的图片，实际并没有传递有价值的信息。
图 5. 装饰性图片

对应的 HTML 如下：
清单 2. 装饰性 Image 的 HTML必须设置一个空 alt 属性的目的是为了能通过 Webking 的检查，并且使得读屏软件能够忽略此元素。
3. 对于图表文件，alt 属性的设置则需要简明扼要的表达出图表的信息，并不用把里面的细节都详细得描述出来。例如下面的图 6：alt 信息设置为销售额从 1996 年到 2004 年间持续稳定增长，从 400 万增长到了 1600 万。并不需要把每一年的增长额都详细得描述出来。
图 6. Image 图表

4. 对于放在链接里面的图片，如果已经有文字的说明，alt 也设置为空，这样避免读屏软件重复同样的内容。如下面的 HTML：
清单 3. 无需重复设置 alt 的 Image +tundra .dijitMenuExpand { width: 7px; height: 7px; background-image: url('images/spriteArrows.png'); background-position: -14px 0px; } .dijitMenuExpandA11y {display: none; } .dijit_a11y .dijitMenuExpandA11y {display: inline; } 快速链接到主要内容为了使屏幕阅读器可以略过页面中的一些普通元素快速跳到页面的功能区域，开发人员需要在页面中添加一些链接。在下面的页面中，主要内容即为左侧的导航栏，用户可以通过点击导航栏中的链接打开相应的页面。清单 4 和清单 5 列出的代码可以帮助有视力障碍的用户快速定位到导航栏。
图 1. 示例页面

清单 4. HTML 代码片段 Skip to main content ... Human Ability and Accessibility Center Developer guidelines Web checklist .....清单 5. CSS 代码片段
div.ibm-access { position: absolute; margin-top: -9999px; } 无障碍访问的表单控件
标签控件与标题属性
在 Web 页面中经常会用到表单进行信息的录入与更新。大部分的表单控件可以自动与一个标签控件建立关联，使得屏幕阅读器可以将标签中的文字内容作为表单录入控件的说明信息，比如提交按钮。但是诸如文本框，下拉菜单，复选框以及单选按钮这样的控件则需要开发人员为其指定一个标签控件，同时设置标签控件的 for 属性值为与其建立关联的控件的 id 属性值。清单 6 与清单 7 分别列举了如何为文本框与下拉列表添加与其关联的标签控件。
清单 6. 为文本框的标签控件设置 for 属性 Name清单 7. 为下拉列表的标签控件设置 for 属性
Select your shipping method Ground _ 7 business days Air _ 3 business days Next day air _ 1 business day 然而并不是所有的表单控件都适合采用上述方式添加标签以保证其可读性，单选按钮通常是一组按钮具有同一个 id 属性值，所以我们无法通过上述方法为每一个按钮添加标签，我们可以利用 title 属性来保证其可读性。例如：
清单 8. 为复选框设置 title 属性提示：无需为隐藏控件添加与其关联的标签控件。
必输字段
为了使得屏幕阅读器可以将必须输入的字段限制信息传达给用户，开发人员可以使用 WAI-ARIA 提供的属性，示例如下：
清单 9. 设置属性限制字段必须输入

* Phone number:但是目前 IE8 还不支持这种属性，由于屏幕阅读器可以读出用于录入信息的表单控件的 title 属性，所以我们可以将限制信息写在 title 中。如清单 10 所示：
清单 10. 利用 title 属性标识字段为必输项

* Phone number:可“读”的图片
随着 Web 页面的友好性不断提高，图片的使用也越来越广泛。然而对于无法亲眼看到页面的用户需要借助屏幕阅读器才能够知晓当前阅读的内容是一张图片以及该图片的作用，对于页面中所有有意义的图片，尤其是一些动态的图片，比如链接或是按钮，开发人员必须要给出其 alt 属性值。如清单 11 所示：
清单 11. 为图片设置 alt 属性

提示：请尽量避免使用图片作为背景，如果需要，请在 CSS 文件中指定。
创建无障碍访问的数据表格
在 Web 页面中通常有两种用途的表格，一种用于页面布局，另外一种用于显示数据。
数据表格需要用指定行或列的标题行，同时还需要显式地指定 summary 属性值，使得屏幕阅读器可以读出表的主要用途。如清单 12 所示：
清单 12. 数据表格

清单 13. 设置表格的 role 属性 ... 然而并非所有的浏览器都支持 WAI-ARIA 属性，这种情形下，我们可以设定表格的 datatable 属性值为 0, 这样 JAWS 也会将其视为布局表格。
清单 14. 设置表格的 datatable 属性 ... Id 属性值唯一
在 Web 页面中必须保证每个元素的 id 属性值在页面中是唯一的，如果有重复 id 值，WebKing 会提示出错。
提供必要的指导信息
页面中隐式的添加一些必要的指导信息可以使得无法看到 Web 页面的用户在屏幕阅读器的帮助下清楚的了解页面的功能以及如何快速使用这些功能。如清单 15 所示：
清单 15. 利用标签设置提示信息 Start of left navigation 在 Web 页面中，为了保证表单中录入的数据真实有效，需要对表单中的一些输入字段加以验证，为保证验证生成的反馈信息可以被无障碍的访问即屏幕阅读器可以在表单验证后的第一时间将反馈信息传达给用户，需要对页面代码做一些修饰。表单验证可以分为客户端验证与服务器端验证。以下将分别讨论这两种场景。
来自客户端验证的信息
Dojo 输入域的验证
随着对表单控件功能性需求的不断提高，Dojo 控件得以广泛使用。大部分的 Dojo 控件都实现了无障碍访问，当输入不符合输入字段限制的数据时，屏幕阅读器可以快速捕捉并阅读错误信息。如清单 16、17 所示：
清单 16. HTML 中加入 Dojo 输入域U.S. Dollars清单 17. 借助 JavaScript 实现验证在上述实例中，当输入无效的数据时，JAWS 就会阅读 invalidMessage 属性值的内容。
使用 WAI-ARIA 属性实现输入域验证
我们可以使用 WAI-ARIA 提供的属性使得 JAWS 可以读出验证消息。以下是一个应用场景示例，使用 JavaScript 将 div 的 role 属性值设置为 alert。
清单 18. 借助 JavaScript 设置 div 的 role 属性function showErrorMsg(msg){ var msgContainer = document.createElement('div'); msgContainer.setAttribute('role', 'alert'); msgContainer.setAttribute('id', 'alert'); var msg = document.createTextNode( ‘ Error Message ’ ); msgContainer.appendChild(msg); document.body.appendChild(msgContainer);} 或者，开发人员可以在 html 代码中为用于错误信息显式的元素设置 role ＝ alert，在 JavaScript 代码中更新错误信息。如清单 19、20 所示：
清单 19. HTML 代码片段
清单 20. 在 JavaScript 中设置错误信息 function testAlert() { ?? document.getElementById("errorMessage").innerText = "Invalid format"; ?? } 当验证后错误信息会显示在页面中指定的位置，JAWS 会立即阅读错误信息，帮助用户快速定位到不满足输入条件限制的输入域。
来自服务器端验证的信息
服务器端验证的反馈信息与客户端有所不同，当页面提交经过服务器端验证后会重新生成页面，所以 WAI-ARIA 所提供的 role=alert 无法支持屏幕阅读器去阅读验证信息。对于服务器端验证的场景，在这里给出几种实现方案。
借助页面标题提示信息
页面重新加载后，JAWS 会首先阅读页面的标题，所以我们可以在页面标题中加入提示信息提醒用户当前页面校验存在错误信息。在下面的示例中，错误信息是在服务器端校验后动态生成的。
清单 21. 在中显示错误信息
清单 22. 借助 JavaScript 修改页面标题 if(document.getElementById("errorMessage").innerText!="") document.title +=" - Please Using arrow key to read error message";借助焦点定位提示信息
当页面重新载入时，JAWS 会首先阅读第一个获得焦点的页面元素。但是有些页面元素是无法获取焦点的，比如 < div > 和 < p >。如果错误信息是在 div 中显示，我们可以通过设置 tabindex 的值为 -1 使得 div 可以在 JavaScript 中设置其获取焦点。如清单 23、24 所示：
清单 23. 在 中显示错误信息?? 清单 24. 在 JavaScript 中设置焦点 document.getElementById(“errorMessage”).focus 当页面元素的 tabindex 值为 -1 时，这个元素并不会被包含在 tab 队列中。开发人员只能通过代码控制其获取焦点。如果用户需要将其包含在 tab 队列中，可以将其 tabindex 值设置为 0.
多个验证消息的处理
如果有几个输入字段同时验证出错 , 我们可以以链接的形式显示错误信息，屏幕阅读器通过阅读链接帮助视力有障碍的用户快速定位到出错字段进行更正。每个需要校验的输入字段都需要有与其关联的 。如清单 25、26 所示：
清单 25. HTML 页面中的输入域示例 * Phone number:清单 26. 在 JavaScript 中设置错误信息的链接目标 function testError() { var msgContainer = document.createElement("div"); var summaryMsg = document.createTextNode(“There is one error message”); var msg = document.createElement("a"); msg.setAttribute("href","#phone"); msg.innerText = "Phone number is required"; msgContainer.appendChild(msg); document.body.appendChild(msgContainer); } 提示 ：从上述示例中可以看到如果在当前页面显示错误信息并且保证其可读，会增加代码的复杂性。在满足需求的情况下可以尝试在特定的错误页面中显示错误信息，这样可以降低代码的复杂性。
伴随页面功能性需求的不断提高，人们也越来越关注页面的美观性。但是在设置页面的颜色方案时要保证页面的字体颜色与其相应背景色的深浅度对比要至少达到 5：1，开发人员可以利用 Contrast Analyser 验证当前页面的颜色对比度是否满足这个比例。
图 2.Contrast Analyser 验证

如何测试无障碍的 Web 网站应用 目前有很多用于测试无障碍访问（AVT，Accessibility Verification Test）Web 应用的工具，较为常用的有
NVDA ：绝大部分读屏软件都是收费的，而 NVDA 是一个免费开源的读屏软件，而且做的很不错， NVDA 2011.2 中文用户指南
WebKing：是由 Parasoft 发布的一款静态扫描工具，用户可以在该工具中指定需要扫描的 web 页面文件的目录实现批量扫描。
JAWS：是由 Freedom Scientific 发布的一款屏幕阅读器， 它通过阅读页面的文字帮助使用者快速了解页面功能，完成相关操作。
Web 开发人员可以借助这几种工具验证所开发的 Web 页面是否可以实现无障碍访问。
总结 本文介绍了开发测试可访问无障碍的 Web 应用的工具，步骤以及开发中的最佳实践。应用这些最佳实践与小技巧能帮助您在开发中迅速的为您的 Web 应用提供 A11Y 的支持。
文：IBM
本文转自：-to-develop-accessible-web-site-application/#prettyPhoto

我爱编程网

网站WEB前端开发需要掌握什么技术？

1.开发语言
HTML发展历史有二十多年，历经多次版本更新，HTML5和CSS3的出现又是一次革新。有些人认为前端开发要掌握的技能简单，不就是制作网页 嘛，其实不然，web前端需要掌握的核心语言xHTML+CSS+JavaScript，JavaScript作为最难的语言之一，许多编程高手也不敢妄 自菲薄自封精通。由于JavaScript与html的差异性，以及静动态分开处理的一些好处。在大公司编写静态效果和动态效果往往是分开由不同的人完成 的。小公司因为需要压缩成本，就要求每个人会的越多越好，如果您想往项目经理发展，能懂一两门后台语言，绝对是锦上添花！
2.浏览器兼容性
互联网目前主流浏览器有IE6\7\8\9，Firefox，Chrome，Opera，Safari，遨游，包括国内主流的搜狗，腾讯 TT，360，the World等等；从内核上讲主要有IE的，遨游版IE，safari，firefox以及opera的，这些都是大家常见的，如果你身边有老网虫喜欢收藏 浏览器，你翻翻他的硬盘，相信几十款肯定是有的（或查看前端社区 www.w3cFuns.com 中的浏览器大全）。每种内核对代码的解析是不完全一样的，即使同样内核也可能存在很大差异，如IE和遨游版的IE。不说非主流的浏览器，就主流的浏览器要做到完全兼容，也并非易事，需要长时间的积累和测试，需要前端开发工程师对前端开发的热爱和激情。
目前移动互联网的发展趋势也不容小觑，将慢慢占据互联网的主要份额。移动互联网最突出的好处是方便和及时，试想一下，走在某地风景很好，拍下来后自 动分享给各路好友，因此手机上的浏览器兼容也看刻不容缓，现在手机上的浏览器也是纷繁复杂，主流的UCWEB，safari，IE，3G门户的，以及 symbian低端机的“残缺儿童”，包括国外流行手机我们不知道的一些浏览器，更糟糕的是这些浏览器解析因为手机硬件的不同，每个浏览器得到的结果都是 完全不同的。
3.hack技术
由于不同的浏览器对CSS的解析认识不一样，因此会导致生成的页面效果不一样，这个时候就需要针对不同的浏览器写不同的CSS，这个过程叫CSS hack。虽然我们写代码都要求按照标准，不写hack代码，但实际工作中为了兼容主流浏览器，hack代码是免不了的，所以这也应该是每个前端开发人员 必备的技能。
4.业内标准
目前Web前端开发中提到最多的就是W3C标准，这是一系列标准的集合，代表了互联网发展的方向，也代表了前端开发的一种信仰。写的代码都要100%通过标准验证，为通过标准验证而感到自豪，会有效推动互联网的快速发展。
5.开发工具
目前比较流行的是Dreamweaver， 其曾经风靡一时，到现在也没有退出历史舞台，证明DW还是有很大优势的，尤其是针对初学者，其强大的提示功能可以帮助我们很快的熟悉并掌握网页布局，但现 在更提倡的是纯手写代码，既体现技能方面的卓越，也可有效避免使用DW等工具产生的冗余代码。此外再掌握一些photoshop技能，即使没有美工，也能 简单处理一些图像。

以上就是我爱编程网小编整理的内容，想要了解更多相关资讯内容敬请关注我爱编程网。