我認為你第一次看到我的工作間肯定這樣想 —— “總感覺少些什麼”。沒有顯示器和滑鼠，卻有個人敲打著鍵盤，不知注視著哪裡。
這就是我，我同事可以證明我沒問題。我是位於坦佩雷（芬蘭西南部一座城市）的 Vincit 寫字樓中的一名軟體開發者。我雙目失明。這篇文章中我將講述有關我工作中的事情。
你真的什麼都看不到嗎？
準確來說，我覺察到陽光和其他明亮的光線，不過也僅限這些。其實，這對我的工作也並沒有什麼幫助。
你工作內容是什麼？
和大部分人一樣：忙時寫程式碼，閒時和同事吹逼。我做全棧專案，主攻後端。兼職訪問顧問 – 或稱監管，隨你如何稱呼。
你如何使用電腦？
我用的電腦是一臺執行 Windows 10 的普通筆記本。是其中的軟體讓一切變得神奇。我使用一款叫做螢幕閱讀器的程式來訪問電腦。螢幕閱讀器監聽螢幕上的變化並通過盲文（需要單獨的盲文裝置）或合成的聲音來展示給使用者。這並不是你如今聽到的各種智慧助理的合成聲音。我使用一種機械聲音，每分鐘能說 450 個單詞。相比較而言，英語正常語速每分鐘 120-150 個單詞。我有一個怪癖：我既說英語也說芬蘭語，我用芬蘭語合成器讀英語，因為老舊的螢幕閱讀器在語言之間切換不夠智慧，所以我習慣這樣做。下面是個例子是閱讀這個段落，我能聽懂。
https://www.vincit.fi/wp-content/uploads/2017/08/mpsample.mp3?_=1
下面是英語合成器發出的聲音：
https://www.vincit.fi/wp-content/uploads/2017/08/essample.mp3?_=2
滑鼠對於我來說並不是非常有用，所以我僅僅通過鍵盤工作。在座的各位應該十分熟悉我用到的命令：方向鍵和 tab 鍵控制視窗內的移動，alt+tab 切換視窗等等。螢幕閱讀器也有很多自己的快捷鍵，比如閱讀活動視窗的不同區域或開關一些功能特性。
有趣的是閱讀網頁和其他格式化文件。你看，螢幕閱讀器分塊呈現資訊。每一塊可能是一行，也可能是一個單詞、一個字母，亦或是文字的片段。舉個例子，我在網頁中按向下的方向鍵，我聽到頁面的下一行。我並不能像正常人一樣用眼睛從螢幕上閱讀內容。相反，我聽到一塊一塊的內容，或跳過我不感興趣的部分。
語音或盲文並不能描繪出視窗的顯示佈局。資訊以線性方式呈現給我。如果你把網頁複製貼上進記事本，你就能明白我看到的網頁是什麼樣子的。就是剝離大部分格式的多行文字。然而螢幕閱讀器可以獲取網頁上的 HTML 語法，所以我也能知道超連結、標題、表單等等。事實上，如果非核取方塊元素展示成核取方塊樣式，我並不能知道這是核取方塊。我之後將寫一篇文章詳細講述這些內容，記住我剛剛舉的是個“反人類”例子。 （譯者注：突然感到自責和羞愧，深深明白了一個道理：不要用各種有含意義的傳統標籤 hack 佈局和樣式，也不要因為 css 的強大而懶得使用各種有含義的傳統標籤。共勉）
我花費大量時間工作在命令列上。事實上我通常用瀏覽器和編輯器，很少用其他圖形應用程式。相比那些為滑鼠使用者打造的圖形介面，我發現用命令列處理手邊的工作更加高效。
既然我如此熱愛命令列，為什麼我卻要選擇 Windows 這個並不以命令列出名的作業系統呢？答案很簡單：Windows 是最方便的作業系統。NVDA是我所選擇的螢幕閱讀器，它是開源的並且維護比其他閱讀器更頻繁。如果上天再我一次機會，我可能會選 Mac 系統，因為我認為它是易用性和功能性平衡的典範。不幸的是 Mac 系統上的螢幕閱讀器 VoiceOver 經歷了漫長的釋出週期從而被遺忘，並且它的導航模型和我獨特的工作方式並不協調。當然這裡也有一個 Gnome 桌面上的螢幕閱讀器，雖然使用者很少，依然被很好地維護著，不過還有一些不完善的地方和我日常工作不協調。所以，我選擇 Windows。由 GNU 誕生的 Git Bash 和其他命令列工具彌補了 Windows 內建命令列的缺陷。
你如何寫程式碼？
我花費好長時間才明白為什麼大家覺得這個問題是個很高深的問題。記得我上面說過一行一行地閱讀文字嗎？我也是通過這種方式讀程式碼。通常我會跳過無用的行，或僅聽半行來獲取內容，但當我需要知道完整資訊的時候，我不得不像讀小說一樣讀完所有東西。我當然無法閱讀整個程式碼庫。這種情況下我會在腦中抽象一部分程式碼：這個元件輸入 x 返回 y，並不用關心細節邏輯。
這種閱讀方式讓我和正常同事的工作方式有些區別。舉個例子，當程式碼審查時，我喜歡看原始 diff 輸出，並列視窗顯示 diff 對我並不適用，而且還容易讓人分心。有修改的程式碼行上用符號 + 和 – 比用不同背景色標註也要好太多，並不是因為我不能獲知顏色名字，而是因為在新增的一行中，讀“加”這個字比讀“帶複雜陰影的高亮紅色”用更短的時間。（嘿，我說你呢 Gerrit (一款程式碼審查工具)）
你或許會認為縮排和其他程式碼格式和我無關，因為都是基本的視覺問題。並不是這樣，正確的縮排對我的幫助和正常開發者一樣。當我用盲文（比語音更加高效）讀程式碼時，我像其他正常程式設計師一樣清楚程式碼結構。當我進入一段有縮排或無縮排的程式碼時，我也會得到語音提醒。這些資訊幫助我在腦中描繪程式碼結構。事實上我學的第一門語言就是 Python （PHP 不算），它強制使用程式碼縮排，這對我來說並不是問題。我有眾多理由來強烈建議使用整潔統一的程式碼風格，其中之一就是不要讓我的生活變得更加艱難了，好嗎。
你喜歡哪款編輯器？
劇透一下：這個答案並不是以 V 或者 E 開頭（我雖然通過命令列用 Vim 來寫 git commit 資訊和其他備註。我認為我在這場聖戰中是中立的）（譯者注：Vim 和 Emacs 梗）一年前我認為 Notepad++ 最棒，它是輕量級的做工精細的文字編輯器。然而一年前我還沒有接觸大規模 Java 專案，當我接觸這種專案時，意味著我應該在 Notepad++ 和理智之間做個選擇。最後我選擇理智，拋棄 Notepad++ 轉投 IntelliJ IDEA 的懷抱。從那之後 IntelliJ IDEA 便是我首選編輯器。我曾對各種 IDE 有深深怨念，它們大多數在純鍵盤流操作下麻煩又低效。如果我視力沒問題，我肯定早就跳到 IDE 陣營了。
但你可能會問，為什麼當初選 Notepad++。還有其他很多更先進的輕量級編輯器，比如 Sublime 或 Atom。原因很簡單：螢幕閱讀器無法訪問它們。Vim 一類的文字編輯器也是如此，我使用的螢幕閱讀器對命令列程式的支援有問題，在這些編輯器上無法處理多於 commit 資訊的文字。很遺憾，可用性決定了我能夠使用的工具。即使我不能高效工作，也不是什麼大問題。
你編寫過前端程式碼嗎？
你應該認為前端開發和視覺有關，註定與盲人程式設計師無緣。基本上是這樣。我從來不自己做概念原型，我做都是有介面，需要隨後加入功能的專案。
然而，我也做過 Angular 和 React 工作任務。怎麼會這樣？如今很多 APP 基於瀏覽器。舉個例子，我曾花費兩週時間為一個 Angular APP 增加國際化支援。我並不需要做任何視覺上的改動。
我發現對於我這類開發者開說，像 Bootstrap 這類的庫簡直是上天的禮物。正因為柵格系統（Bootstrap的響應式佈局解決方案），我可以自己構建一個粗糙的介面。儘管如此，我做的有關介面的改動在呈現給使用者之前仍然要有一雙眼睛檢查。所以，總而言之，我可以在一定程度上做些前端開發，至少不是和表現層太相關。
有什麼其他沒有提到的東西？
其實這篇文章有很多東西沒有表達出來。正如上文所承諾，我將全力以赴寫一篇文章，有關製作易訪問網頁的藝術，因為一言未盡是我討厭的事情之一。我不會半途而廢的，敬請期待。
打賞支援我翻譯更多好文章，謝謝！
打賞譯者
打賞支援我翻譯更多好文章，謝謝！
任選一種支付方式
