Hỗ trợ tiếp cận cho nhóm

Cách lồng ghép khả năng hỗ trợ tiếp cận vào quy trình làm việc của nhóm.

Làm cho trang web của bạn dễ tiếp cận hơn có thể là một nhiệm vụ khó khăn. Nếu đây là lần đầu tiên bạn tiếp cận khả năng hỗ trợ tiếp cận, thì phạm vi hoàn toàn của chủ đề này có thể khiến bạn phân vân không biết nên bắt đầu từ đâu. Xét cho cùng, khi cố gắng đáp ứng nhiều khả năng, bạn cần xem xét nhiều vấn đề tương ứng.

Hãy nhớ rằng khả năng hỗ trợ tiếp cận cần đến một nhóm nỗ lực. Mỗi người đều có vai trò riêng. Bài viết này trình bày tiêu chí cho từng chuyên ngành chính (người quản lý dự án, nhà thiết kế trải nghiệm người dùng và nhà phát triển) để họ có thể tìm cách áp dụng các phương pháp hay nhất về hỗ trợ tiếp cận vào quy trình của mình.

Nhà quản lý dự án

Mục tiêu quan trọng đối với mọi trình quản lý dự án là cố gắng đưa khả năng hỗ trợ tiếp cận vào mọi cột mốc quan trọng; đảm bảo rằng chủ đề này cũng có mức độ ưu tiên tương đương với các chủ đề khác như hiệu suất và trải nghiệm người dùng. Dưới đây là một vài mục trong danh sách kiểm tra mà bạn cần ghi nhớ khi thực hiện quy trình.

  • Cung cấp nội dung đào tạo về khả năng hỗ trợ tiếp cận cho nhóm.
  • Xác định các hành trình trọng yếu của người dùng trên trang web hoặc ứng dụng.
  • Cố gắng đưa danh sách kiểm tra khả năng hỗ trợ tiếp cận vào quy trình của nhóm.
  • Nếu có thể, hãy đánh giá trang web hoặc ứng dụng bằng các nghiên cứu người dùng.

Đào tạo về khả năng hỗ trợ tiếp cận

Có nhiều tài nguyên miễn phí tuyệt vời để tìm hiểu về khả năng hỗ trợ tiếp cận trên web. Việc dành thời gian để nhóm của bạn nghiên cứu chủ đề này có thể giúp bạn dễ dàng đưa khả năng tiếp cận vào quá trình này.

Một số tài nguyên do Google cung cấp bao gồm:

Khả năng hỗ trợ tiếp cận trên web của Google – một khoá đào tạo tương tác kéo dài nhiều tuần.

Kiến thức cơ bản về tính năng hỗ trợ tiếp cận – viết hướng dẫn về hỗ trợ tiếp cận và các phương pháp hay nhất.

Material Guidelines: Hỗ trợ tiếp cận – một tập hợp các phương pháp hay nhất về trải nghiệm người dùng dành cho thiết kế bao trùm.

Xác định hành trình trọng yếu của người dùng

Mỗi ứng dụng đều có một số hành động chính mà người dùng cần thực hiện. Ví dụ: nếu bạn đang tạo một ứng dụng thương mại điện tử, thì mọi người dùng đều cần phải thêm được mặt hàng vào giỏ hàng.

Hành trình chính của người dùng: Người dùng có thể thêm một mặt hàng vào giỏ hàng.

Một số hành động có thể quan trọng thứ cấp và có lẽ chỉ được thực hiện thỉnh thoảng. Ví dụ: thay đổi ảnh đại diện là một tính năng hữu ích, nhưng có thể không quan trọng đối với mọi trải nghiệm.

Việc xác định hành động chính và phụ trong ứng dụng sẽ giúp bạn sắp xếp mức độ ưu tiên cho công việc hỗ trợ tiếp cận trước đây. Sau đó, bạn có thể kết hợp các thao tác này với một danh sách kiểm tra khả năng hỗ trợ tiếp cận để theo dõi tiến trình và tránh hiện tượng hồi quy.

