1. Web
  2. 無障礙
  3. 指南
  4. 預防癲癇發作和身體反應

網頁癲癇發作和身體反應的無障礙性

本文介紹了為前庭功能障礙者提供無障礙網頁內容背後的概念，以及如何測量和防止內容導致癲癇發作和/或其他身體反應。

概述

癲癇發作

由光引起的癲癇發作被稱為光敏性癲癇。閃爍、閃動或忽明忽暗的內容可能會誘發光敏性癲癇。使用影片、動畫 GIF、動畫 PNG、動畫 SVG、Canvas 以及 CSS 或 JavaScript 動畫的 Web 技術都可能產生誘發癲癇發作或其他致殘性身體反應的內容。某些視覺模式，尤其是條紋，即使不是動畫，也可能引起身體反應。光敏性癲癇實際上是一種“反射性癲癇”——癲癇發作是對一種觸發因素的反應。就光敏性癲癇而言，癲癇發作是由閃爍的燈光特別觸發的，但其他型別的反射性癲癇可能是由閱讀行為或噪音觸發的。圖案和影像也可能觸發癲癇。

靜態影像可能導致癲癇發作和其他障礙的事實在 《伽馬振盪和光敏性癲癇》 等文章中有所記載，其中指出：“某些視覺影像，即使在沒有運動或閃爍的情況下，也可能觸發光敏性癲癇患者的癲癇發作”。癲癇基金會在其文章 《揭示光敏性——癲癇最複雜的病症之一》 中談到了靜態影像和圖案：“可辨別的明暗條紋的靜態或移動圖案與閃爍的燈光具有相同的效果，因為明暗區域的交替。” 美國癲癇基金會工作組能夠對這個問題進行一些“量化”：“具有誘發癲癇發作潛力的圖案包含清晰可辨的條紋，在任何方向上都有超過五對明暗條紋”。此外，根據 Cedars-Sinai 的說法，棋盤格圖案也已知會導致光敏性癲癇發作。

雖然靜態影像可能作為觸發因素，但它們的一致性較低。已經確立且強烈的觸發因素是閃爍/頻閃燈。USF 綜合癲癇專案的 Selim Benbadis 博士指出，“唯一真正有記載的是閃爍的燈光，它可以觸發光敏性癲癇患者的癲癇發作。但只有少數型別的癲癇是光敏性的，絕大多數癲癇不是。” 除了由光敏性引起的癲癇發作外，聽某些音樂也可能觸發所謂的音樂性癲癇，儘管這類癲癇似乎要罕見得多。要了解關於音樂性癲癇主題的精彩介紹，請訪問安大略癲癇組織的 音樂性癲癇 網頁。

癲癇發作和癲癇病不是一回事。在其文章 《癲癇病的修訂定義》 中，癲癇基金會指出：“癲癇發作是一次事件，而癲癇病是涉及反覆無故發作的疾病。”根據癲癇基金會的頁面 《癲癇發作有多嚴重？》，“癲癇意外猝死 (SUDEP) 可能是癲癇患者最常見的與疾病相關的死亡原因。它不常見，但它是一個非常現實的問題，人們需要意識到其風險”。

重點是，癲癇發作絕對可能是致命的，而開發者和設計師對於使網路成為對光敏性或音樂性觸發因素敏感者更安全的地方至關重要。

癲癇發作可能是致命的，但即使是那些“僅僅”使人衰弱的發作，其嚴重程度也可能使使用者失去能力。其他障礙，如定向障礙、噁心、嘔吐等，也可能嚴重到使使用者無法正常工作。癲癇基金會的文章 《光敏性與癲癇發作》 提供了一個可能導致光敏人群癲癇發作的觸發因素列表；以下是該列表的摘錄

  • 電視螢幕或電腦顯示器，由於閃爍或滾動影像。
  • 某些影片遊戲或電視廣播，包含快速閃光或不同顏色的交替模式。
  • 強烈的頻閃燈，如視覺火警警報。
  • 自然光，如陽光，特別是當它在水面閃爍、透過樹木或百葉窗的板條閃爍時。
  • 某些視覺圖案，特別是對比色的條紋。

同一篇文章繼續指出，許多因素必須結合才能觸發光敏反應。值得注意的是，它將光的波長作為一個可能的因素；光譜中紅色部分的波長似乎特別有問題。在文章 《理解 WCAG 2.0：每秒三次閃爍或低於閾值》 中，通常指出：“患有光敏性癲癇症的個人可能會因內容以特定頻率閃爍超過幾次而被觸發癲癇發作”，並特別指出：“人們對紅色閃爍比對其他顏色更敏感，因此為飽和紅色閃爍提供了專門的測試”。

你甚至不需要影像或影片來造成傷害。一個設定為以高頻率改變顏色和亮度的 <div> 元素，透過 JavaScript 很容易實現，就可能造成真正的傷害。而且，閃爍無處不在。例如，通常用於在頁面載入時顯示的“載入指示器”，在旋轉時很容易“閃爍”。

對於有運動技能問題的個人存在額外的擔憂。例如，Trace Research & Development Center 的 光敏性癲癇分析工具 的頁面指出，“光敏性癲癇發作可由網頁或計算機內容中的某些型別的閃爍引起，包括導致螢幕大面積反覆快速閃爍的滑鼠懸停”。

其他身體反應

