최신 웹 애플리케이션의 접근성
저는 현재 독일 고객을위한 복잡한 웹 애플리케이션을 개발하는 팀의 일원입니다 (죄송합니다, 프로젝트에 대해 아무 말도 할 수 없습니다). 우리는 "좋은 시민이 되고자"하고 접근성을 염두에두고 응용 프로그램을 개발하고 싶습니다. 우리는 이제 다음과 같은 문제에 직면하고 있습니다.
- http://www.w3.org/WAI/WCAG20/quickref/ 의 규칙을 따르면 고객이 작성한 사양과 모순되는 경우가 있습니다. 어떻게 처리해야합니까?
- "= 새로운 기술"(AJAX 및 DOM의 일부 교체))을 사용하면 규칙을 따르는 지 쉽게 확인할 수 없습니다. 예를 들어 탭 중 하나를 클릭하면, 소스 (Firefox 3.6.10)를 볼 때 전혀 변경 사항이 없으므로 규칙을 올바르게 준수하는지 어떻게 확인합니까?
질문 이이 사이트에 적합하기를 바랍니다 ...
액세스 가능한 사이트를 디자인 할 때 AJAX 사용하지 말고 DOM을 너무 많이 수정하는 것이 훨씬 어렵습니다.) 가능한 경우 표준 HTML을 사용하십시오. 대화 형 작업이 최소화 된 문서-작업이 훨씬 쉬워지고 화면 판독기 등을 사용하는 사람들의 삶이 더 쉬워집니다.
당신이 할 수있는 또 다른 일은 자바 스크립트없이 애플리케이션이 완전히 잘 작동하도록하고 유용성을 더하는 곳에서 일을 풍부하게하는 것입니다. 탭은 좋은 예입니다. 먼저 탭을 클릭 할 때 탭의 내용이 새 페이지에로드되도록 각 탭을 작성하십시오. 그런 다음 눈에 잘 띄지 않는 자바 스크립트를 사용하여 탭의 onclick 이벤트를 "강화"하여 참조 된 페이지의 내용을 가져 와서 AJAX를 사용하여로드합니다. 이제 원하는 방식으로 작동하는 액세스 가능한 탭이 생겼습니다. 앱에서 이러한 탭의 작동 방식을 제어하는 접근성 설정을 만들 수도 있습니다.
아, 그리고 뒤로 버튼을 깨지 않도록주의하십시오!
사양이 고객의 사양과 상충되는 경우 고객과 함께합니다. 접근성이 중요한 이유를 설명하고 세계의 추세를 보여줍니다. 미국의 정부 사이트의 경우 법에 의해 시행되며 가장 중요한 것은 작업을 수행 할 대체 솔루션을 생각해보십시오.
이것은 오래된 질문이지만 맨 위에 튀어 나왔으므로 여기에 답이 있습니다. 글쎄, 그다지 답은 아니지만 다른 답변에서 완전히 다루어지지 않은 몇 가지 핵심 사항은 다음과 같습니다.
- 접근성 지침은 바로 그 지침입니다. 그것들이 구식이되고 특정 상황이 결여되어 있고 접근성 소프트웨어와 잘 어울리지 않는 것을 추천하는 것에주의하십시오
- 내게 필요한 옵션의 일부는 브라우저 및 지원 장치/소프트웨어 제조업체에 있습니다. 나는 이것이 최종 사용자에게는 전적으로 공평하지 않다는 것을 알고 있지만 표준 및 모범 사례가 작동하려면 장치 및 소프트웨어 제조업체가 웹 개발자만큼 많은 것을 따라야합니다. 이와 관련하여 최신 정보)
- JavaScript는 이제 웹의 일부입니다. 그것을 요구하는 것은 완벽하게 허용됩니다. 최신 보조 소프트웨어 및 장치가이를 처리 할 수 있어야합니다 (허가 된 경우는 안됨). W3C조차도 이것을 알고 있으며 이것이 ARIA 속성이 고려해야 할 부분입니다. http://www.w3.org/WAI/intro/aria
- 항상 인간의 솔루션을 테스트하십시오. 다음과 같은 사양, 표준 및 지침을 따르는 것이 좋지만 모든 것을 얻을 수는 없습니다. 결국, 각 제품은 자체적으로 분석되어야합니다.
당신은 썼습니다 :
1. http://www.w3.org/WAI/WCAG20/quickref/ 의 규칙을 따르는 경우 고객이 작성한 사양과 모순되는 경우가 있습니다. 어떻게 처리해야합니까?
누군가가 이미 가장 좋은 점은 다음과 같습니다. 고객에게 일부 계약이 있으며 표준을 따르는 것이 좋습니다. 그리고 당신은 또한 썼습니다 :
2. "신기술"(AJAX 및 DOM의 일부 교체))을 사용하여 규칙을 따르는 지 쉽게 확인할 수 없습니다. 소스 (Firefox 3.6.10)를 볼 때 아무런 변화가 없으므로 규칙을 올바르게 준수하는지 어떻게 확인합니까?
당신이 매우 중요한 경우에 나는 당신에게 당신의 웹 사이트를 시도하기 위하여 몇몇 장님에게 요구할 것을 제안합니다. 때로는 접근성을 확인하는 도구가 최선의 선택이 아닙니다!
디자인 단계에서 웹 사이트의 정보 종류에 관계없이 웹 사이트의 접근성 문제를 고려할 수 있습니다. 접근성 규칙을 따르면 장애인을 고려할뿐만 아니라 새 웹 사이트에서 유용한 정보를 찾을 수있는 사용자의 전 세계를 고려하게됩니다.
가장 쉬운 방법은 애플리케이션을 아약스로 빌드하는 동시에 웹 사이트가 자바 스크립트없이 작동 할 수 있도록하는 것입니다. 예를 들어, xhtml 태그 (링크)를 사용하면 자바 스크립트없이 전체 웹 사이트를 사용할 수 있으며 화면 판독기 또는 음성 브라우저도 웹 사이트에서 작동합니다.
이 태그에 대한 그림은 다음과 같습니다.
< a id=\"item_menu_15\" href="?module=rapido&mitem=15"
onclick="cargar_modulo('publi_cont',
'comp=articulos&tipo=2&id=18&modv=',
'Loading...',15,this,0);return false;" >
어디:
id=dom_id (dom 객체)
href= 표시하려는 현재 컨텐츠에 대한 직접 링크를 포함해야합니다.
onclick=는 ajax 상호 작용을 빌드하고 publi_cont (dom_id-컨테이너의 경우) 및 url/parameters (comp=articulos&tipo=2&id=18&modv=) 컨테이너 내부에서 시각화하려는 경우.
아약스를 사용하거나 표시하지 않는 (직접 링크) 표시 할 정보는 동일해야합니다. 그러면 접근성 문제와 상관없이 모든 사용자가 웹 사이트를 동일한 방식으로 볼 수 있습니다. 따라서, 장애인에 따라 다른 버전의 웹 사이트를 구축 할 필요가 없습니다. 디자인 절차를 시작할 때부터 웹 사이트의 접근성 규칙을 고려해야합니다. 그러면 대상 사용자가 접근성 규칙을 고려하지 않아도되기 때문에 유용성이 향상 될 수 있습니다. 물론 고객이 필요로하는 기능에 따라 다르지만 사용성도 향상 될 수 있으므로 접근성 문제를 고려하여 대상 그룹을 늘리는 것이 좋습니다.