Kết hợp danh sách kiểm tra khả năng hỗ trợ tiếp cận

Chủ đề về khả năng hỗ trợ tiếp cận khá rộng. Vì vậy, việc có một danh sách kiểm tra gồm các khía cạnh quan trọng cần cân nhắc có thể giúp bạn đảm bảo mình đang bao phủ mọi cơ sở.

Hiện có một số danh sách kiểm tra khả năng hỗ trợ tiếp cận, một số ví dụ trong ngành bao gồm:

Danh sách kiểm tra WCAG của WebAIM Nguyên tắc hỗ trợ tiếp cận Vox

Khi có một danh sách kiểm tra, bạn có thể xem qua các hành động chính và phụ để bắt đầu phân loại những việc vẫn cần hoàn thành. Bạn có thể có được chiến thuật đẹp mắt về quy trình này và thậm chí là tạo một ma trận gồm các thao tác chính và phụ, đồng thời xác định từng bước trong các quy trình đó, xem có bit hỗ trợ tiếp cận nào bị thiếu hay không.

Bảng có các trường hợp sử dụng chính dưới dạng hàng và các mục trong danh sách kiểm tra dưới dạng cột.

Đánh giá bằng nghiên cứu người dùng

Bạn không cần phải ngồi cạnh và quan sát người dùng thực tế khi họ cố gắng dùng ứng dụng. Nếu bạn đang trang bị thêm khả năng hỗ trợ tiếp cận cho một trải nghiệm hiện có, thì quá trình này có thể giúp bạn nhanh chóng xác định những khía cạnh cần cải thiện. Nếu bạn đang bắt đầu một dự án mới, các nghiên cứu sớm về người dùng có thể giúp bạn tránh dành quá nhiều thời gian cho việc phát triển một tính năng khó sử dụng.

Cố gắng thu thập ý kiến phản hồi của nhiều người dùng nhất có thể. Hãy xem xét những người dùng chủ yếu thao tác bằng bàn phím hoặc dựa vào công nghệ hỗ trợ như trình đọc màn hình hoặc trình phóng to màn hình.

nhà thiết kế UX

Vì mọi người có xu hướng thiết kế theo thành kiến của riêng mình, nên nếu bạn không có khuyết tật nào và không có đồng nghiệp nào bị khuyết tật, thì có thể bạn đã vô tình thiết kế cho một số người dùng của mình. Trong quá trình làm việc, hãy tự hỏi "có những kiểu người dùng nào có thể dựa vào thiết kế này?" Dưới đây là một số kỹ thuật bạn có thể thử để làm cho quy trình của bạn hoà nhập hơn.

  • Nội dung có độ tương phản màu phù hợp.
  • Đã xác định thứ tự nhấn phím tab.
  • Các chế độ điều khiển có nhãn là các chế độ dễ tiếp cận.
  • Có nhiều cách để tương tác với giao diện người dùng.

Nội dung có độ tương phản màu tốt

Mục tiêu chính của hầu hết các trang web là truyền tải một số thông tin cho người dùng, thông qua văn bản hoặc hình ảnh. Tuy nhiên, nếu nội dung này có độ tương phản thấp, thì một số người dùng (đặc biệt là những người khiếm thị) có thể khó đọc. Điều này có thể ảnh hưởng tiêu cực đến trải nghiệm người dùng của họ. Để giải quyết mối lo ngại này, hãy cố gắng tạo ra độ tương phản màu phù hợp cho tất cả văn bản và hình ảnh.

Độ tương phản được đo bằng cách so sánh độ chói của màu nền trước và màu nền sau. Đối với văn bản nhỏ hơn (bất kỳ kích thước nào dưới 18 pt hoặc đậm 14 pt), bạn nên sử dụng tỷ lệ tối thiểu là 4,5:1. Đối với văn bản lớn hơn, bạn có thể điều chỉnh tỷ lệ này thành 3:1.