噁心、眩暈（或頭暈）和定向障礙是非常不特定的症狀，與各種疾病有關，並不特別暗示癲癇發作（除了定向障礙，這在癲癇發作中可以看到）。然而，癲癇發作並不是閃爍、忽明忽暗、閃動和其他類似刺激可能產生的唯一不良身體反應。1997 年，一部日本卡通片中出現了一個動畫“病毒炸彈”。一些觀看該卡通片的兒童反應為癲癇發作，另一些則出現噁心、顫抖和吐血。孩子們的反應非常嚴重，他們不得不被緊急送往急診室。下面列出的身體障礙都是可能產生的後果：這些身體反應中的每一種都可能嚴重到使人喪失能力。

  • 癲癇發作
  • 前庭障礙
  • 偏頭痛
  • 噁心
  • 嘔吐

閃爍、閃動和忽明忽暗

儘管“flashing”（閃光）和“blinking”（閃動）有時可以互換使用，但它們並不相同。根據 W3C 的說法，閃動是一個分散注意力的問題，而閃光指的是每秒發生超過 3 次，並且足夠大和亮的內容。Section 508 禁止頻率大於 3 赫茲（每秒閃爍次數）且低於 55 赫茲的閃爍效果。癲癇基金會的文章 《揭示光敏性，癲癇最複雜的病症之一》 指出，“通常，頻率在每秒 5 到 30 次閃爍（赫茲）之間的閃光最有可能引發癲癇發作。為了安全起見，共識建議光敏個體不應暴露於每秒超過三次的閃光。” 然而，對於某些人來說，閃光/閃動在低於 3 赫茲時也可能引起症狀。

值得注意的是，並非所有的閃光和閃動都是不好的。美國宇航局（NASA）在其題為 《閃動、閃光和時間響應》 的檔案中指出，閃動和閃光可以成為吸引注意力的強大工具——這對於警示按鈕是必要的（這假設使用者在元素閃爍時仍能看到螢幕，但並非總是如此）。對於某些使用者來說，閃動的按鈕也警告他們必須謹慎和有節制地使用。就網頁設計而言，透過“劫持”螢幕以提供閃爍的緊急警告來提醒公司員工危險的系統，需要考慮螢幕上這些警告閃爍時的速率、大小和亮度變化。

閃光和閃爍——如何量化危險？

根據文章 《光和圖案誘發的癲癇發作：美國癲癇基金會工作組的專家共識》，“如果閃光的亮度 ≥20 cd/m2，頻率 ≥3 Hz，並佔據 ≥0.006 球面度的立體視角（在典型觀看距離下約佔中央視野的 10% 或螢幕面積的 25%），則閃光是潛在的危險。”

典型的觀看距離是多遠？撰寫本文時考慮的典型觀看距離建議是“該區域可以視為適用於電視螢幕面積的 >25% 的區域，假設標準觀看距離為 ≥2 米（約 9 英尺）”。自那時以來，情況發生了很大變化，我們現在離螢幕更近了。

某些顏色和/或顏色組合也很重要。《研究人員發現，某些顏色更容易引起癲癇發作》 指出，“……大腦動力學的複雜性可能更多地受到某些顏色組合的調節，例如，紅藍閃爍刺激比紅綠或藍綠刺激引起更大的皮層興奮。”

閃光與紅色閃光

WCAG 2.3.1 通用閃光和紅色閃光閾值 定義如下：

  • 通用閃光被定義為一對相對亮度變化達到或超過最大相對亮度 10% 的相反變化，其中較暗影像的相對亮度低於 0.80，並且“一對相反變化”是指先增加後減少，或先減少後增加；
  • 紅色閃光被定義為任何涉及飽和紅色的相反轉變對。

這些標準基於早期的研究。2004 年，美國癲癇基金會召開了一次研討會，就光敏性癲癇達成了 共識，指出“如果閃光的亮度至少為 20 cd/m2，頻率至少為 3 Hz，並且佔據的立體視角至少為 0.006 球面度（在典型觀看距離下，約佔中央視野的 10% 或螢幕面積的 25%），則閃光是潛在的危險。” 向飽和紅色的轉變或從飽和紅色的轉變本身也很重要並構成風險：“無論亮度如何，向飽和紅色的轉變或從飽和紅色的轉變也被認為是一種風險。”

尺寸和距離

多大？視情況而定

“相對”大小和距離都很重要。根據 PEAT 的說法，“當內容以 1024 x 768 畫素觀看時，同時發生的閃光的總面積不得超過顯示螢幕區域上任何 341 x 256 畫素矩形的四分之一。”

視野是一個重要考慮因素的觀點在討論 WCAG 2.3.1 的文章中繼續出現：“1024 x 768 螢幕被用作評估的參考螢幕解析度。341 x 256 畫素塊代表在典型觀看距離下的 10 度視口。（10 度視野取自原始規範，代表人眼中央視覺部分，人們最容易受到光刺激。）”

這個像素面積比計算的是相對大小，但距離也很重要。

距離之所以重要，是因為它影響總視野。當觀看者佩戴眼罩進行遊戲時，視野很可能完全被螢幕包圍。WebXR 是一項開放規範，使得在瀏覽器中體驗 VR 成為可能，可以在手機、電腦或頭戴裝置上體驗。在眼罩中閃爍影像的擔憂日益增加，因為眼罩離眼睛非常近。

研究普遍表明，由於重新整理率較高，VR 的使用實際上可能比正常的螢幕消費更安全。正如 Fisher 等人 2022 年 的總結，“目前有限的資料並未引發對 VR 技術的特殊癲癇擔憂，儘管隨著經驗的增加，這種看法可能會改變。某些型別的 VR 內容，包括明亮的閃光、刺激性的圖案或顏色變化，預計會像在現實世界中一樣誘發癲癇發作。”

