Kiểm thử khả năng hỗ trợ tiếp cận theo cách thủ công

Kiến thức cơ bản về kiểm thử thủ công

Kiểm thử khả năng hỗ trợ tiếp cận theo cách thủ công sử dụng các bài kiểm thử, công cụ và kỹ thuật về bàn phím, thị giác và nhận thức để tìm ra những vấn đề mà công cụ tự động không thể phát hiện. Vì công cụ tự động không đáp ứng tất cả các tiêu chí thành công được xác định trong WCAG, nên bạn cần thiết phải chạy các bài kiểm thử khả năng tiếp cận tự động và tiếp tục kiểm thử!

Khi công nghệ phát triển, chỉ riêng các công cụ tự động có thể thực hiện nhiều quy trình kiểm thử hơn, nhưng hiện tại, bạn cần thêm cả quy trình kiểm tra thủ công và quy trình kiểm tra bằng công nghệ hỗ trợ vào các giao thức kiểm thử để bao gồm tất cả các điểm kiểm tra WCAG hiện hành.

Lợi ích của kiểm thử khả năng hỗ trợ tiếp cận theo cách thủ công:

  • Khá đơn giản và chạy nhanh
  • Phát hiện được tỷ lệ vấn đề cao hơn so với chỉ sử dụng kiểm thử tự động
  • Không cần nhiều công cụ và chuyên môn để thành công

Nhược điểm của kiểm thử khả năng hỗ trợ tiếp cận theo cách thủ công:

  • Phức tạp và tốn thời gian hơn so với kiểm thử tự động
  • Có thể khó lặp lại trên quy mô lớn
  • Đòi hỏi chuyên môn về khả năng hỗ trợ tiếp cận nhiều hơn để chạy các kiểm thử và diễn giải kết quả

So sánh những phần tử và thông tin chi tiết về khả năng tiếp cận mà một công cụ tự động có thể phát hiện, với những phần tử và thông tin chi tiết mà công cụ đó không phát hiện được.

Có thể tự động hoá Không thể tự động hoá
Độ tương phản màu của văn bản trên nền đơn sắc Độ tương phản màu của văn bản trên các hình ảnh/chuyển màu
Có văn bản thay thế cho hình ảnh Văn bản thay thế cho hình ảnh chính xác và được chỉ định đúng cách
Có tiêu đề, danh sách và điểm mốc Tiêu đề, danh sách và điểm đánh dấu được đánh dấu đúng cách và tất cả các phần tử đều được tính đến
ARIA hiện diện ARIA đang được sử dụng một cách thích hợp và áp dụng cho(các) phần tử chính xác
Xác định các phần tử có thể lấy tiêu điểm bằng bàn phím Những phần tử nào bị thiếu tiêu điểm bàn phím, thứ tự tiêu điểm có hợp lý không và chỉ báo tiêu điểm có hiển thị không
Phát hiện tiêu đề iFrame iFrame, thứ tự lấy tiêu điểm có ý nghĩa logic và chỉ báo lấy tiêu điểm xuất hiện
Có thành phần video Phần tử video có phương tiện thay thế phù hợp (chẳng hạn như phụ đề và bản chép lời)


Các loại kiểm thử thủ công

Có nhiều công cụ và kỹ thuật thủ công mà bạn cần cân nhắc khi xem xét trang web hoặc ứng dụng của mình về khả năng hỗ trợ tiếp cận kỹ thuật số. Ba lĩnh vực trọng tâm lớn nhất trong kiểm thử thủ công là chức năng bàn phím, các bài đánh giá tập trung vào hình ảnh và các bước kiểm tra nội dung chung.

Chúng ta sẽ đề cập đến từng chủ đề này ở cấp độ cao trong mô-đun này, nhưng các kiểm thử sau đây không phải là danh sách đầy đủ về tất cả các kiểm thử thủ công mà bạn có thể hoặc nên chạy. Bạn nên bắt đầu bằng danh sách kiểm tra khả năng hỗ trợ tiếp cận thủ công từ một nguồn uy tín và phát triển danh sách kiểm tra thử nghiệm thủ công tập trung của riêng bạn cho sản phẩm kỹ thuật số và nhu cầu cụ thể của nhóm.

Kiểm tra bàn phím

