Một trang có thể rất chỉn chu mà vẫn khiến người đọc mất vài nhịp mới biết nên nhìn vào đâu. Tên gói, badge trạng thái, con số lớn, cảnh báo và hai nút cùng “la” ở một âm lượng; trên desktop còn tạm ổn, tới mobile thì phần hỗ trợ lại nhảy lên trước việc cần xử lý. Tăng cỡ chữ cho tiêu đề chỉ giải quyết phần nhìn thấy, chưa chắc sửa được câu chuyện mà DOM và công nghệ hỗ trợ đang đọc.
Bài này dựng một fixture trang chi tiết gói dịch vụ với bốn câu hỏi cố định: đây là gì, trạng thái nào quan trọng, hành động chính là gì và chi tiết hỗ trợ nằm ở đâu. Cùng một nội dung được chạy qua bốn biến thể: before, chỉ sửa hình thức, chỉ sửa semantic và after. Kết quả là một heuristic probe n=1 trên Windows x64, Node.js 24.19.0 và Edge 154.0.4258.53; đây không phải nghiên cứu người dùng, eye-tracking hay bằng chứng tăng conversion.
Mục lục [Hiển thị]
- Trước khi sửa, trang muốn người đọc biết gì trước?
- Vẽ content outline trước visual hierarchy
- Những tín hiệu nào đang tranh cùng một cấp?
- Nhóm nội dung bằng khoảng cách trước khi thêm khung
- Visual order và DOM order phải kể cùng một câu chuyện
- Chỉ sửa một nửa thì điều gì còn hỏng?
- Đo “dễ quét” mà không bịa usability research
- Khi nào hierarchy tốt mà trang vẫn khó dùng?
Trước khi sửa, trang muốn người đọc biết gì trước?
Visual hierarchy không bắt đầu bằng việc chọn font 48 px hay thêm shadow. Nó bắt đầu bằng thứ tự câu hỏi. Với fixture này, câu trả lời cần xuất hiện theo logic: “Gói vận hành Studio” cho biết đối tượng, “Gia hạn ngay” là hành động chính, “Cần gia hạn trước 16:00” giải thích tính cấp bách, rồi mới tới lịch sao lưu và vị trí lưu.
Bản before cố ý làm ngược hai việc. Mọi tiêu đề gần như cùng cỡ và cùng độ đậm, còn khối “Chi tiết hỗ trợ” đứng trước nội dung chính trong DOM. CSS kéo khối đó sang cột phải trên desktop nên mắt thường dễ bỏ qua lỗi. Ở 390 CSS px, layout xếp một cột và chi tiết phụ xuất hiện đầu tiên; thứ tự tab cũng bắt đầu bằng “Liên hệ hỗ trợ” thay vì tác vụ gia hạn.
Ảnh trên dùng cùng copy và cùng số component ở hai phía. Bản after không thêm card cho có vẻ “xịn” hơn: nó giảm số tín hiệu cạnh tranh, tách cấp title/status/action/detail và sửa thứ tự trong source. Đây là điểm quan trọng vì W3C Page Structure Tutorial giải thích rằng cấu trúc tốt giúp người dùng định hướng, tìm phần cần thiết và điều hướng bằng heading hoặc landmark hiệu quả hơn.
Vẽ content outline trước visual hierarchy
Outline văn bản của fixture chỉ cần bốn dòng:
- H1: Gói vận hành Studio.
- H2: Tình trạng cần xử lý.
- H2: Chỉ số trong tháng.
- H2: Chi tiết hỗ trợ.
Outline này giúp tách nội dung khỏi style. Tiêu đề không cần đổi từ h2 sang h4 chỉ vì designer muốn chữ nhỏ hơn; CSS xử lý kích thước, HTML giữ quan hệ. Ngược lại, một div đậm 32 px vẫn chỉ là div nếu không có semantic phù hợp.
Understanding SC 1.3.1 nói rõ mục tiêu là để thông tin, cấu trúc và quan hệ được xác định bằng chương trình hoặc có sẵn dưới dạng văn bản. Tài liệu Understanding là phần giải thích có tính thông tin, không phải một success criterion mới. Nó cũng không có nghĩa mọi trang bắt buộc phải bắt đầu bằng H1; W3C Easy Checks gọi H1 đầu trang và việc không bỏ cấp là gợi ý mạnh, không phải yêu cầu tuyệt đối.
Những tín hiệu nào đang tranh cùng một cấp?
Trong bản before, eyebrow, title, section heading, badge, nút chính và nút phụ đều gần nhau về weight, contrast và khoảng trắng. Người đọc vẫn đọc được từng chữ, nhưng trang không đưa ra một đường ưu tiên ổn định. Một badge phụ có nền đậm hơn title hoặc nút “Xem lịch sử” nặng ngang “Gia hạn ngay” đều làm mục tiêu chính mờ đi.
Khi audit, nên nhìn từng cặp tín hiệu thay vì tranh luận chung chung rằng “trang hơi rối”:
| Cặp cần so | Probe | Kết luận dùng được |
|---|---|---|
| Title và badge | Cỡ chữ, weight, contrast, vị trí | Title phải nhận diện trang trước; badge chỉ bổ sung trạng thái |
| CTA chính và phụ | Màu nền, viền, thứ tự tab, nhãn | Hành động chính nổi hơn nhưng cả hai vẫn đọc được |
| Cảnh báo và đối tượng | Khoảng cách, source order, văn bản | Cảnh báo nằm gần phần nó giải thích, không dựa vào màu đỏ |
| Nội dung chính và hỗ trợ | Landmark, DOM, responsive order | Chi tiết phụ không chen lên trước mục tiêu chính khi reflow |
Fixture after dùng chữ, vị trí và khoảng trắng để giữ nghĩa ngay cả khi bỏ màu. Badge có chấm san hô nhưng vẫn ghi đầy đủ “Cần gia hạn trước 16:00”; cảnh báo có nhãn “Cảnh báo”, không giao toàn bộ ý nghĩa cho border đỏ. Vì thế chế độ forced colors vẫn còn văn bản và đường biên để phân biệt thành phần.
Nhóm nội dung bằng khoảng cách trước khi thêm khung
Border, nền và shadow là công cụ cuối, không phải bước đầu. Ở bản after, title và mô tả được gom thành một cụm; hai CTA thành một cụm; heading trạng thái, badge và cảnh báo thành cụm thứ ba. Khoảng cách giữa ba cụm lớn hơn khoảng cách bên trong mỗi cụm, nên quan hệ vẫn hiểu được khi chuyển sang grayscale.
Card chỉ được giữ ở ranh giới giữa nội dung chính và chi tiết hỗ trợ. Nếu mỗi metric, đoạn mô tả và badge đều nằm trong một card có shadow như nhau, container lại biến thành tiếng ồn. Chỗ này thường bị hiểu nhầm: “thêm khung cho rõ nhóm” có thể làm tất cả nhóm cùng nổi, cuối cùng chẳng nhóm nào thật sự quan trọng.
Nếu typography thay đổi sau khi font web tải xong, đường quét cũng có thể lệch dù hierarchy ban đầu đúng. Bài font fallback tiếng Việt với size-adjust đi sâu vào phần metric và layout shift này.
Visual order và DOM order phải kể cùng một câu chuyện
Understanding SC 1.3.2 không yêu cầu mọi khối trên trang chỉ có đúng một thứ tự. Yêu cầu xuất hiện khi thay đổi sequence làm thay đổi ý nghĩa; khi đó phải có ít nhất một reading order đúng có thể xác định bằng chương trình. Hai bài độc lập có thể đổi chỗ, nhưng đặt chi tiết phụ lên trước cảnh báo và hành động đang cần xử lý thì dễ làm câu chuyện chệch đi.
Bản before dùng CSS để đặt aside ở cột phải nhưng source lại đứng trước main. Đây là lỗi khó thấy ở desktop và lộ rõ khi tắt CSS hoặc reflow về một cột. Bản after đặt main trước aside, giữ title → action → status → details trong DOM, CSS-off và mobile. Không cần dùng order để “vá” một source order sai.
Accessibility tree của Edge nhận một landmark main tên “Gói vận hành Studio”, một complementary tên “Chi tiết hỗ trợ”, một H1 và ba H2. Thứ tự tab bắt đầu “Gia hạn ngay” → “Xem lịch sử” → “Liên hệ hỗ trợ”. Đây là kiểm tra bằng browser accessibility tree và keyboard order, chưa phải phiên test thực tế với NVDA hoặc Narrator.
Chỉ sửa một nửa thì điều gì còn hỏng?
Hai negative control giữ cùng dữ liệu để tránh đánh tráo biến. “Chỉ sửa hình thức” dùng title lớn, CTA xanh và khoảng trắng rõ nhưng vẫn không có heading lập trình được; aside vẫn đứng trước main trong DOM. Người nhìn thấy có thể quét nhanh hơn, còn danh sách heading của công nghệ hỗ trợ vẫn trống.
“Chỉ sửa semantic” có H1/H2 và landmark đúng, nhưng mọi phần gần như cùng cỡ, cùng màu và cùng khoảng cách. Người dùng heading navigation có cấu trúc tốt hơn, còn người đọc bằng mắt vẫn phải tự đoán điểm bắt đầu. Understanding SC 2.4.6 cũng tách khá rõ hai chuyện: heading/label phải mô tả đúng chủ đề hoặc mục đích; việc chúng có được đánh dấu đúng bằng code hay không thuộc phạm vi liên quan của SC 1.3.1.
Vì vậy visual hierarchy và semantic outline không thay thế nhau. Một bên tạo đường quét, bên còn lại giúp quan hệ tồn tại khi presentation đổi. Trang chỉ ổn khi cả hai mô tả cùng một thứ tự ưu tiên.
Đo “dễ quét” mà không bịa usability research
Probe tự động chạy 15 assertion trên bốn biến thể. Nó kiểm số heading, cấp heading, landmark, thứ tự DOM trên desktop/mobile, focus order, contrast của bốn mục tiêu, overflow ở 390 CSS px, proxy reflow 200% và 400%, text-spacing override, CSS-off order và forced colors. Bản after đạt 15/15; hai negative control thất bại đúng chỗ được thiết kế để thất bại.
Con số 15/15 chỉ chứng minh fixture đáp ứng bộ assertion đó. Nó không nói người thật sẽ tìm thông tin nhanh hơn bao nhiêu giây, không chứng minh conversion tăng và cũng không đại diện cho mọi dashboard. Nếu cần usability evidence, hãy đưa cùng bốn câu hỏi cho nhiều người thuộc đúng nhóm sử dụng, ghi first target, đường đi, số lần quay lại và thời gian quan sát theo một protocol cố định.
Trong một audit nhỏ, log trung thực có thể đơn giản như sau: “before có 0 heading, mobile DOM bắt đầu bằng details; visual-only vẫn 0 heading; semantic-only có một H1 và ba H2 nhưng presentation phẳng; after có outline hợp lệ, DOM/CSS-off cùng thứ tự và không tràn ở 320 CSS px”. Không cần gắn phần trăm marketing vào một phép đo chưa chạy.
Khi nào hierarchy tốt mà trang vẫn khó dùng?
Hierarchy chỉ trả lời “đâu là trước, đâu là sau”. Copy mơ hồ, contrast yếu, bảng quá rộng, layout shift, trạng thái loading hoặc focus bị che vẫn có thể làm trang khó dùng. Nếu vấn đề nằm ở phục hồi lỗi, bài form báo lỗi với error summary và giữ dữ liệu xử lý đúng luồng đó. Nếu đường tab đã đúng nhưng vòng focus khó nhìn, xem cách đo focus indicator theo WCAG 2.2.
Cách làm gọn nhất là viết outline nội dung trước, ánh xạ nó sang heading và landmark, rồi mới dùng size, weight, contrast, spacing và container để lộ thứ tự ấy ra màn hình. Sau đó tắt CSS, thu viewport, bật forced colors và đi bằng bàn phím. Nếu bốn chế độ vẫn kể cùng một câu chuyện, hierarchy không chỉ đẹp trong mockup mà đã bắt đầu đứng vững trong sản phẩm thật.
