顧客下載的 PDF 發票，真的能讀懂和使用嗎？

先列出顧客需要從發票取得甚麼

發票是顧客辦事用的文件，不只是交易的圖片。顧客可能需要找實際商戶名稱、發票編號、發出日期、貨品或服務明細、適用的折扣或運費、總額、付款狀態，以及查詢差異的方法。需要放大文字的人會縮放畫面；使用屏幕閱讀器的人可能按標題和表格導覽；只用鍵盤的人則須到達下載連結及文件內的連結或欄位。驗收應由這些任務出發，使用實際模板和安全的示例交易。本題與「誰有權下載顧客發票」不同：權限保護入口，可達性則關乎已獲授權的人能否理解和使用文件。通過權限測試，不等於 PDF 已可用。

不要只憑外觀製作驗收清單。PDF 在畫面上可以排列整齊，抽取文字時卻顛倒次序，或失去表格欄與數值的關係。W3C 的 PDF 閱讀次序技術指出，標籤結構主要決定輔助技術讀到的順序，測試可用屏幕閱讀器聆聽，或檢視無障礙表示。Adobe 亦解釋，文件標籤用來識別標題、段落、表格等元素；沒有標籤時，閱讀軟件可能只能猜測。因此應沿着匯出後的成品檢查資訊，而不是只批准原始文件或預覽圖片。

在原始模板建立真正結構

應在能輸出文字和結構的來源系統製作模板，不要把整頁壓成圖片。文件標題、各部分標題及段落要有真正結構；貨品描述、數量、單價和總額應放在有清楚欄名的資料表，不靠空格排欄。畫面次序與邏輯閱讀次序要相符。如果商標旁已有文字寫出商戶名稱，毋須讓屏幕閱讀器再讀一段含糊描述；若圖片承載必要資料，匯出文件便須提供有用的替代說明。字體必須容許正確抽取實際發票用到的中文字和貨幣符號。漂亮字體若令抽取結果變成亂碼，就是功能缺陷。

雙語發票要先決定兩種語言同在一份文件，還是讓顧客選英文或繁體中文版。兩種方法都要維持連貫的閱讀次序，並為匯出的文字設定合適語言資訊。不要在表格每一行把兩種語言逐字交錯，否則語音讀出時很難理解。若生成兩份版本，金額、日期、項目編號和商戶資料須對應同一筆交易；切換語言不能悄悄改變交易內容。可行時文件中的有意義文字應可選取和搜尋。掃描圖片一般先要進行文字辨識，才談得上後續無障礙處理；Adobe 文件亦明確把掃描影像列為須先做 OCR 的情況。

檢查匯出的 PDF 成品

用安全的示例資料匯出發票：若模板支援，放入多於一項明細、折扣或附加費、較長貨品名稱，以及實際業務會用的字元。這些是測試輸入，不是捏造顧客金額。檢查 PDF 標籤和閱讀次序：商戶、發票身分、帳單資料、明細表、總額及聯絡方法，應按不用看畫面也能理解的順序出現。表格欄名須與數值相連，讀出總額時應有標籤、幣種及金額。若數字在視覺上對齊某欄，語音卻沒有上下文，讀者便難以判斷它是單價、小計還是尾數。能改來源模板時先在來源修正，再重新匯出。

W3C 指出，有標籤也不保證閱讀次序正確；版面、圖像及表格較複雜時尤其如此。文件若有連結或互動欄位，應以鍵盤巡覽；再用屏幕閱讀器聆聽，或用能顯示無障礙結構的工具檢查。對長中文描述及附幣種的金額，也要測試放大和支援的重排方式，看看文字會否被截、欄位重疊，或總額與標籤分離。自動檢查器可指出缺少標籤或屬性，卻不能判斷明細在上下文是否易懂。記下示例、實際聆聽或顯示問題、修改和重測結果；不能只因工具出現綠色總結便宣稱文件可達。

無障礙審閱旁邊，還要有算術核對。用同一份生成示例，確認各項明細、調整及顯示總額互相吻合，並檢查文字抽取後的負號、小數點和幣種仍然保留。這不是要求無障礙審閱者兼任會計，而是避免修復文件時改變交易意思。若模板容許貸項或零金額項目，可在受控示例加入一項，聆聽系統怎樣讀出。若只讀「一百」而漏掉正負號或幣種，顧客可能完全誤解應付金額。應把示例的原始數值與匯出呈現分開記錄，讓審閱者毋須依靠畫面對齊，也能逐項比較。

一個能揭示歧義的示例

假設某公司售賣兩種服務，測試發票的視覺表格整齊列出服務、數量、單價和金額，下面再有調整項及應付結餘。但用屏幕閱讀器聆聽時，系統先讀完所有服務名稱，再讀全部數字，最後讀出沒有幣種的結餘。視覺審閱者可能看不出問題；靠聆聽的顧客卻不能把價格配對服務，甚至可能付錯款。修正方法是保留 PDF 結構中的行與欄名關係，並明確標示最後結餘。之後用較長服務名稱重測，因為短示例可能掩蓋版面錯誤。這是假設驗收情境，並非某家商戶真實發票出錯的報告。

另一個選項是同時提供有結構的 HTML 發票頁及 PDF。對某些顧客，具語意標題和表格、能配合手機畫面的網頁，比複雜文件更容易使用和維護。若商戶能保持兩者數值一致，並妥善控制存取權，這可成為有用的額外途徑。但只要 PDF 仍是要求顧客使用的正式下載文件，網頁版本便不能替壞掉的 PDF 開脫。應釐清各格式用途：畫面核對、下載存檔、列印，還是提交予另一方。每個承諾提供的途徑，都用同一交易資料測試，避免無障礙改動帶來不同總額或日期。

連下載途徑一併驗收

顧客須先找到並開啟正確發票，文件標籤才有機會發揮作用。下載控制項應具體標示發票編號或訂單參考及文件種類，不要在一頁放多個完全一樣的「下載」。說明目的地是 PDF，並確保可用鍵盤到達；開啟或下載後，焦點狀態亦要讓人明白。若以電郵寄送，附件名稱應清晰，檔案不能開啟時也要有查詢方法。不可讓別人的文件經可猜到的連結流出；存取權雖是另一項測試，仍不可缺少。入口和文件是同一段顧客旅程，應一起審閱。

發票模板應有明確的發布規則，而不是承諾每一種閱讀器設定都必然完美。保存已審閱的示例 PDF，以及來源版本、語言、測試任務、所用工具和未解問題的驗收紀錄。帳單軟件、字體、模板、商標位置或貨品描述一改，就要重測。手動修好一份示例檔，不會自動修好下星期生成的發票；修正必須進入產生系統或模板。今天可先匯出一份安全而具代表性的示例，不看畫面讀出金額及明細順序，在來源處修正第一個歧義。這樣才把「PDF 看起來正常」變成顧客真正能完成的測試。

交付時也要審核檔名和文件屬性。顧客下載多張發票後，應能分辨文件，毋須逐份開啟。檔名可包含不敏感的發票參考及文件種類；不要把不必要的個人資料放進可能出現在下載紀錄或共用資料夾的名稱。若生成系統支援，PDF 文件屬性亦應有有意思的標題，並確認標題與所選語言版本一致。這些細節有助導覽和存檔，但不能取代正確標籤和閱讀次序。若示例含私人帳單資料，應使用受控測試帳戶，並只在核准的內部位置保存審閱成品。