7 Hướng đi đáng giá cho mọi Lập trình viên web trong năm 2024

Bắt đầu 1 năm mới thường là lúc nhìn lại bản thân và đặt mục tiêu mới, và nếu bạn đang build các ứng dụng web trong hay ngoài công việc, thì mình có 7 đề mục tiêu mà bạn có thể xem xét.

Những mục tiêu dễ đạt thành tựu này sẽ giúp bạn vào guồng tiếp cận tới việc phát triển web, đặt những xem xét cốt lõi về khả năng tiếp cận của nó.

7 “đầu mục” phấn đấu cho bạn sẽ nêu trong bài này:

Nâng cấp lint của bạn bằng một plugin a11y
Chọn một extension (tiện ích mở rộng) để thường xuyên kiểm tra code của bạn trên trình duyệt
“Làm bạn” với trình đọc màn hình của bạn và học thêm ít nhất 3 kỹ năng
Tạm ngưng dùng chuột/ trackpad một thời gian
Kiểm tra các heading của bạn
Làm quen với các thách thức do Single Page Applications đưa ra
Thay đổi định nghĩa của bạn về việc “đã hoàn thành”

1. Tích hợp A11y-Linting vào dự án của bạn

Nếu bạn đang làm việc về front-end, có thể bạn đã sử dụng ESLint trong dự án của mình rồi. Đây là công cụ tuyệt vời để đảm bảo các error thông thường được phát hiện sớm nhất có thể, và trước khi chúng được đưa ra vận hành.

Các plugin bổ sung có thể tìm quét lỗi (lint) cho các vấn đề truy cập, và 1 trong những công cụ tốt là elsint-plugin-jsx-a11y. Điều này sẽ kiểm tra các vấn đề truy cập mà có thể được phát hiện bởi 1 linter, ví dụ:

Đảm bảo form input có những nhãn (label) và ID thích hợp
Thuộc tính ‘alt’ thích hợp cho các hình ảnh, bao gồm kiểm tra các vấn đề chất lượng chung trong văn bản ‘alt’ (như sử dụng dư thừa các từ như “Hình ảnh của …”)
Việc sử dụng tabIndex không phù hợp

Dùng plugin ‘jsx-ally’ giúp bạn giới thiệu 1 trang net an toàn, nắm bắt các vấn đề code trước cả khi nhìn vào trình duyệt. Cùng với các nguyên tắc ESLint khác, bạn còn có thể cài đặt thất bại CI pipeline của mình nếu các vấn đề không chỉ ra được. Và nó giúp mình tiết kiệm thời gian tìm kiếm những loại error trong phần review code.

2. Chọn extension (tiện ích mở rộng) để kiểm tra Code của bạn trong trình duyệt

Rất nhiều vấn đề truy cập có thể được tìm ra bởi các tiện ích mở rộng trình duyệt, và nó không chỉ highlight vấn đề rõ ràng trên trang, chúng còn đề xuất hướng giải quyết cho bạn. Những công cụ này khá tuyệt cho các vấn đề truy cập như:

Đảm bảo đủ độ tương phản màu
Đảm bảo tất cả hình ảnh đều có thuộc tính ‘alt’
Xác minh các heading và các semantic HTML đã được sử dụng phù hợp

Các công cụ phổ biến nhất là Axe và WAVE. Cả 2 đều trên cả tuyệt vời – hãy thử cả 2 và xem bạn hợp cái nào hơn
Sử dụng chúng trước khi đưa bất kỳ code nào cho review. Và từ đó các thao tác kiểm tra truy cập sẽ trở thành một phần không thể thiếu trong quy trình làm việc của bạn.

3. Làm bạn với Screen Reader của mình

Hãy thoải mái với cách screen reader của bạn làm việc. Và cách người dùng thường lướt web với nó là điều cần thiết để xem xét khả năng truy cập đúng cách trong phương pháp lập trình chung của bạn.

Screen Reader nào thì phù hợp?

Dựa trên Khảo sát Người dùng Screen Reader của WebAIM, các option miễn phí này sẽ hoạt động khá ổn:

Người dùng Mac có thể đơn giản dùng built-in VoiceOver (chuyển Bật và Tắt với ‘cmd’ + ‘F5’)
Người dùng Windows có thể tải về và dùng NVDA

Các điều căn bản cần học

Như là điểm bắt đầu cơ bản nhất, hãy học những thứ sau đây với screen reader bạn chọn:

Đọc và lướt qua một trang nội dung – điều này sẽ giúp bạn kiểm tra các phần của trang và cách chúng được thông báo đến người dùng screen reader
Quét qua các heading – đây là điều cần thiết do phần lớn người dùng screen reader sẽ “quét” nội dung của bạn theo cách này trước khi vào một phần nhất định
Tab vào các mục tương tác – đây là phần điều hướng bàn phím tiêu chuẩn, nhưng hãy thoải mái thực hiện việc này với trình đọc màn hình được bật và tương tác với các mục đó khi bạn làm như vậy (ví dụ: nhấp vào nút và liên kết)

