[譯] 你認爲「figure」怎麼用?

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

  • 爲一段內容提供一個描述性標籤,
  • 該標籤與當前文件相關,但用戶對它的理解並不重要。

爲了獲得更具體的信息,讓咱們分別來了解一下這些元素。前端

figure 元素

一般 figure 元素被認爲用來包裹圖或圖表,它還能夠承載文檔主要內容中引用的但不是冗餘信息的任何內容(代碼片斷、引用、音頻、視頻等)。在文檔流中能夠把 figure 徹底刪除,而不會影響用戶對主要內容的理解。html5

例如,描述 unladen Swallow 空速的文檔,可能有一節描述南非燕子和歐洲燕子之間的差別。伴隨文本內容的多是一個 figure 標籤,並排展現了這兩種鳥類的差別,以補充文檔中描述的信息。android

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

在這個基本的例子中,figurefigcaption 起到了引用前文內容的做用。若是去掉它們,目前爲止全部的文本信息依然起到了 figure 的做用。ios

圖片來源(2003)git

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

figcaption 元素

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

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 屏幕閱讀器

在使用 IE十一、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前端後端區塊鏈產品設計人工智能等領域,想要查看更多優質譯文請持續關注 掘金翻譯計劃官方微博知乎專欄

相關文章
相關標籤/搜索