（請注意，一些使用者可能無法看清閃爍的游標，並可能出現偏頭痛、暈動病和定向障礙，儘管閃爍的光標占據螢幕的面積要小得多。）

圖案和視差

對比強烈的明暗幾何圖案是已知的罪魁禍首；條紋和棋盤格是最著名的例子。美國癲癇基金會工作組列出了可能誘發癲癇發作的明暗條紋對的數量以及在何種條件下。如果圖案是不變且筆直的，則最多允許八條線，但如果它波動，則不超過五條線。

視差效應可能導致定向障礙。請謹慎使用視差效應；如果必須使用，請確保使用者有控制元件可以關閉它們。

“具有誘發癲癇發作潛力的圖案包含清晰可辨的條紋，在任何方向上數量超過五對明暗條紋。當任何圖案的明暗條紋從最小預期觀看距離在眼睛處共同形成 >0.006 球面度的立體角時，最亮條紋的亮度 >50 cd/m2，並且圖案呈現 ≥0.5 秒，則如果條紋改變方向、振盪、閃爍或對比度反轉，圖案應顯示不超過五對明暗條紋；如果圖案不變或在一個方向上平滑漂移，則不超過八條條紋。”

並非所有情況都已知，即使有上述指標，還有其他因素在起作用。例如，從較小區域變為較大區域會增加大腦反應的可能性，同時增加對比度，以及將空間頻率從低增加到中。同樣已知的是，儘管其背後的原因尚不清楚，但從基本方向（例如，條紋）變為多個方向（例如，將一組條紋疊放在原始條紋之上但與之垂直時出現的棋盤格圖案）會影響大腦。

顏色

理解顏色對於無障礙性很重要。請參閱理解顏色和亮度，因為它關係到網頁無障礙性和一般無障礙性。

顏色如何與其背景相關——通常以對比度的形式來描述——以及顏色在動畫中幀與幀之間變化有多劇烈，這都很重要。有關此方面的更多資訊，請參閱每秒三次閃爍或低於閾值理解 SC 2.3.1。

紅色的特殊情況

已經證明，某些顏色比其他顏色更容易引起癲癇發作。人類的生理和心理通常會受到紅色的影響。它影響行為的力量甚至在動物中也已得到注意。

  • 紅色脫飽和測試：人眼對紅色的敏感度如此之高，以至於眼科醫生用它來設定測試。紅色脫飽和測試評估視神經的完整性。有關眼科醫生如何使用此測試的更多資訊，請參閱紅色脫飽和。
  • 紅色環境：研究表明，對於患有創傷性腦損傷的人來說，在紅色環境中認知功能會降低。

飽和紅色是一種特殊的、危險的情況，並且有專門的測試。除了紅色環境會影響創傷性腦損傷患者的認知功能外，紅色光譜波長中的顏色似乎也需要特別關注和特殊測試。Gregg Vanderheiden 博士在測試光敏性癲癇分析工具時指出，癲癇發作率遠高於預期。他們發現我們對飽和紅色閃爍更為敏感。（請參閱影片《光敏性癲癇分析工具》。）

網路安全色不等於癲癇安全色

請注意，顏色 #990000 被認為是“網路安全色”。這並不意味著它對於“不引起癲癇發作是安全的”，它只意味著該顏色可以被用於在螢幕上生成顏色的技術“安全地”準確再現。

透過測量預防傷害

衡量潛在危害是一個很好的起點。測試中考慮的因素包括顏色、亮度、大小、對比度，以及在動畫的情況下，頻率。WCAG 2.1 提供了評估內容的指導。

2004 年 8 月，美國癲癇基金會召開了一次研討會，開始就光敏性癲癇達成專家共識。以下專家和權威資訊來自：光和圖案誘發的癲癇發作：美國癲癇基金會工作組的專家共識。

如果閃光的亮度 ≥20 cd/m2，頻率 ≥3 Hz，並佔據 ≥0.006 球面度的立體視角（在典型觀看距離下約佔中央視野的 10% 或螢幕面積的 25%），則閃光是潛在的危險。向飽和紅色的轉換或從飽和紅色的轉換也被認為是一種風險。具有誘發癲癇發作潛力的圖案包含清晰可辨的條紋，在任何方向上都有超過五對明暗條紋。當任何圖案的明暗條紋在最小預期觀看距離下共同在眼睛處形成 >0.006 球面度的立體角時，最亮條紋的亮度 >50 cd/m2，並且圖案呈現 ≥0.5 秒，那麼如果條紋改變方向、振盪、閃爍或對比度反轉，圖案應顯示不超過五對明暗條紋；如果圖案不變或在一個方向上平滑漂移，則不超過八條條紋。這些原則在固定媒體（例如，可以逐幀分析的預錄電視節目）的情況下比在互動式媒體中更容易應用。

“cd/m2” 指的是坎德拉每平方米。那麼對於網頁開發者來說，這與顏色、亮度和飽和度的測量有何關係？

坎德拉是 SI 單位（國際單位制）中的光強度單位。它是一個光度學術語，而光度學涉及人眼所感知的可見光的測量。維基百科關於“坎德拉每平方米”的文章以我們作為開發者所熟悉的方式來描述它：在顯示裝置上，以及在 RGB 空間中。這很有幫助，因為有一個特定的標準被假定用於顯示器、印表機和網際網路，那就是 sRGB（標準紅綠藍）。

作為每單位面積發出的光的度量，這個單位經常被用來指定顯示裝置的亮度。顯示器的 sRGB 規範目標是 80 cd/m2。通常，校準過的顯示器應該有 120 cd/m2 的亮度。大多數消費級桌面液晶顯示器的亮度在 200 到 300 cd/m2 之間。高畫質電視的亮度範圍從 450 到大約 1500 cd/m2。

