O3noBLOG

不少人還會直接把網站的親和力（無障礙）問題和盲人朋友直接連在一起，覺得應該來解除迷思一下，盲人朋友確實是最直接會想到的，各種有身心障礙人士的族群當中，盲人朋友使用電腦上網的難度也是最高的，不過在你把眼睛矇起來體驗盲人如何操作電腦之前，有不少事情是可以先做的，隨便把腦袋裡馬上想的到的列了一下：

首先是網頁的文字內容易讀性，易讀性有分兩個面向，第一個面向大家比較清楚，就是文字排版、字形挑選、顏色對比等等視覺上的易讀程度，這部分做的好的話除了對老花眼、近視或是弱視的朋友有幫助外，一般人也會受惠；另一個面向則是文字內容好不好理解的程度，如果網站上的文字說明太難懂，那就應該要用更好理解的文字來重新講一遍，或是加上圖表輔助，或是乾脆減少資訊量，通常自己看的懂，不代表別人看的懂，所以如果是重要的說明（尤其是政府網站一些流程、辦理辦法之類的），建議都要找人看過，最簡單的是找家中長輩，因為網路上理解力較低的族群中，長輩們佔不少。

第二個是操作介面好不好操作，通常是 Web App 才有這需求，一樣有不同的面向，第一個是你的操作介面應該設計的容易理解，讓人看了也不會疑惑應該點哪裡，其中一個很重要的原則是不要破壞使用者的習慣，第二個面向是有些人可能無法好好的控制滑鼠（要模擬這個比模擬盲人的情境還要難），點擊不精確，所以永遠要保留鍵盤操作的選項，如果是使用原生的輸入元件來做操作介面的話，沒有亂做什麼奇怪的事情應該是都可以用鍵盤來控制，但是如果要自己設計一個嶄新的控制元件，那記得要好好利用 WAI-ARIA 來讓鍵盤可以順利的控制，像是 Google 的 Gmail 就有完整的鍵盤操作支援，這個應該是這篇文章當中做起來最辛苦的一項吧。

第三個是表單行為，要把表單作的好填，本身是一門很大的學問，不過在深入的思考設計表單的 usability 之前，有一些很基本的功能是應該具備的，其中特別想說的是錯誤訊息的處理，使用者送出表單後，如果後端的檢查沒過被打回來，應該要伴隨著能幫助使用者更新資料的錯誤訊息，並且正確的顯示在正確的位置，不然使用者不知道發生什麼事情，除了告訴使用者哪裡有錯之外，更進一步是讓使用者能把輸入資料改好，例如帳號名稱有格式限制的話，就要明確的說明有哪些限制，另外表單檢查不通過之後，記得也不要把使用者剛剛填的資料清空（實做這點還需要特別記得安全性問題）。

最後一個是文件結構，正確的使用 HTML 標籤，還可以輔以 WAI-ARIA 的 role 屬性，這已經是講到爛的項目了，當然 single page application 算是特殊情形，不過只要你做的頁面還是接近傳統網頁有文字內容，有主要內容的話，把網頁的文件結構弄好還是有兩大好處的：一、SEO 的部分已經好了一大半了；二、所有輔具都可以根據你的文件結構快速的帶領使用者在文件中穿梭，不用多做什麼奇怪的導盲機制。要把這塊做好算是四點當中最簡單的，只要正確的依照語意使用 HTML 標籤，不夠的再看看 WAI-ARIA 有沒有可用的 role，不要亂用標籤，然後用檢視原始碼的功能看看好不好看，如果你能開始從 HTML 原始碼中感受到美感甚至有完美的感覺出來，相信你就在正確的方向上了。

其實以上四點都有一個特色，就是把這些地方做好，不只是身心障礙人士會受惠，文字易讀性就不用說了，操控介面如果支援鍵盤，有些正常人操作起來會更得心應手，表單的訊息也是不論是怎樣的使用者都很需要，而文件結構也是，弄得好的話，大家都好找到資料，站長應該也開心。所以其實在你想要為了提升親和力而去實際模擬身心障礙人士使用電腦的情境之前，是有很多東西是可以先做的，

