[譯] 你認為“figure”怎麼用?

HydeSong發表於2019-04-28

作為 HTML5 新引入的元素,figurefigcaption 元素是為了建立有意義的標記結構:

  • 為一段內容提供一個描述性標籤,
  • 該標籤與當前檔案相關,但使用者對它的理解並不重要。

為了得到更具體的資訊,讓我們分別來了解一下這些元素。

figure 元素

通常 figure 元素被認為用來包裹圖或圖表,它還可以承載文件主要內容中引用的但不是冗餘資訊的任何內容(程式碼片段、引用、音訊、視訊等)。在文件流中可以把 figure 完全刪除,而不會影響使用者對主要內容的理解。

例如,描述 unladen Swallow 空速的文件,可能有一節描述南非燕子和歐洲燕子之間的差異。伴隨文字內容的可能是一個 figure 標籤,並排展示了這兩種鳥類的差異,以補充文件中描述的資訊。

一篇文章的截圖,使用與主要內容錯開的影象來表示南非燕子和歐洲燕子之間的視覺差異。圖片的文字說明左邊是南非燕子,右邊是歐洲燕子。

在這個基本的例子中,figurefigcaption 起到了引用前文內容的作用。如果去掉它們,目前為止所有的文字資訊依然起到了 figure 的作用。

圖片源(2003)

使用 figure 時可以加上或不加 figcaption 標籤。但是,不加 figcaption 標籤,或者不提供其他可訪問的屬性(比如 aria-label),單獨使用 figure 在表達其語義上價值不大。在某些情況下,如果沒有給定可訪問的屬性,可能表達不出任何語義。

figcaption 元素

figcaptionfigure 所含的內容提供標題或摘要。如果在 figure 上不使用 aria-labelaria-labelledby 屬性,figcaption 會成為 figure 元素的可訪問屬性。

figcaption 可以放在 figure 的主要內容之前或之後,但是它必須是 figure 元素的直接子元素。

推薦的用法:

<figure>
  <figcaption>...</figcaption>
  <!-- figure 的內容 -->
</figure>

<figure>
  <!-- figure 的內容 -->
  <figcaption>...</figcaption>
</figure>

<figure>
  <figcaption>
    <div>
      ...
    </div>
  </figcaption>
  <!-- figure 的內容 -->
</figure>
複製程式碼

不推薦的用法:

<figure>
  <div>
    <figcaption>...</figcaption>
  </div>
  <!-- figure 的內容 -->
</figure>

<figure>
  <!-- figure 的內容 -->
  <div>
    <figcaption>...</figcaption>
  </div>
</figure>
複製程式碼

figcaption 可能包含 流式內容,它將 body 元素的大多數子元素進行分類。但是,由於 figcaption 元素的作用是為 figure 的內容提供標題,所以通常更傾向於使用簡潔的描述性文字。figcaption 不應該重複 figure 的內容,或者重複主文件中的其他內容。

figcaption 不能代替 alt 文字

對於 figure 中使用的影象,使用 figcaption 時最大的誤解之一是它用於替代影象 alt 文字。HTML 5.2 中規定,這種做法是隻有當作者沒有為圖片提供適當的 alt 文字時,力求傳遞有意義資訊的最後的“殺手鐗”。

一段來自 HTML 5.2 的說明:

這種情況應保持在絕對最低限度。如果作者有能力提供真正的替代文字,那麼省略 alt 屬性是不可接受的。

figcaption 是用來為 figure 提供標題和摘要的,將其與包含 figure 的文件關聯起來,或者傳遞附加的資訊,這些資訊可能在檢視 figure 本身時並不明顯。

如果給一張圖片一個空的 alt,那麼 figcaption 實際上什麼也沒有描述。這說不通,對吧?

換句話說,讓我們看看一個包含 Sass 程式碼片段的 figure

<figure>
  <pre><code>
    $align-list: center, left, right;

    @each $align in $align-list {
      .txt-#{$align} {
        text-align: $align;
      }
    }
  </code></pre>
  <figcaption>
    使用 Sass 的 @each 迴圈控制指令編譯成
    三個 CSS class;.txt-center,.txt-left,和 .txt-right。
  </figcaption>
</figure>
複製程式碼

figurealt 為空的影象相比,這就像在程式碼段中放入 aria-hidden="true"。這樣做將使螢幕閱讀器和其他輔助技術無法解析標題引用的內容。然而,不幸的是,這反映了 figure 中圖片通常發生的情況。