關鍵在於，sRGB 色彩空間是研究、評估工具和開發者之間的共同接觸點，因為它很容易從常用的十六進位制程式碼轉換而來。

生理和心理因素的考慮

許多專家致力於儘可能量化和測量可能作為癲癇發作觸發因素的網頁內容。然而，不能忘記的是，顏色既是人腦中的感知，也是對來自電腦螢幕的光的測量。

除了心理差異外，我們之間也存在生理差異。一個真實的人如何感知和響應顏色和光，會有各種差異和細微之處。例如，加州州立大學長灘分校計算機科學榮休講師 Tom Jewett 指出，關於 HSL 色彩尺度中的亮度，“……亮度級別之間的區別實際上並非像 HSL 尺度所暗示的那樣是線性的；我們對較亮值的變化比對較暗值的變化要敏感得多。”

重要的是要理解，光及其測量是線性的，但人類視覺和人類感知不是。關於如何將機器對光的測量（從電腦螢幕發出，經過一定距離到達人眼，被人眼視覺過濾，然後透過人腦處理）關聯起來，正在進行調查和討論。

甚至年齡和性別也可能起作用。根據癲癇基金會的文章 《揭示光敏性，癲癇最複雜的病症之一》，“兒童和青少年比成年人更容易對光刺激產生異常反應，第一次由光引起的癲癇發作幾乎總是在 20 歲之前發生”。 該文章接著提供了這個統計資料：“女孩（60%）比男孩（40%）更容易受到影響，儘管男孩的癲癇發作更頻繁，因為他們更可能玩影片遊戲。影片遊戲通常包含潛在的刺激性光刺激”。

使用者測試非常成問題。自然地，沒有人願意讓一個容易癲癇發作的個體進行使用者測試。這很危險。因此，開發者和設計師能做的最道德的事情之一，就是使用由該領域專家與醫生攜手開發的工具。在撰寫本文時，有兩種常用的工具是由研究人員和醫生為電影/影片而道德和專業地開發的：PEAT 和 Harding 測試。

光敏性癲癇分析工具 (PEAT)

Trace 研究與開發中心為光敏性癲癇分析工具樹立了黃金標準，並且他們特意使其可以免費下載。PEAT 可以幫助作者確定其內容中的動畫或影片是否可能引起癲癇發作。請注意其使用限制：禁止使用 PEAT 評估用於電視廣播、電影、家庭娛樂或遊戲行業的商業製作材料。請使用 Harding 測試或其他工具用於商業目的。

要獲取馬里蘭大學光敏性癲癇分析工具的免費副本，請訪問 Trace 研究與開發中心。

University of Maryland College of Information Studies Photosensitive Epilepsy Analysis Tool.

哈丁測試

由於 PEAT 工具禁止商業使用，電視節目製作人可以在 HardingTest.com 使用哈丁測試。哈丁測試是另一個黃金標準。各國的電視節目製作人必須透過此測試才能進行廣播，因此 HardingTest.com 的團隊提供影片內容的分析和認證。

Harding Flash and Pattern Analyzer.

面向開發者的無障礙解決方案

所有動畫都具有潛在危險。作為設計師和開發者，我們的責任是確保我們不會有意或無意地造成傷害。如果我們必須包含可能造成傷害的內容，至關重要的是要防止使用者意外遇到有害內容，並提供方法讓使用者預防和控制動畫，以減輕潛在傷害。

網頁開發者可以做什麼

勿施傷害

WCAG 指南 2.3 癲癇發作和身體反應 提供了概述：“不要以已知會導致癲癇發作或身體反應的方式設計內容”。不要包含使用者無法控制的動畫。不要使用已知會引起問題的圖案進行設計。如果必須包含帶有閃爍的 gif 或 png，請將其錄製成影片格式，以便使用者可以使用控制元件。讓使用者能夠避免、關閉或使其危害性降低。

理解惡意行為

作為開發者或設計師，問問自己，閃爍的內容是否真的需要出現在你的網頁上。即使處理得當，也有人可能會從你的網站下載有問題的內容並將其武器化。據信，首次有記載的試圖利用計算機透過動畫造成身體傷害的事件始於 2008 年 3 月 22 日星期六：癲癇基金會的網站被駭客攻擊，釋出了帶有閃爍影像和虛假聲稱有幫助的連結的帖子。正在該網站尋求幫助的前庭障礙使用者受到了影響。

在記者 Kurt Eichenwald（一位已知的癲癇患者）於 2016 年 12 月收到一個動畫 gif 後，引發了一系列法律考量，該 gif 帶有資訊：“你的帖子讓你活該發作一次癲癇”。

控制曝光，控制訪問

控制對頁面的暴露是確保易患癲癇的人不會意外接觸到它的關鍵。WCAG 指出，單個物件就可能使整個頁面無法使用。

如果你認為你可能有一個可能導致癲癇發作的影像或動畫，請透過首先顯示關於該內容的警告來控制對它的訪問，然後將其放在一個使用者必須選擇加入的位置，例如點選一個按鈕，或者確保頁面的連結有明確而明顯的警告。

考慮為搜尋引擎設定爬取指令，以提示它們不應將可能有害的資源包含在其搜尋索引中。你可以透過在 <meta name="robots"> 元素中使用限制性規則（如 noindex, nofollow）來實現這一點。透過不索引頁面（noindex）和不跟蹤頁面上的連結（nofollow），使用者透過搜尋偶然發現它的可能性將降低。