Ước tính có khoảng 25% tổng số vấn đề về khả năng hỗ trợ tiếp cận kỹ thuật số là do thiếu sự hỗ trợ của bàn phím. Như chúng ta đã tìm hiểu trong mô-đun tiêu điểm bàn phím, điều này ảnh hưởng đến tất cả các loại người dùng, bao gồm cả người dùng chỉ sử dụng bàn phím có thị lực bình thường, người dùng trình đọc màn hình có thị lực kém/khiếm thị và những người sử dụng phần mềm nhận dạng giọng nói sử dụng công nghệ dựa vào nội dung có thể truy cập bằng bàn phím.

Các bài kiểm tra bàn phím giúp giải đáp những câu hỏi như:

  • Trang web hoặc tính năng đó có cần chuột để hoạt động không?
  • Thứ tự nhấn phím tab có hợp lý và trực quan không?
  • Chỉ báo tiêu điểm bàn phím có luôn hiển thị không?
  • Bạn có thể bị mắc kẹt trong một phần tử không nên giữ tiêu điểm không?
  • Bạn có thể di chuyển phía sau hoặc xung quanh một phần tử cần giữ tiêu điểm không?
  • Khi đóng một phần tử đã nhận tiêu điểm, chỉ báo tiêu điểm có quay lại một vị trí hợp lý không?

Mặc dù chức năng bàn phím có tác động rất lớn, nhưng quy trình kiểm thử lại khá đơn giản. Bạn chỉ cần đặt chuột sang một bên hoặc cài đặt gói JavaScript nhỏ và kiểm thử trang web chỉ bằng bàn phím. Các lệnh sau đây là cần thiết cho việc kiểm thử bằng bàn phím.

Khoá Kết quả
Tab Di chuyển một phần tử đang hoạt động sang một phần tử khác
Shift + Tab Di chuyển ngược một phần tử đang hoạt động sang một phần tử khác
Mũi tên Chuyển đổi qua các chế độ kiểm soát liên quan
Phím cách Chuyển đổi trạng thái và di chuyển xuống cuối trang
Shift + Phím cách Di chuyển lên trang
Enter Kích hoạt các chế độ điều khiển cụ thể
Nút thoát Loại bỏ các đối tượng hiển thị động

Kiểm tra bằng hình ảnh

Kiểm tra bằng mắt tập trung vào các phần tử trực quan của trang và sử dụng các công cụ như phóng to màn hình hoặc thu phóng trình duyệt để xem xét khả năng tiếp cận của trang web hoặc ứng dụng.

Việc kiểm tra bằng mắt có thể cho bạn biết:

  • Có vấn đề nào về độ tương phản màu mà công cụ tự động không phát hiện được, chẳng hạn như văn bản nằm trên nền có hiệu ứng chuyển màu hoặc hình ảnh không?
  • Có những phần tử trông giống như tiêu đề, danh sách và các phần tử cấu trúc khác nhưng không được mã hoá như vậy không?
  • Các đường liên kết điều hướng và thông tin đầu vào của biểu mẫu có tính nhất quán trên toàn bộ trang web hoặc ứng dụng không?
  • Có hiệu ứng nhấp nháy, nhấp nháy nhanh hoặc ảnh động nào vượt quá các đề xuất không?
  • Nội dung có khoảng cách phù hợp không? Đối với chữ cái, từ, dòng và đoạn văn?
  • Bạn có thể xem tất cả nội dung bằng trình phóng to màn hình hoặc tính năng thu phóng của trình duyệt không?

Kiểm tra nội dung

Không giống như các kiểm thử trực quan tập trung vào bố cục, chuyển động và màu sắc, các kiểm thử nội dung tập trung vào các từ trên trang. Bạn không chỉ xem xét bản sao mà còn phải xem xét bối cảnh để đảm bảo bản sao đó có ý nghĩa đối với người khác.

Các bước kiểm tra nội dung giúp trả lời những câu hỏi như:

  • Tiêu đề trang, tiêu đề và nhãn biểu mẫu có rõ ràng và mang tính mô tả không?
  • Nội dung thay thế cho hình ảnh có ngắn gọn, chính xác và hữu ích không?
  • Màu sắc có phải là cách duy nhất để truyền đạt ý nghĩa hoặc thông tin không?
  • Đường liên kết có mang tính mô tả hay bạn sử dụng văn bản chung chung như "đọc thêm" hoặc "nhấp vào đây"?
  • Có thay đổi nào về ngôn ngữ trong một trang không?
  • Ngôn ngữ đơn giản có được sử dụng và tất cả các từ viết tắt có được viết đầy đủ khi được đề cập lần đầu tiên không?