Hãy thoải mái hơn khi dùng screen reader của bạn. Và kiểm tra code thường xuyên với nó giúp bạn tự nhiên xem xét “Cách nó sẽ hoạt động với screen reader?” khi chọn 1 phần của công việc.

4. Tạm ngưng dùng chuột/ trackpad một thời gian

Tương tự như Bước 3, hãy thoải mái với cách người dùng điều hướng web với bàn phím. Vài điều quan trọng cần biết:

Bạn cần đảm bảo sao cho usersẽ có thể di chuyển qua tất cả các mục tương tác trên trang (nút, liên kết, form input, v..v..) bằng việc chỉ sử dụng nút ‘tab’
Mục hiện đang được hiển thị chính phải có chỉ báo trực quan rõ ràng (ví dụ: viền màu xanh)
Các mục không tương tác sẽ không bao giờ nhận được thông báo định hướng bằng phím tab
Thứ tự hiển thị khi tab trên trang nên hợp lý. Thông thường, điều này có nghĩa là nó tuân theo thứ tự bạn mong đợi như một người dùng được quan sát (ví dụ: từ trên xuống dưới) và không nhảy ngẫu nhiên

Kiểm tra đều đặn công việc của bạn bằng cách chỉ dùng điều hướng bàn phím sẽ giúp đánh dấu các vấn đề truy cập như là:

Các phần tử HTML được khai báo theo thứ tự hợp lý (khiến thứ tự tab không nhảy theo tiến trình bạn muốn)
Những mục tương tác không nhận được focus (ví dụ: một thành phần tùy chỉnh như Thẻ mà người dùng sẽ có thể nhấp vào)
Đa trạng thái focus mặc định bị xóa vì lý do thương hiệu / thiết kế, nhưng không bao giờ bị thay thế’

5. Kiểm tra các cấp heading

Như đã nêu trong Bước 3, các người dùng screen reader sử dụng các cấp heading để có thể quét và đọc lướt nội dung của bạn. Theo cách rất giống với cách người dùng quan sát. Việc kiểm tra nhanh các cấp heading của bạn có thể tạo ra sự khác biệt lớn và giúp hiển thị nội dung hữu ích cho nhiều người dùng hơn.

Một số quy tắc nhỏ:

Mỗi trang nên có một yếu tố ‘h1’ mô tả rõ ràng mục đích của trang
Các cấp heading sau đó chỉ nên tăng từng cái một, ví dụ: h2 → h3, đừng nhảy vọt

6. Thấy được những vấn đề có thể phát sinh trên Single Page Applications (Ứng dụng trang đơn)

Bản thân nó đã là 1 chủ đề lớn. Nhưng nếu bạn làm việc với framework tối ưu hoá render về client-side như React hoặc Vue. Việc làm quen với những cạm bẫy tiềm tàng này sẽ mang lại lợi ích rất lớn cho khả năng truy cập các ứng dụng web của bạn.

Những cạm bẫy tiềm năng và nguồn tài nguyên cho nó

Thay đổi route:

Khi route thay đổi trong ứng dụng do khách hàng render. Thường người dùng screen reader không biết nội dung trang đã thay đổi và có thể đã “mất”
Nếu người dùng nhấp vào một liên kết dẫn đến thay đổi route do khách hàng render. Thì thường phần focus sẽ được để lại trên liên kết dù không còn hiển thị nữa. Vốn nó có thể gây khó hiểu!

Tiêu đề trang:

Trong Single Page Application, tựa đề trang không bao giờ thay đổi trừ khi nó được quản lý rõ ràng. Điều này không giúp ích cho lắm với người dùng screen reader. Người có thể mở vài tab hay cửa sổ và muốn biết họ đang ở trang nào.

7. Thay đổi định nghĩa về việc “Hoàn thành”

Bước cuối này có lẽ là bước quan trọng nhất – trước khi bạn review code trước khi ra lò:

Đăng ký bằng ESLint của bạn, được định cấu hình để kiểm tra a11y và sửa bất kỳ lỗi nào
Chạy project thông qua một trong những công cụ xác minh trong trình duyệt được đề cập ở trên. Và xem có bất kỳ vấn đề nào cần khắc phục không?
Bật trình screen reader của bạn và cung cấp cho nó một cách nhanh chóng. Bao gồm quét theo cấp heading
Tab thông qua nội dung bạn vừa tạo – liệu nó có hoạt động như mong đợi?
Nếu công việc của bạn là để kích hoạt thay đổi route trong Single Page Application. Hãy kiểm tra kỹ xem các thay đổi route đã được xử lý với khả năng truy cập chưa

Nếu bạn hoàn thành các bước này thường xuyên nhất có thể trong công việc của mình. Bạn sẽ đi đúng hướng để tạo các ứng dụng web có thể truy cập vào năm 2024!