html
<html lang="en">
  <head>
    <title>…</title>
    <meta name="robots" content="noindex, nofollow" />
  </head>
</html>

對於非 HTML 資源，你可以在 X-Robots-Tag HTTP 響應頭中設定爬取指令。

http
X-Robots-Tag: noindex

動畫 GIF

所有影像型別都具有潛在危險，然而，動畫 GIF 因其普遍存在以及動畫速度實際上由 GIF 檔案本身控制而值得特別提及。

檢測 GIF 是否為動畫

對於動畫 GIF，確保動畫在使用者選擇啟用之前處於非活動狀態。例如，使用者必須按下按鈕或選中複選框才能啟動動畫。

影片

與動畫 GIF 的情況一樣，使用者必須按下按鈕或選中複選框才能啟動動畫。有很多方法可以做到這一點，比如不要在 <video controls> 中新增 autoplay 屬性，或者將 animation-play-state 的初始狀態設定為 paused。要看一個這方面如何實際運作的強大示例，請參閱 Kirupa 的文章 《開啟和關閉動畫》。Kirupa 將 animation-play-state 與 transition、transform 和 prefers-reduced-motion 結合使用，創造了一個由使用者控制的非常無障礙的體驗。

animation-play-state 是一個 CSS 屬性，用於設定動畫是正在執行還是暫停。

css
div {
  animation-play-state: paused;
}

CSS 過渡可用於將動畫初始階段的持續時間設定為零。

css
div {
  transition-duration: 0s;
}

確保使用者既能啟動動畫，也能停止動畫

一個沒有任何屬性的 <video> 元素不會自動播放，也沒有控制元件。請確保將 controls 屬性新增到 video 元素，以便使用者既能啟動影片，也能停止影片。

html
<video controls>
  <source src="video.mp4" type="video/mp4" />
  <source src="video.ogg" type="video/ogg" />
  Your browser does not support the video tag.
</video>

以程式設計方式確保控制元件可用

HTMLMediaElement.controls 屬性反映了 controls HTML 屬性，它控制是否顯示用於播放媒體專案的使用者介面控制元件。

影片

為確保影片具有使用者可以訪問的控制元件，請務必在 HTML 影片和音訊元素中新增“controls”一詞。

<video controls>

html
<video controls>
  <source src="myVideo.mp4" type="video/mp4" />
  <source src="myVideo.webm" type="video/webm" />
  <p>
    Your browser doesn't support HTML video. Here is a
    <a href="myVideo.mp4">link to the video</a> instead.
  </p>
</video>
音訊

將同樣的例子應用於音訊

<audio controls>

html
<audio controls>
  <source src="myAudio.ogg" type="audio/ogg" />
  <source src="myAudio.mp3" type="audio/mpeg" />
  <p>
    Your browser does not support the audio element. Here is a
    <a href="myAudio.mp3">link to the audio</a> instead.
  </p>
</audio>
作為影片一部分的音訊

請注意，影片中的音訊可以透過 muted 內容屬性來控制，即使內容是在 <video> 元素內，而不是 <audio> 元素內。這個例子來自 HTML Living Standard 中關於 muted 媒體屬性 的描述部分。它解釋了影片將在後臺靜音自動播放，直到使用者採取行動取消靜音。

html
<video src="adverts.cgi?kind=video" controls autoplay loop muted></video>

控制速度

這似乎是顯而易見的，但由於 MIME 型別如此之多，處理它們的機制差異很大，因此沒有一個一刀切的解決方案。更復雜的是，即使是檔案的分類方式也使如何處理它們變得複雜。例如，.gif 檔案格式通常被理解為影像，但由於其動畫能力，在某些圈子中也被視為影片檔案格式。要獲取媒體型別的全面列表，請訪問 IANA.org 的媒體型別頁面。

嗅探它們的方法並非易事。你可能會對 whatwg.org 上的 MIME 嗅探標準感興趣。幾乎每種影像都可以被動畫化；它們的動畫方式各不相同，因此，動畫的控制方式也不同。

常見的動畫檔案型別

  • 點陣圖：動畫
  • Canvas：MDN 的 Canvas 教程有一個關於基本動畫的精彩部分。setInterval() 是 Canvas 動畫中的中流砥柱，但看它如何與螢幕重新整理互動也很有趣。請參閱文章《用 requestAnimationFrame 控制 fps？》，其中他們討論了在螢幕重新整理的背景下實現 requestAnimationFrame 的細節。
  • GIF（光柵）：難以破解，因為它們的動畫控制權在於 gif 檔案本身。有關控制 GIF 速度的資訊，請參閱 W3C 的 “G152：設定動畫 gif 影像在 n 個週期後（5 秒內）停止閃爍”。Stack Overflow 上一篇關於該主題的精彩文章是 “你能用 JavaScript 控制 GIF 動畫嗎？”
  • GIFV（光柵）：被認為是 GIF 的一種變體，即影片版本。該格式沒有標準化，必須引用一個“真實”的影片檔案（例如，一個 .webm 檔案），該檔案必須存在於別處。
  • JPG (光柵)
  • MNG (光柵): 多影像網路圖形是一種用於動畫影像的圖形檔案格式。也被一些人認為是影片格式。
  • PNG、APNG（光柵）：行動式網路圖形和動畫行動式網路圖形都可以是動畫的。
  • SVG（向量）：MDN 文件 《SVG：可縮放向量圖形》 指出，“SVG 是一種基於文字的開放 Web 標準。它被明確設計為與其他 Web 標準（如 CSS、DOM 和 SMIL）協同工作。” SVG 可以像本例中那樣用作影像：<img src="example.svg" alt="這是一個使用 svg 作為源的影像">。這意味著 SVG 的外觀和動畫可以透過 CSS 關鍵幀和動畫來控制。關於與 JavaScript 的互動，請參閱 MDN 關於 SVG 介面和將 SVG 效果應用於 HTML 內容的文件。
  • Voxel（光柵）：三維體素光柵圖形被用於影片遊戲以及醫學成像。