你可能會認為,“很明顯,標題的作用應該跟圖片的 alt 文字一樣,不是嗎?”。這個假設有兩個問題:

首先,什麼是圖片?當圖片的 alt 為空時,螢幕閱讀器不會顯示出這張圖片,也不會被發現。如果圖片中沒有 alt 鍵,某些螢幕閱讀器會顯示影象的檔名,但不是所有的螢幕閱讀器都會這樣(比如 JAWS,有調整這些行為的設定。但預設忽略這些影象)。

其次alt 屬性傳達圖片呈現的重要資訊。figcaption 應該提供上下文,以便將 figure(圖片)與主文件關聯起來,或者顯示需要注意的特定資訊。如果 figcaption 代替了 alt,那麼這就為無視力障礙的使用者建立了重複的資訊。

誤用 figcaption 代替影象 alt 還有其他問題。但要發現這些問題,我們需要了解螢幕閱讀器如何解析 figure

figure 元素和螢幕閱讀器

既然我們已經知道了應該如何使用 figure 及其標題,那麼這些元素在螢幕閱讀器上是如何表現的呢?

理想情況下,figure 應該宣告 role 屬性和 figcaption 的內容作為可訪問屬性。然後,使用者應該能夠找到 figure ,並獨立地與 figurefigcaption 的內容進行互動。對於不完全支援 figure 的瀏覽器,像 Internet Explorer 11, ARIA 的 role="figure" 屬性aria-label 屬性可用於幫助提高某些螢幕閱讀器識別標籤的可能性。

以下是測試過的螢幕閱讀器在預設設定下如何在不同的瀏覽器中顯示(或不顯示)這些資訊的摘要:

JAWS 18 的 2018 和 2019 版本

JAWS 對原生 figure 和 標題有最好的支援,儘管根據瀏覽器和 JAWS 的詳細設定,支援並不完美和一致。

IE11 需要使用 role="figure"aria-labelaria-labelledby 指向 figcaption 來模擬原生元素的屬性。IE11 不支援原生元素並不奇怪,因為 HTML5 可訪問性的 IE11 瀏覽器評級永遠不會改進。但至少 ARIA 可以提供語義。

無論是否使用 ARIA,Edge 都不會宣告 figure 的 role 屬性。一旦 Edge 瀏覽器切換到 Chromium 核心,這種情況可能會改變。

Chrome 和 Firefox 提供了類似的支援,但是如果一個圖片有一個空的 alt 或缺少 alt 屬性,JAWS(預設的詳細設定)Chrome 會完全忽略 figure(包括它的 figcaption 的內容)。

這意味著 在各種 Medium 文章中 那些伴隨圖片的標題,都被與 Chrome 配合使用的 JAWS 完全忽略了。如果 JAWS 的設定更新能宣告所有影象(例如沒有提供 alt 屬性或值的圖片),那麼 JAWS 使用 Chrome 宣告這些 figure 標題。

不像 Chrome,在 JAWS 上使用 Firefox,圖片的 alt 為空或缺失,figurefigcaption 仍然會被識別。但是由於圖片將被完全忽略,使用螢幕閱讀器的人不得不推斷 figure 的主要內容是不是圖片。

NVDA 螢幕閱讀器

在使用 IE11、Edge、Firefox 64.0.2 和 Chrome 71 測試 NVDA 2018.4.1 版本時,沒有發現任何 figure。最接近的跡象是 NVDA + IE11 在宣告圖片或 figcaption 內容之前宣告 “edit”(不過 “edit” 沒有任何意義...)。測試 role="figure" 模式並沒有改變缺少宣告的情況。figure 的內容仍然可以訪問,但是不會表現內容和標題之間的關係。

VoiceOver(macOS)

測試在 macOS 10.14.2 上使用 Safari(12.0.2)和 Chrome(71.0.3578.98)進行,並使用了 VoiceOver 9。

Safari

當使用 Safari 進行測試時,figure 將會顯示出它的 role 屬性。如果沒有語義化的屬性(例如沒有 figcaption, aria-label 等),則不會顯示出 figure 的 role 屬性。

VoiceOver 可以導航到 figure,並單獨與 figurefigcaption 的主要內容進行互動。

Chrome

