접근성 및 이러한 모든 JavaScript 프레임 워크

접근성 및 이러한 모든 JavaScript 프레임 워크

---

저는 Backbone.js 및 Batman.js와 같은 몇 가지 JavaScript 프레임 워크를 한동안 조사해 왔으며 정말 마음에 드는 부분이 하나 있습니다. 그 문제는 접근성입니다.

웹 개발자로서 저는 특히 점진적 향상이라는 아이디어를 사용하여 접근성을 염두에두고 웹 사이트와 애플리케이션을 만들려고 항상 노력했습니다.

이러한 새로운 JS 프레임 워크는 당연히이 새로운 JS 프레임 워크가 정상적으로 저하되지 않으므로이 문제에 대한 다른 개발자의 생각과 이에 대해 무엇을하고 있는지 궁금합니다. 결국 웹 사이트 / 앱의 접근성은 많은 국가에서 법률의 일부이기 때문에 실제로 선택 사항이 아닙니다.

아마도 나는이 주제에 대해 지나치게 열심이고 접근성 측면에서 얼마나 멀리 왔는지 인식하지 못하고있을 수 있습니다.

---

최신 사이트에서 js-framework (제 경우에는 spine.js)를 사용합니다. 여전히 나는 비 -js 브라우저 (확실히 열정적이지 않은 : SEO 생각)가 내 사이트를 탐색하고 콘텐츠를 소화 할 수 있는지 확인합니다.

예를 들어 제품이 표시된 검색 페이지로 이동합니다. 제품을 페이징, 필터링, 정렬 할 수 있습니다. 물론 이것은 일반화 된 아이디어의 예입니다.

PREREQ : 서버 측과 클라이언트 측을 모두 렌더링 할 수있는 템플릿 엔진을 사용합니다. (나는 콧수염을 사용합니다). 이를 통해 서버 측 템플릿을 통해 js없이 모델을 렌더링하고 클라이언트 측 템플릿을 통해 js로 모델을 렌더링 할 수 있습니다.

1. 초기 : 서버 측 콧수염 템플릿을 사용하여 제품을 렌더링합니다. 또한 JSON 형식의 동일한 제품을 포함하는 'bootstrapJSON'객체를 포함합니다.

2. 초기 : 모든 링크 (제품 상세 페이지, 페이징, 정렬, 필터링)는 실제 서버 측 URL입니다 (해시 뱅 URL 없음).

3. 최종 결과는 JS를 사용하지 않고 페이징, 정렬, 필터링으로 100 % 탐색 할 수있는 페이지입니다.

4. 모든 페이징, 정렬, 필터링 URL은 서버에 대한 요청으로 이어지며 결과적으로 새로운 제품 세트가 렌더링됩니다. 여기에 특별한 것은 없습니다.