文字也可以是動畫的

平移和變換可以使 div 中的文字動起來，並造成傷害。移動的文字會因為與移動影像相同的原因誘發癲癇發作，所以請避免讓你的文字動起來。無論如何，最好避免使用移動文字，因為許多螢幕閱讀器無法讀取移動文字，即使對於沒有視覺或前庭問題的人來說，這也是糟糕的使用者體驗。

用於動畫的 CSS

在樣式表或 <style> 元素中，許多選項可以結合在一起，為使用者創造強大的體驗。我們已經在本文件的前面提到了 animation 屬性。它實際上是所有動畫屬性的簡寫，包括

  • animation-play-state
  • animation-duration 的值為 <time>；這是動畫完成一個週期所需的時間。這可以以秒 (s) 或毫秒 (ms) 為單位指定。預設值 0s 表示不應發生動畫。
  • animation-timing-function

動畫屬性本身已經很強大，但與 prefers-reduced-motion 等其他屬性和查詢結合使用，可以為使用者設定一套強大的選項。將 animation-duration 和 transition-duration 屬性設定為一個較短的持續時間，而不是將它們設定為 animation: none 和 transition: none，可以提供一種保障，以防止在動畫需要執行時出現問題。

JavaScript 動畫

JavaScript 通常用於控制 <canvas> 元素和 SVG。大多數適用於 HTML 影片的 JavaScript 程式碼也適用於音訊。HTMLMediaElement.playbackRate 用於為影片和音訊實現使用者對播放速率的控制。值為 1.0 是預設值，被認為是正常速度；值為 0.5 是半速，值為 2.0 是兩倍速。負數會向後播放影片或音訊。設定播放速率屬性：HTMLMediaElement.playbackRate = playbackSpeed。

document.getAnimations() 是一項實驗性技術，包括 CSS 動畫、CSS 過渡和Web 動畫。MDN 關於 Document.getAnimations() 的頁面提供了以下程式碼示例，演示如何將頁面上的所有動畫減慢到一半速度

js
document.getAnimations().forEach((animation) => {
  animation.playbackRate *= 0.5;
});

動畫的影像源

最簡單的方法之一是從一個已經存在的影像開始，將其用作影像源，然後對其進行動畫處理。請記住，你可以在這裡使用 GIF、JPG、PNG、SVG 和其他檔案型別作為影像源，只要它們是你的環境中允許的檔案型別和大小。由於安全問題，SVG 通常不被允許。MDN 文件《基本動畫》提供了這方面的出色示例，它使用多個影像源來表示太陽、地球和月亮，並使用多種畫布方法來控制地球繞太陽執行以及月亮繞地球執行的速度和動畫。使用本教程提供的 codepen 調整程式碼中的 ctx.rotate，看看進行更改後動畫會受到怎樣的影響。

如果你絕對、必須使用閃爍動畫……

確保它上面有控制元件。確保當觀看者第一次遇到它時它是關閉的，並且使用者必須選擇加入才能看到動畫。

一個使用者無法使用控制元件的格式示例是 gif 檔案。動畫速度由 gif 影像本身控制。將動畫 gif 轉換為影片可以為動畫新增控制元件，並給予使用者自主權。有許多免費的線上轉換器可供使用，例如 EZGif 和 GIF to MP4。

設定使用者期望

在使用者點選連結之前，給他們一個提示，告訴他們將會發生什麼。描述將要播放的動畫。請參閱 WCAG 2.2 成功標準 3.2.5 按請求更改。

保持小尺寸

如果你非要閃爍不可，請保持其尺寸小。一般來說，將閃爍的大小限制在大約 341 x 256 畫素或更小的區域內。這個畫素尺寸假設觀看者與螢幕的距離是典型的。如前所述，如果影像要在近距離觀看，比如在 VR 頭盔中，這個尺寸可能太大了。WebVR 是一個開放規範，它使得在瀏覽器中體驗 VR 成為可能。WebVR 可以在手機、電腦或頭盔上體驗。

如果你正在為使用眼罩的遊戲或 VR 設計，或者可以被眼罩使用，例如在 Firefox Reality（一個用於虛擬現實的瀏覽器）中，請確保矩形的大小遠小於 341 x 256 畫素，因為影像離使用者的眼睛更近。

降低對比度

通常情況下，在無障礙性方面，更高的對比度是件好事。文字顏色與其背景的對比度越大（根據 W3.org 關於良好對比度顏色的頁面，技術上稱為亮度對比度），這類內容就越容易閱讀。視力低下的使用者尤其感激為確保文字與背景的高對比度所做的努力。然而，當內容是動畫時，降低對比度實際上是降低動畫內容引起癲癇發作可能性的方法。如果在 1 秒內檢測到 3 次閃爍，請降低對比度。

WCAG 2.2 中對比度的定義如下：

對比度

(L1 + 0.05) / (L2 + 0.05)，其中

最好能在上傳或釋出到網路之前調整對比度。對於影片和動畫 GIF，Adobe Suite 產品是處理傳統影像的絕佳資源。對於影像，還有一個線上工具 pinetools.com 的線上亮度和對比度調整。例如，如果你打算製作動畫 GIF，請從對比度較低的影像開始。