相信還是有人會有興趣盲人朋友怎麼操控電腦的，曾經 HappyDesigner 有邀請有聲書協會的朋友來介紹，不過已經有點久了，我去年初剛好有機會在 Moztw Lab 遇到 Fancy 示範，當時有簡單的錄下來，有興趣的朋友可以看一下：

至於要怎麼體驗盲人怎麼操作呢？如果你是用 OSX 的話，系統有內建 Voice Over，品質很好，可以直接使用，Windows 有好幾套商業軟體，至於免費的比較有名的是 NVDA，這套也是開源軟體，一開始可能需要先當明眼人練習操作，另外它講的話一開始可能會聽不太懂，聲音合成引擎和商業軟體比起來有差，多聽幾次慢慢就聽的出來再講什麼了。

2014 年的回顧終於出來了，今年比較晚主要是年底出國去玩，回來整理照片上傳就弄了好久，加上還有一堆其他事情，慢慢才找時間回顧照片，今年開始嘗試給每張照片加上一些解說。

之前介紹過 fetch 之後過了一段時間，有發現幾個目前 spec 上的一些細節要來分享一下。首先是上一篇文章說到的重複 header 的問題，詳細看下去後，發現 fetch 收的 header 參數有兩種，一個是 key value pair 的原生物件，另外一種是 Headers 物件，這個物件是 fetch spec 裡面新定義的：

var h = new Headers();
h.append('X-Custom-Header', '1');
h.append('X-Custom-Header', '2');
h.append('X-Custom-Header', '3');

就可以像這樣用append重複加上同樣名稱的 Header，其實丟原生的物件進去，也會在內部被轉成這個 Header 物件。

第二個要說的是關於回應 status code 在 400 到 600 之間時，Promise 物件是 resolve 不是 reject，理由是 Error 和 Exception 不一樣，不過有人開 Issue 在討論，會不會有改變還不知道，倒是如果現在用 github polyfill 想要處理這個問題的話，除了可以自己處理之外，也有人寫了 fetchres 這個，wrapper 可以把 fetch 的一些行為弄得更接近大部分開發者的直覺，目前提供的功能除了這個之外，還有一個是如果回傳的 type 是 JSON，但是內容的 JSON 語法有錯，那也會被丟到 reject 那邊去。

這次去東京還去了東京迪士尼樂園玩了一天，先直接說一下結論，去的那天遇到高中生開始放假，在車站有點嚇到，還好沒影響很大，大約開場前 20 分到場排隊（7:40），到要關門才離開，看了三場遊行，平常就有的日間和夜間加上聖誕節特別遊行，然後還看到煙火和 Once Upon a Time，而且有抽到中央的觀賞位，遊樂設施的部分玩到 11 個，其中八個 FastPass 的設施玩到了 6 個，整體下來我覺得算蠻值得的了（以下圖多）。

這次去東京其中一個目標就是去拍東京車站，拍東京車站其實就兩個點，丸之內大樓和新丸之內大樓，因為據說新丸之內大樓景比較漂亮，所以就先過去新丸，結果不知道為什麼超多人的。

今天遇到一個問題是，本來好好的全螢幕影片播放功能，到了 Android L 的 Facebook App 裡的 webview 瀏覽器就壞掉了，而且透過開發工具看沒有錯誤訊息出來，查了一陣子終於發現，最新的 webview 改成使用 Chrome 核心後，有些 API 雖然 Chrome 有支援，但是在 WebView 裡面是沒開啟的。

其實我本來已經有用 feature detection 的寫法了，不過這個情形實際上，requestFullscreen是找的到，可以執行，也不會有錯誤的，只是就是什麼事情都不會發生，後來才 發現 是要用document.fullscreenEnabled來做判斷，這個東西我之前一直覺得在手機上都用不到的東西（桌面瀏覽器通常會先問使用者是否願意讓網頁進入全螢幕），沒想到會在這邊派上用場啊。