Một số quy trình kiểm tra nội dung có thể được tự động hoá một phần. Ví dụ: bạn có thể viết một trình kiểm tra JavaScript để kiểm tra xem có cụm từ "Nhấp vào đây" hay không và đề xuất bạn thực hiện thay đổi. Tuy nhiên, những giải pháp tuỳ chỉnh này thường vẫn cần con người thay đổi bản sao thành một nội dung phù hợp với bối cảnh.

Bản minh hoạ: Kiểm thử thủ công

Cho đến nay, chúng tôi đã chạy các thử nghiệm tự động trên trang web minh hoạ của mình, đồng thời tìm thấy và khắc phục 8 loại vấn đề khác nhau. Bây giờ, chúng ta đã sẵn sàng chạy quy trình kiểm tra thủ công để xem liệu có thể phát hiện thêm các vấn đề về khả năng hỗ trợ tiếp cận hay không.

Bước 1

Bản minh hoạ CodePen mới cập nhật của chúng tôi đã áp dụng tất cả các bản cập nhật tự động về khả năng tiếp cận.

Xem trong chế độ gỡ lỗi để tiếp tục với các kiểm thử tiếp theo. Điều này rất quan trọng vì nó sẽ xoá <iframe> bao quanh trang web minh hoạ. <iframe> này có thể gây trở ngại cho một số công cụ kiểm thử. Tìm hiểu thêm về chế độ gỡ lỗi của CodePen.

Bước 2

Bắt đầu quy trình kiểm thử thủ công bằng cách đặt chuột hoặc bàn di chuột sang một bên và chỉ dùng bàn phím để di chuyển lên và xuống DOM.

Vấn đề 1: Chỉ báo tiêu điểm có thể nhìn thấy

Bạn sẽ thấy ngay vấn đề đầu tiên về bàn phím (hoặc đúng hơn là bạn sẽ không thấy vấn đề này) vì chỉ báo tiêu điểm có thể nhìn thấy đã bị xoá. Khi quét CSS trong bản minh hoạ, bạn sẽ thấy "outline: none" đáng sợ được thêm vào cơ sở mã.

  :focus {
    outline: none;
  }
Hãy khắc phục vấn đề này.

Như bạn đã tìm hiểu trong mô-đun Tiêu điểm bàn phím, bạn cần xoá dòng mã này để cho phép trình duyệt web thêm tiêu điểm hiển thị cho người dùng. Bạn có thể tiến thêm một bước nữa và tạo chỉ báo tiêu điểm được tạo kiểu để đáp ứng tính thẩm mỹ của sản phẩm kỹ thuật số.

:focus {
  outline: 3px dotted #008576;
}

Vấn đề 2: Thứ tự tiêu điểm

Sau khi bạn sửa đổi chỉ báo tiêu điểm và chỉ báo này xuất hiện, hãy nhớ nhấn phím tab để di chuyển qua trang. Khi làm như vậy, bạn sẽ nhận thấy rằng trường nhập dữ liệu biểu mẫu dùng để đăng ký nhận bản tin không nhận được tiêu điểm. Thẻ này đã bị xoá khỏi thứ tự tiêu điểm tự nhiên bằng một chỉ mục thẻ âm.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" tabindex="-1" required>
Hãy khắc phục vấn đề này.

Vì chúng tôi muốn mọi người sử dụng trường này để đăng ký nhận bản tin, nên tất cả những gì chúng tôi cần làm là xoá tabindex âm hoặc đặt tabindex thành 0 để cho phép đầu vào trở thành tiêu điểm bàn phím một lần nữa.

<input type="email" placeholder="Enter your e-mail address" aria-hidden="true" required>

Bước 3

Sau khi kiểm tra tiêu điểm bàn phím, chúng ta sẽ chuyển sang kiểm tra hình ảnh và nội dung.

Khi thực hiện các bài kiểm thử bàn phím bằng cách nhấn phím Tab lên và xuống trên trang minh hoạ, có thể bạn nhận thấy bàn phím tập trung vào 3 đường liên kết bị ẩn về mặt thị giác trong các đoạn văn về các bệnh lý khác nhau.

Để trang của chúng ta có khả năng tiếp cận, các đường liên kết phải nổi bật so với văn bản xung quanh và có sự thay đổi về kiểu không phải màu khi di chuột và tiêu điểm bàn phím.

Hãy khắc phục vấn đề này.

Một giải pháp nhanh chóng là thêm dấu gạch chân vào các đường liên kết bên trong đoạn văn để làm nổi bật các đường liên kết đó. Cách này sẽ giải quyết được vấn đề về khả năng hỗ trợ tiếp cận, nhưng có thể không phù hợp với tính thẩm mỹ tổng thể mà bạn muốn đạt được.