JavaScript 也是動態降低對比度的一種選擇。以下是來自標題為“示例：設定段落的背景顏色”部分的示例程式碼。請注意，示例中的顏色是在 RGB 色彩空間中描述的。

HTML 內容（連結到源頁面）

html
<body>
  <input type="button" value="Set paragraph background color" />
  <p>hi</p>
  <p>hello</p>
</body>

JavaScript 內容（連結到源頁面）

js
function setBackground() {
  // now, get all the p elements in the document
  const paragraphs = document.getElementsByTagName("p");

  // get the second paragraph from the list
  const secondParagraph = paragraphs[1];

  // set the inline style
  secondParagraph.style.background = "red";
}

document.querySelector("input").addEventListener("click", setBackground);

避免對閃爍內容使用完全飽和的紅色

如本文件前面所述，美國癲癇基金會於 2004 年 8 月召開了一次研討會，開始就光敏性癲癇達成專家共識。他們的研究結果之一是，“如果閃光的亮度至少為 20 cd/m2，頻率至少為 3 Hz，並佔據至少 0.006 球面度的立體視角（在典型觀看距離下約佔中央視野的 10% 或螢幕面積的 25%），則閃光是潛在的危險。向飽和紅色的轉換或從飽和紅色的轉換也被認為是一種風險。” 他們在同一共識中還指出：“無論亮度如何，向飽和紅色的轉換或從飽和紅色的轉換也被認為是一種風險。”

提供備用 CSS 樣式

瞭解到大部分動畫和閃爍都可以透過 CSS 方法控制，探索為使用者提供備選方案，並使這些選項的控制方便可見，就顯得很重要了。

備用樣式表

現代瀏覽器會顯示備用樣式表中可用的備用 CSS，如果使用者知道在哪裡尋找它們的話。在某些情況下，備用樣式會在使用者透過“檢視”選單時顯示，在另一些情況下，它們會體現在設定中，有時兩者兼有。並非所有使用者都知道透過瀏覽器或設定來尋找這些選項，所以考慮用老式的方法，用明顯的按鈕或連結來改變樣式，這樣使用者就能看到它們。這樣做不會與瀏覽器讀取備用樣式表的能力，或者使用者在設定中設定偏好的能力相沖突或覆蓋。

重要的是要知道，某些使用者，例如那些依賴語音識別系統的使用者，通常依賴於傳統的按鈕和連結，因為他們的殘疾使他們無法使用滑鼠，或者無法利用移動平板電腦上的觸控事件。

將備用樣式表包含到 HTML 文件中的常用方法是使用 <link> 元素和 @import。

在網頁的 <head> 部分，使用 <link> 元素，並結合 rel="alternate stylesheet" 和 title="…" 屬性。

html
<head>
  <title>Home Page</title>
  <link href="main.css" rel="stylesheet" title="Default Style" />
  <link
    href="alternate1.css"
    rel="alternate stylesheet"
    title="Alternate One" />
  <link
    href="alternate2.css"
    rel="alternate stylesheet"
    title="Alternate Two" />
</head>

@import 也是一種引入樣式表的方式，但它的支援不如 <link> 元素廣泛。

css
@import "alternate1.css";
@import "alternate2.css";

透過使用備用樣式表（記得新增標題），你正在為使用者設定，讓他們能夠使用瀏覽器選擇備用樣式。

動態樣式切換

依賴瀏覽器來顯示備用樣式的一個問題是，並非所有使用者都具備足夠的技術知識來發現備用樣式。或者，由於他們的殘疾，他們無法做到。按鈕或連結讓許多心懷感激的使用者清楚地知道有可用的選項。有多種方法可以新增切換按鈕，讓使用者切換到不同的樣式表。也就是說，使用備用樣式表並非唯一選擇。另一個選擇是操縱頁面本身的樣式。根據 MDN 文件《使用動態樣式資訊》，“在可能的情況下，透過 className 屬性動態操作類確實是最佳實踐，因為所有樣式掛鉤的最終外觀都可以在單個樣式表中控制”。 關於如何做到這一點，最好的例子之一來自 W3C 的頁面《C29：使用樣式切換器提供符合規範的備用版本》。

極端情況：純文字替代方案

製作一個阻止影像顯示的獨立、備用樣式表很容易。這是一種嚴厲的解決方案；但對於學校教師和其他必須為極度敏感人群服務的公務員來說，有時是必要的。這些公務員可以要求他們的開發者使用 display: none 開發一個特殊的備用樣式表。以下是透過 CSS 實現的方法：

css
img {
  display: none;
}

利用媒體查詢和 <style>

在設定媒體查詢時，你正在為使用者啟用控制元件；這些控制元件在瀏覽器或作業系統中可用。請參閱 MDN 文件《無障礙性：使用者可以做些什麼來更安全地瀏覽》，以檢視使用者如何訪問控制元件的更多詳細資訊。

prefers-reduced-motion

現代瀏覽器對 prefers-reduced-motion 的支援正在增長。

css
@media screen and (prefers-reduced-motion: reduce) {
}
@media screen and (prefers-reduced-motion) {
}

要看一個如何使用 prefers-reduced-motion 程式碼的絕佳示例，請訪問 MDN 文件 prefers-reduced-motion，或參見下面來自“Chrome 74 新特性”部分的示例。

css
button {
  animation: vibrate 0.3s linear infinite both;
}

@media (prefers-reduced-motion: reduce) {
  button {
    animation: none;
  }
}

prefers-color-scheme

如果環境光 API 不可用，這可能很有用。支援正在出現。

css
@media (prefers-color-scheme: dark) {
  /* adjust styles for dark mode */
}

Window.matchMedia()