5. JS 사용-domload에서 :

   • bootstrapJSON을 가져 와서 제품 모델을 만드십시오 (js-framework 기능을 사용하십시오).
   • 나중에 동일한 콧수염 템플릿을 사용하여 제품을 다시 렌더링하지만 이제는 클라이언트 측에서 수행합니다. (다시 js 프레임 워크를 사용하여).
   • 시각적으로 아무것도 변경해서는 안되지만 (모든 서버 측 및 클라이언트 측 렌더링이 동일한 템플릿을 사용하여 동일한 모델에서 수행 된 후) 적어도 지금은 클라이언트 측 모델과 뷰 사이에 바인딩이 있습니다.
   • URL을 hashbang-url로 변환합니다. (예 : / products / # sort-price-asc) js-framework 기능을 사용하여 이벤트를 연결합니다.

6. 이제 모든 (필터링, 페이징, 정렬) URL은 클라이언트 측 상태 변경을 초래해야하며, 이는 아마도 js-framework가 새 제품을 반환하기 위해 서버에 ajax-request를 수행하는 결과를 낳을 것입니다 (JSON 형식). 클라이언트에서이를 다시 렌더링하면 뷰가 업데이트됩니다.

7. 서버 측에서 6.에서 ajax-request를 처리하는 코드의 로직 부분은 4에서 사용 된 코드와 100 % 동일합니다. ajax-call과 일반 요청을 구별하고 JSON 또는 html로 제품을 뱉어냅니다. (콧수염 서버 측 사용) 각각.

편집 : 2013 년 1 월 업데이트이 질문 / 답변이 합리적인 견인력을 얻고 있기 때문에 작년과 밀접하게 관련된 아하 순간을 공유 할 것이라고 생각했습니다.

• JSON을 뱉어 내고 선택한 클라이언트 측 mvc (위의 6 단계 및 7 단계)를 사용하여 클라이언트 측으로 렌더링하는 것은 CPU 측면에서 상당히 비용이 많이들 수 있습니다. 물론 이것은 특히 모바일 장치에서 분명합니다.

• 위의 답변에서 제안한 것처럼 클라이언트 측에서 동일한 작업을 수행하는 대신 서버 측 콧수염 템플릿 렌더링을 사용하여 ajax에서 html 스 니펫을 반환하는 테스트를 수행했습니다. 클라이언트 장치에 따라 최대 10 배 더 빠를 수 있습니다 (1000ms-> 100ms). 물론 마일리지는 다를 수 있습니다. (7 단계에서 이미 두 가지를 모두 수행 할 수 있으므로 실제로 코드 변경이 필요하지 않습니다.)

• 물론 JSON이 반환되지 않으면 클라이언트 측 MVC가 모델을 빌드하고 이벤트를 관리하는 등의 방법이 없습니다. 클라이언트 측 MVC를 유지하는 이유는 무엇입니까? 솔직히 말해서, 매우 복잡한 검색 페이지조차도 클라이언트 측 mvc를 전혀 사용하지 않습니다. 나에게 유일한 진정한 이점은 클라이언트에서 논리를 명확하게 분리하는 데 도움이된다는 것입니다.하지만 이미 자신의 imho에서 수행하고 있어야합니다. 결과적으로 클라이언트 측 MVC를 제거하는 것은해야 할 일입니다.

• 오 예, 저는 Mustache를 Hogan 과 거래했습니다 (동일한 구문, 약간 더 많은 기능,하지만 대부분은 매우 성능이 뛰어납니다!). 백엔드를 Java에서 Node.js로 전환했기 때문에 그렇게 할 수있었습니다.

---

저는 시각 장애가있는 사용자이자 웹 개발자이기 때문에 여기에서 차임 할 것입니다.

내 경험상 이러한 프레임 워크는 접근성과 관련하여 적절한 조치를 취하면 문제가되지 않았습니다.

많은 스크린 리더가 자바 스크립트를 이해하고 있으며, 개발자로서 HTML5의 aria-live 속성과 같은 기능을 사용하여 화면 리더에게 상황이 변경되고 있음을 알리는 경험을 개선 할 수 있으며, role 속성을 사용하여 스크린 리더에게 추가 힌트를 제공 할 수 있습니다.

그러나 JavaScript를 사용한 웹 개발의 기본 원칙은 JavaScript없이 먼저 기본 사이트를 개발 한 다음 견고하고 작동하며 테스트 된 기반을 사용하여 더 나은 기능을 제공해야한다는 것입니다. 제품을 구매하거나 서비스를 받거나 정보를 얻기 위해 JS를 사용해야하는 것은 아닙니다. 일부 사용자는 화면 판독기가 작동하는 방식을 방해하기 때문에 JavaScript를 비활성화합니다.

접근성을 고려하지 않고 완전한 Backbone.js 또는 Knockout 사이트를 처음부터 수행하면 많은 스크린 리더에서 매우 어렵게 실패하는 "새로운 Twitter"와 유사한 결과가 발생합니다. 하지만 트위터는 탄탄한 기반을 가지고 있으므로 다른 수단을 사용하여 플랫폼에 액세스 할 수 있습니다. 잘 만들어진 API가있는 기존 사이트에 Backbone을 접목하는 것은 꽤 할 수 있고 매우 재미 있습니다.

따라서 기본적으로 이러한 프레임 워크 자체는 jQUery 자체보다 접근성 문제가 아닙니다. 개발자는 모두에게 적합한 사용자 경험을 만들어야합니다.

---

콘텐츠를 가져 오기 위해 자바 스크립트 가 필요한 모든 웹 페이지는 접근성 관련 문제에 직면 할 수 있습니다. JavaScript 프레임 워크의 접근성은 확실히 경합의 문제입니다. 실제로 모든 웹 애플리케이션은 사용되는 프레임 워크에 관계없이 콘텐츠가 동적으로 제공 될 때 단점이 있습니다.

귀하의 사이트에 액세스 할 수 있도록 보장하는 은색 총알은 없으며 모든 JavaScript 프레임 워크를 설명 할 수는 없습니다. 다음은 JavaScript를 사용할 때 사이트에 완전히 액세스 할 수 없도록하는 방법에 대한 몇 가지 생각입니다.

• 클라이언트 측 스크립팅 에 대한 WCAG 2.0 및 일반적인 WCAG 2.0 의 지침을 따릅니다 .

• Uki.js 와 같은 자바 스크립트를 통해 페이지의 UI, 컨트롤 및 / 또는 콘텐츠를 완전히 생성해야하는 프레임 워크 또는 Jo 와 같은 고유 한 마크 업을 사용하는 프레임 워크는 피하세요 . 정적 (-ish), 의미 론적 HTML 콘텐츠에 가까울수록 더 나은 결과를 얻을 수 있습니다.

• 동적 페이지 영역을 나타 내기 위해 및 속성 과 같은 ARIA 역할을 사용 하는 것이 좋습니다. 시간이 지남에 따라 보조 장치에서 점점 더 많은 aria 역할을 지원하므로 이러한 aria 속성을 앱에 적절하게 추가 할 수있을 때 사용하는 것이 좋습니다.role="application"aria-live

  In terms of JS libraries, check their source and see if they output any aria roles. They might not be perfectly accessible, but it would demonstrate they're considering assistive devices.

• Wherever possible, treat JavaScript as an enhancement rather than a necessity. Try to provide alternative methods or workflows to accessing the important information that don't require dynamic page updates.

• Test and validate your app with your users! Do some user testing sessions with people who use assistive devices or have other difficulties using web software. Nothing will help you prove your site is accessible more than watching real people use it.

The last point is the most important, though many try to escape it. Regardless of the technology, the fact remains that you're developing an application that people will use. No machine or theory will ever be able to perfectly validate your application as being usable, but you're not building it for machines anyway. Right? :)

---

Chris Blouch (AOL) and Hans Hillen (TPG) had a good presentation on this regarding jQuery, including the work they do in reviewing for accessibility. Making Rich Internet Applications Accessible Through JQuery That and another related presentation on Accessibility of HTML5 and Rich Internet Applications (http://www.paciellogroup.com/training/CSUN2012/) should be of interest to you.

My money is on choosing the most accessible framework: jQuery provides a great deal of graceful degradation or progressive enhancement fallback as well as an overall pretty good focus on accessibility. Also, indirectly I help test and review several systems that leverage jQuery (Drupal public and Intranet websites) such that defects found for accessibility are found and routed back to the project for fixes.

참고URL : https://stackoverflow.com/questions/7370056/accessibility-and-all-these-javascript-frameworks