Nếu chọn không thêm đường gạch chân, bạn sẽ cần sửa đổi màu sắc sao cho đáp ứng các yêu cầu đối với cả nền và bản sao.

Khi xem bản minh hoạ bằng công cụ kiểm tra độ tương phản của đường liên kết, bạn sẽ thấy rằng màu của đường liên kết đáp ứng yêu cầu về độ tương phản màu là 4,5:1 giữa văn bản có kích thước thông thường và nền. Tuy nhiên, các đường liên kết không được gạch chân cũng phải đáp ứng yêu cầu về độ tương phản màu là 3:1 so với văn bản xung quanh.

Một lựa chọn là thay đổi màu của đường liên kết cho phù hợp với các phần tử khác trên trang. Nhưng nếu bạn thay đổi màu của đường liên kết thành màu xanh lục, thì nội dung cũng phải được sửa đổi để đáp ứng các yêu cầu chung về độ tương phản màu giữa cả 3 phần tử: đường liên kết, nền và văn bản xung quanh.

Ảnh chụp màn hình WebAIM cho văn bản liên kết cho thấy đường liên kết đến văn bản nội dung không đáp ứng cấp độ A của WCAG.
Khi đường liên kết và nội dung giống nhau, thử nghiệm sẽ không thành công.
Ảnh chụp màn hình của WebAIM cho thấy tất cả các bài kiểm thử đều đạt khi màu của đường liên kết là màu xanh lục.
Khi đường liên kết và văn bản nội dung khác nhau, quy trình kiểm thử sẽ thành công.

Vấn đề 4: Độ tương phản màu của biểu tượng

Một vấn đề khác về độ tương phản màu bị bỏ lỡ là biểu tượng mạng xã hội. Trong mô-đun màu sắc và độ tương phản, bạn đã biết rằng các biểu tượng thiết yếu cần đáp ứng độ tương phản màu là 3:1 so với nền. Tuy nhiên, trong bản minh hoạ, các biểu tượng mạng xã hội có tỷ lệ tương phản là 1,3:1.

Hãy khắc phục vấn đề này.

Để đáp ứng yêu cầu về tỷ lệ tương phản màu là 3:1, các biểu tượng mạng xã hội sẽ được đổi thành màu xám đậm hơn.

Ảnh chụp màn hình bản minh hoạ với trình phân tích màu cho thấy độ tương phản màu biểu tượng không thành công.

Vấn đề 5: Bố cục nội dung

Nếu bạn xem bố cục của nội dung đoạn văn, bạn sẽ thấy văn bản được căn đều hoàn toàn. Như bạn đã tìm hiểu trong mô-đun Kiểu chữ, điều này tạo ra "dòng trống", có thể khiến một số người dùng khó đọc văn bản.

p.bullet {
   text-align: justify;
}
Hãy khắc phục vấn đề này.

Để đặt lại chế độ căn chỉnh văn bản trong bản minh hoạ, bạn có thể cập nhật mã thành text-align: left; hoặc xoá hoàn toàn dòng đó khỏi CSS, vì trái là chế độ căn chỉnh mặc định cho trình duyệt. Hãy nhớ kiểm thử mã trong trường hợp các kiểu kế thừa khác xoá chế độ căn chỉnh văn bản mặc định.

p.bullet {
   text-align: left;
}

Bước 4

Ảnh chụp màn hình trang web minh hoạ của Medical Mysteries Club.
Tất cả vấn đề thủ công hiện đã được giải quyết trong bản minh hoạ, như trong hình này.

Sau khi bạn xác định và khắc phục tất cả các vấn đề về khả năng tiếp cận theo cách thủ công được nêu trong các bước trước, trang của bạn sẽ trông tương tự như ảnh chụp màn hình của chúng tôi.

Có thể bạn sẽ phát hiện thêm các vấn đề về khả năng hỗ trợ tiếp cận trong quá trình kiểm tra thủ công so với những vấn đề chúng tôi đề cập trong mô-đun này. Chúng ta sẽ tìm hiểu nhiều vấn đề trong số này ở mô-đun tiếp theo.

Bước tiếp theo

Bạn làm tốt lắm! Bạn đã hoàn thành các mô-đun kiểm thử tự động và kiểm thử thủ công. Bạn có thể xem CodePen mới cập nhật của chúng tôi. CodePen này đã áp dụng tất cả các bản sửa lỗi về khả năng tiếp cận theo cách thủ công và tự động.

Bây giờ, hãy chuyển sang mô-đun kiểm thử cuối cùng tập trung vào kiểm thử công nghệ hỗ trợ.