開發者可以透過 Window.matchMedia() 獲得一個強大的工具。一個很好的資源是 MDN 關於 Window.matchMedia() 的文件。

媒體更新功能

螢幕重新整理得越頻繁，它在人眼看來就越穩定，“閃爍”就越少。絕大多數現代技術以不會引起光敏性問題的速率重新整理。然而，並非每個人都富裕到能夠負擔得起最新技術：老舊或效能不足的計算機可能重新整理率很低。AbilityNet 的情況說明書（2015 年 11 月）《計算機與癲癇》描述了更多關於重新整理率的細節。

一篇很老的文章，Tech Republic 的 《癲癇與 CRT/LCD 螢幕閃爍》，有一個關於重新整理率（Hz）的有趣回應

  • “這種效果是顯而易見的，並且有記載，最高可達 70 赫茲。”
  • “這些研究似乎表明，你應該遠離低於 70 赫茲的重新整理率，並使用一個不能被 10 整除的速率。”

CSS-Tricks 的 Eric Bailey 發現了一種創新性地使用更新功能的方法，它與 animation-duration 或 transition-duration 結合使用，以人眼無法察覺的速率結束。換句話說，Eric 的技術解決了重新整理率問題。下面的 CSS 來自 CSS-Tricks 的文章《再談 prefers-reduced-motion，減少運動的媒體查詢》。

css
@media screen and (prefers-reduced-motion: reduce), (update: slow) {
  * {
    animation-duration: 0.001ms !important;
    animation-iteration-count: 1 !important; /* Hat tip Nick/cssremedy (https://css-tricks.com/revisiting-prefers-reduced-motion/#comment-1700170) */
    transition-duration: 0.001ms !important;
  }
}

update 媒體特性用於查詢輸出裝置在內容渲染後修改其外觀的能力。它有“none”、“slow”和“fast”三個值。

開發和實驗性功能

媒體查詢 Level 5

EnvironmentMQ（計劃在媒體查詢 Level 5 中）

light-level

light-level 有三個有效值：dim、normal 和 washed。有趣的是，該規範避免了以勒克斯為單位實際定義這三個級別，因為帶有光感測器的裝置通常會自動調整螢幕亮度。該規範還指出了技術上的差異，例如電子墨水在明亮的日光下仍然可讀，而液晶則不然。

environment-blending

來自 W3C 的草案文件《媒體查詢 Level 5》：“environment-blending 媒體特性用於查詢使用者顯示器的特性，以便作者可以調整文件的樣式。作者可能會根據顯示技術調整頁面的視覺效果和/或佈局，以增加吸引力或提高可讀性。”

使用者偏好媒體特性（計劃在媒體查詢 Level 5 中）

W3C 編輯草案媒體查詢 Level 5 中的使用者偏好媒體特性在為使用者提供媒體控制方面特別有前途。以下是一些亮點

inverted-colors

根據使用者偏好媒體特性部分，“inverted-colors 媒體特性指示內容是正常顯示，還是顏色已被反轉。”

forced-colors

在 forced-colors-mode 中，使用者代理在頁面上強制執行使用者首選的調色盤，覆蓋作者選擇的顏色。來自 W3C 的草案文件《媒體查詢 Level 5》關於 forced-colors 的部分：“forced-colors 媒體特性用於檢測使用者代理是否啟用了 強制顏色模式，在該模式下，它會在頁面上強制執行使用者選擇的有限調色盤”。 使用者需要被告知這個能力，並且它需要與 prefers-color-scheme 媒體查詢的適當值協調一致。

light-level

來自 W3C 的草案文件《媒體查詢 Level 5》關於 light-level 的部分：“light-level 媒體特性用於查詢裝置使用環境的光照水平，以允許作者相應地調整文件的樣式。” 這對於那些有運動技能問題的人，或者一些有認知困難、無法找到正確“按鈕”來更改螢幕設定的人來說，將是天賜之物。

prefers-contrast

來自 W3C 的草案文件《媒體查詢 Level 5》關於 prefers-contrast 的部分：“prefers-contrast 媒體特性用於檢測使用者是否請求系統增加或減少相鄰顏色之間的對比度。例如，許多使用者難以閱讀與文字背景對比度小的文字，並希望有更大的對比度。” 有時對比度也可能過高；在這種情況下，文本週圍可能會出現光暈效應，實際上會降低易讀性。將對比度的大小交給使用者控制，無疑是無障礙性的一大福音。

MediaQueryList 介面

CSSWG.org 草案的 4.2 節與 HTML 中定義的事件迴圈整合。HTML 中關於 MediaQueryList 物件的內容。有關更多資訊，請參閱 MDN 文件 MediaQueryList。

個性化幫助和支援

literal 屬性的要求取自 WAI-Adapt：幫助和支援。

要求：一些使用者無法理解非字面意義的文字和圖示，如隱喻、成語等。literal 屬性旨在將文字或影像標識為非字面意義，並允許作者向用戶解釋非字面意義的文字和影像。

另見

MDN

顏色

討論

癲癇與癲癇發作

GPII

ISO

  • IEC 61966-2-2:2003(en) 多媒體系統和裝置——色彩測量和管理——第 2-2 部分：色彩管理——擴充套件 RGB 色彩空間——scRGB

光敏性癲癇分析工具

與 Harding 工具一起，通常被認為是分析閃光的兩大“黃金標準”之一。

W3C

幫助改進 MDN

瞭解如何貢獻

本頁面最後由 MDN 貢獻者於修改。

在 GitHub 上檢視此頁面 • 報告此內容的問題
© . Content available under a Creative Commons license.