儘管 Chrome 的可訪問性檢查器指出 figure 的語義正在被揭示,可訪問屬性由標題提供,但 VoiceOver 並不像 Safari 那樣定位或宣告 figure 的存在。除非 figure 特別有一個 aria-label 屬性。使用 figure 上的 aria-labelledbyaria-labelledby 指向 figcaptionfigure 不會被 VoiceOver 識別 。為了正確地向 VoiceOver 傳達 figure,使用 Chrome 時需要以下標記:

<!-- 
  aria-label 需要重複 figcaption 的內容,按預期宣告 figure。
-->
<figure aria-label="Figcaption 內容放這兒。">
  <!-- figure 內容 -->
  <figcaption>
    Figcaption 內容放這兒。
  </figcaption>
</figure>
複製程式碼

figure 元素上加一個 role="figure" 屬性,或者用其他元素替代 <figure>,仍然需要新增 aria-label 來讓 VoiceOver 使用 Chrome 時識別 role 屬性。

VoiceOver(iOS 12.1.2)

在用 VoiceOver 測試 Safari 和 Chrome 時,沒有顯示出 figure,也沒有顯示出 figure 的內容和標題之間的關係。<figure>role="figure" 模式都產生了相同的結果。

TalkBack(Android 8.1 上的 7.2 版)

在測試 Chrome(70)和 Firefox(63.0.2)時,沒有顯示出任何 figure,也沒有顯示出 figure 內容與其標題之間的關係。<figure>role="figure" 模式都產生了相同的結果。

Narrator & Edge 42 / EdgeHTML 17

Narrator 根本沒有顯示出 figure 的 role。但是,原生元素和 role="figure" 確實對 figure 的內容的宣告方式有影響。當 figure 具有語義化屬性時,figure 的內容(例如影象的 alt 文字)和 figure 的語義化屬性(figcaption 內容或 aria-label)將同時顯示。如果圖片的 alt 值為空,則會完全忽略 figure 及其 figcaption

總結

根據 figure 及其標題的預期用例,以及目前螢幕閱讀器對這些元素的支援,如果你想確保語義傳達給儘可能多的受眾,應該考慮以下標記模式:

<figure role="figure" aria-label="repeat figcaption content here">
  <!-- figure content. if an image, provide alt text -->
  <figcaption>
    figure 的標題。
  </figcaption>
</figure>

<!--
  使用 aria-label 相容 macOS VoiceOver 和 Chrome
  使用 role="figure" 相容 IE11。

  IE11 需要一個可訪問的屬性(由 aria-label 提供)。
  如果不是因為 VO + Chrome 不支援
  可訪問的屬性:aria-labelledby,該屬性
  會被優先/指向 <figcaption> 的 ID。
-->
複製程式碼

此模式將確保下面的搭配顯示 figure 的 role 屬性及其標題:

  • JAWS 配備 Chrome、Firefox 和 IE11。
  • macOS VoiceOver 配備 Safari 和 Chrome。
  • Edge 和 Narrator 將建立一個關係,但不會宣告 figure 的 role 屬性。

目前,移動螢幕閱讀器不會顯示 figure,Edge 瀏覽器也不會,除非與 Narrator(類似)配對使用,或任何瀏覽器與 NVDA 配對使用。但不要讓這些差距阻礙你按照規範的預期使用元素。

隨著 Edge 轉為 Chromium核心,更好的支援在不久的將來可能成為現實。雖然 NVDA 和移動螢幕閱讀器沒有宣告語義,但內容仍然是可訪問的。把 bug 記錄下來 是我們目前能為這些漏洞帶來改變做的最好的事情。

感謝大家點選 Steve Faulkner 來評審我的測試並閱讀本篇文章。

擴充閱讀

下面是更多關於 figure 的和 figcaption 的資源和上文使用的測試頁面/結果,以及 JAWS 和 NVDA 歸檔的 bug:

如果發現譯文存在錯誤或其他需要改進的地方,歡迎到 掘金翻譯計劃 對譯文進行修改並 PR,也可獲得相應獎勵積分。文章開頭的 本文永久連結 即為本文在 GitHub 上的 MarkDown 連結。


掘金翻譯計劃 是一個翻譯優質網際網路技術文章的社群,文章來源為 掘金 上的英文分享文章。內容覆蓋 AndroidiOS前端後端區塊鏈產品設計人工智慧等領域,想要檢視更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章