Trong hình ảnh dưới đây, văn bản ở bên trái đáp ứng những mức độ tương phản tối thiểu này, trong khi văn bản ở bên phải có độ tương phản thấp.

Mẫu văn bản đặt cạnh nhau. Một là độ tương phản đủ, một là độ tương phản thấp.

Có một số công cụ để đo độ tương phản màu, chẳng hạn như Công cụ màu Material của Google, ứng dụng Tỷ lệ tương phản của Lea VerouaXe của Deque.

Đã xác định thứ tự thẻ

Thứ tự thẻ là thứ tự mà các phần tử nhận được tiêu điểm khi người dùng nhấn phím thẻ. Đối với những người dùng chủ yếu thao tác bằng bàn phím, phím tab là phương tiện chính để họ truy cập vào mọi nội dung trên màn hình. Hãy coi đây là con trỏ chuột.

Lý tưởng nhất là thứ tự thẻ phải tuân theo thứ tự đọc và di chuyển từ đầu trang xuống cuối trang, với các mục quan trọng hơn sẽ xuất hiện ở vị trí cao hơn trong thứ tự. Điều này giúp bất kỳ ai sử dụng bàn phím để truy cập nhanh các mục này sẽ hiệu quả hơn.

Một thiết kế hoàn thiện với các điều khiển tương tác được đánh số.

Giao diện mô phỏng ở trên được đánh số để hiển thị thứ tự thẻ. Việc tạo một mô hình mô phỏng như thế này có thể giúp ích bằng cách xác định thứ tự thẻ dự kiến. Sau đó, bạn có thể chia sẻ thông tin này với các nhà phát triển và người kiểm thử đảm bảo chất lượng để đảm bảo triển khai và kiểm thử đúng cách.

Các chế độ điều khiển có nhãn hỗ trợ tiếp cận

Đối với người dùng công nghệ hỗ trợ như trình đọc màn hình, nhãn cung cấp thông tin mà thường thì chỉ là hình ảnh. Ví dụ: một nút tìm kiếm chỉ là biểu tượng kính lúp có thể có nhãn "Tìm kiếm" cho người dùng tiếp cận để giúp điền vào thuộc tính tương tác trực quan bị thiếu.

Dưới đây là một số đề xuất đơn giản mà bạn cần áp dụng khi thiết kế nhãn dễ tiếp cận:

  • Ngắn gọn – Bạn có thể thấy tẻ nhạt khi nghe mô tả dài.
  • Cố gắng không đưa vào loại điều khiển hoặc trạng thái – Nếu chế độ điều khiển được mã hoá đúng cách thì trình đọc màn hình sẽ tự động thông báo điều này.
  • Tập trung vào động từ hành động – Dùng "tìm kiếm" thay vì "kính lúp".
Một thiết kế tuân thủ các chế độ điều khiển được đánh dấu bằng nhãn cho phép tiếp cận.

Bạn có thể cân nhắc tạo một bản mô phỏng có gắn nhãn tất cả các chế độ điều khiển. Bạn có thể chia sẻ thông tin này với nhóm phát triển và nhóm đảm bảo chất lượng để triển khai và kiểm thử.

Nhiều cách để tương tác và hiểu giao diện người dùng

Có thể dễ dàng giả định rằng tất cả người dùng tương tác với trang chủ yếu bằng chuột. Khi thiết kế, hãy cân nhắc cách người nào đó sẽ tương tác với một thành phần điều khiển bằng bàn phím.

Lên kế hoạch cho các trạng thái tập trung! Tức là xác định giao diện của thành phần điều khiển khi người dùng lấy tiêu điểm bằng phím tab hoặc nhấn các phím mũi tên. Bạn nên lập kế hoạch sớm cho các trạng thái này thay vì cố gắng đưa chúng vào thiết kế sau này.

Cuối cùng, ở mọi thời điểm tương tác, bạn nên đảm bảo rằng người dùng có nhiều cách để hiểu nội dung. Cố gắng không sử dụng riêng màu sắc để truyền tải thông tin, vì người dùng khiếm thị nhìn thấy màu sắc có thể bỏ qua những tín hiệu tinh tế này. Ví dụ điển hình là trường văn bản không hợp lệ. Thay vì chỉ có dấu gạch dưới màu đỏ để biểu thị vấn đề, bạn cũng nên cân nhắc thêm văn bản trợ giúp. Bằng cách đó, bạn sẽ bao gồm nhiều cơ sở hơn và tăng khả năng người dùng sẽ nhận thấy vấn đề.

Nhà phát triển

Vai trò của nhà phát triển là nơi kết hợp tính năng quản lý tiêu điểm và ngữ nghĩa để tạo thành một trải nghiệm người dùng mạnh mẽ. Dưới đây là một vài mục mà nhà phát triển có thể lưu ý khi thao tác trên trang web hoặc ứng dụng của họ:

  • Thứ tự thẻ phải hợp lý.
  • Tiêu điểm được quản lý và hiển thị đúng cách.
  • Các phần tử tương tác có tính năng hỗ trợ bàn phím.
  • Các vai trò và thuộc tính của ARIA được áp dụng khi cần.
  • Các phần tử đã được gắn nhãn đúng cách.
  • Việc thử nghiệm được thực hiện tự động.

Thứ tự thẻ logic

Các phần tử gốc như input, buttonselect được chọn sử dụng thứ tự thẻ miễn phí và tự động có thể lấy tiêu điểm bằng bàn phím. Tuy nhiên, không phải tất cả các phần tử đều nhận được hành vi này! Cụ thể, các phần tử chung như divspan không được chọn sử dụng thứ tự thẻ. Điều này có nghĩa là nếu sử dụng div để tạo một thành phần điều khiển có tính tương tác, bạn sẽ phải thực hiện thêm một số thao tác để có thể truy cập vào bàn phím của bàn phím đó.

Có hai lựa chọn:

  • Cung cấp tabindex="0" cho đối tượng điều khiển. Điều này ít nhất sẽ giúp ứng dụng có thể lấy tiêu điểm, mặc dù bạn có thể sẽ cần thực hiện thêm thao tác để hỗ trợ thêm thao tác nhấn phím.
  • Nếu có thể, hãy cân nhắc sử dụng button thay vì div hoặc span cho mọi chế độ điều khiển giống như nút. Phần tử button gốc rất dễ tạo kiểu và được hỗ trợ bàn phím miễn phí.

Quản lý tiêu điểm

Khi thay đổi nội dung của trang, bạn cần phải thu hút sự chú ý của người dùng bằng cách di chuyển tiêu điểm. Một ví dụ kinh điển về trường hợp kỹ thuật này hữu ích là khi mở một hộp thoại phương thức. Nếu người dùng dựa vào bàn phím nhấn một nút để mở hộp thoại và tiêu điểm của họ không được chuyển sang phần tử hộp thoại, thì hành động duy nhất của họ là nhấn phím tab qua toàn bộ trang web cho đến khi cuối cùng họ tìm thấy chế độ điều khiển mới. Bằng cách chuyển trọng tâm vào nội dung mới ngay khi nó xuất hiện, bạn có thể cải thiện hiệu quả trải nghiệm của những người dùng này.

Hỗ trợ bàn phím cho các phần tử tương tác

Nếu đang tạo một thành phần điều khiển tuỳ chỉnh như băng chuyền hoặc trình đơn thả xuống, bạn sẽ cần làm thêm một số việc để thêm tính năng hỗ trợ bàn phím. Hướng dẫn thực hành tạo tác giả cho ARIA là một tài nguyên hữu ích giúp xác định nhiều mẫu giao diện người dùng và các loại thao tác trên bàn phím mà chúng dự kiến sẽ hỗ trợ.

Phần trích dẫn trong hướng dẫn Thực hành ghi nhận tác giả của ARIA giải thích cách xây dựng một nhóm radio.

Để tìm hiểu thêm về cách thêm tính năng hỗ trợ bàn phím cho một phần tử, hãy xem phần chỉ mục thẻ lưu trữ trong tài liệu Kiến thức cơ bản về hỗ trợ tiếp cận của Google.

Áp dụng các vai trò và thuộc tính của ARIA khi cần

Các thành phần điều khiển tuỳ chỉnh không chỉ cần hỗ trợ bàn phím phù hợp mà còn cần có ngữ nghĩa phù hợp. Xét cho cùng, div về mặt ngữ nghĩa chỉ là một vùng chứa nhóm chung. Nếu đang dùng div làm cơ sở cho trình đơn thả xuống, bạn sẽ cần dựa vào ARIA để phân lớp ngữ nghĩa bổ sung để loại chế độ điều khiển có thể được truyền đến công nghệ hỗ trợ. Xin nhắc lại, Hướng dẫn về phương pháp tạo tác giả cho ARIA có thể giúp bạn xác định vai trò, trạng thái và thuộc tính mà bạn nên dùng. Bên cạnh đó, nhiều nội dung giải thích trong hướng dẫn ARIA cũng đi kèm với mã mẫu!

Phần tử gắn nhãn

Để gắn nhãn dữ liệu đầu vào gốc, bạn có thể sử dụng phần tử <label> tích hợp sẵn như mô tả trên MDN. Việc này không chỉ giúp bạn tạo khả năng hình ảnh trên màn hình mà còn đặt tên cho đầu vào trong cây hỗ trợ tiếp cận. Sau đó, tên này sẽ được công nghệ hỗ trợ (như trình đọc màn hình) tiếp nhận và thông báo cho người dùng.

Rất tiếc, <label> không hỗ trợ đặt tên cho các chế độ điều khiển tuỳ chỉnh (như các chế độ điều khiển được tạo bằng Phần tử tuỳ chỉnh hoặc từ các div và span đơn giản). Đối với các loại chế độ kiểm soát này, bạn cần sử dụng thuộc tính aria-labelaria-labelledby.

Kiểm thử tự động

Việc lười biếng có thể là một điều tốt, đặc biệt là đối với lĩnh vực kiểm thử. Bất cứ khi nào có thể, hãy tìm cách tự động hoá quy trình kiểm thử khả năng hỗ trợ tiếp cận để bạn không phải làm mọi việc theo cách thủ công. Hiện nay, có một số công cụ kiểm thử tuyệt vời trong ngành giúp bạn dễ dàng và nhanh chóng kiểm tra các vấn đề thường gặp về khả năng hỗ trợ tiếp cận:

aXe (do các hệ thống Deque tạo) có sẵn dưới dạng tiện ích của Chromemô-đun nút (phù hợp cho môi trường tích hợp liên tục). A11ycast ngắn này giải thích một vài cách để tích hợp aXe vào quá trình phát triển của bạn.

Lighthouse là một dự án nguồn mở của Google để kiểm tra hiệu suất của các Ứng dụng web tiến bộ của bạn. Ngoài việc kiểm tra xem PWA của bạn có hỗ trợ những nội dung như Service WorkerTệp kê khai ứng dụng web hay không, Lighthouse còn chạy một loạt bài kiểm thử phương pháp hay nhất, bao gồm cả các bài kiểm thử các vấn đề về hỗ trợ tiếp cận.

Kết luận

Khả năng hỗ trợ tiếp cận là một nỗ lực của một nhóm. Mỗi người đều có vai trò riêng. Hướng dẫn này đã trình bày một số mục chính mà mỗi thành viên trong nhóm có thể sử dụng để nhanh chóng tìm hiểu về chủ đề này và hy vọng có thể cải thiện trải nghiệm chung của ứng dụng.

Để tìm hiểu thêm về khả năng hỗ trợ tiếp cận, hãy nhớ xem khoá học miễn phí của Udacity và duyệt qua tài liệu về hỗ trợ tiếp cận có tại đây trên web.dev.