Tkinterをもう一度使いやすくする: 書きやすさとアクセシビリティ
Tkinterは標準ライブラリに含まれ、すぐにGUIが書けることは、長くPythonの魅力の一つでした。しかし視覚障害のあるPythonユーザーや開発者にとって、Tkinterはスクリーンリーダーから利用しづらいGUIフレームワークでした。私はその課題を見てきました。
その状況が変わろうとしています。Tkinterが依存するTcl/Tk開発版ではスクリーンリーダー対応が進められています。私はPyCon JP 2025のスプリントリーダーとしてこれを確認し、現在もWindowsビルドを含め検証を続けています。これをPythonへ取り込む作業はCPythonのissueとして進行中で、標準ウィジェットが支援技術から利用できる日が近づいています。
一方で、見栄えを改善するために独自描画を行うGUI実装も広まっています。せっかく整備される基盤を活かし、アクセシブルなGUIを書きやすくする方法を考えています。
Tkinterが使いにくい理由を、見た目でなく書き方から捉え直してはどうでしょう。GUIウィジェットをPythonクラスとして扱うことは自然に見えますが、本当にそれが書きやすい設計なのでしょうか。「部品を登録し、実行はフレームワークに任せる」近年のPythonの流れと比べると、Tkinterの書き方は認知負荷が高く感じられる面があります。書きやすさとアクセシビリティは、別々の問題に見えて、つながっているのではないでしょうか。
この問題意識から、私は実験的フレームワークnextpytkを作っています。デコレータでウィジェットを登録し、状態の更新を宣言的に記述する部分は、すでに動作しています。狙いは、この書き方をアクセシブルなカスタムウィジェット実装にまで広げることです。Tkinterを、書きやすく、アクセシブルなGUI基盤として使い続ける道を探ります。
Tell us about your own experience with this topic
私は2011年のPyCon mini JPからPythonコミュニティに関わり、以来NVDA日本語版の開発と運用、スクリーンリーダー対応、アクセシビリティ検証を続けてきました。Tkinter GUIが支援技術から利用しづらい問題も見てきました。
また、私はPythonに出会う前にTcl/Tkに触れ、その魅力も知っています。Tkinterを捨てるのではなく、アクセシブルにしたうえで使い続けられる形にしたいと考えています。
PyCon JP 2025の開発スプリントでは、スプリントリーダーとしてPython GUI Accessibilityをテーマに、Tk開発版のスクリーンリーダー対応を検証しました。その後、Windowsビルドでも基本動作を確認しています。その発展としてnextpytkを作り、PyPIに初期版を登録しました。デコレータによるウィジェット登録と宣言的レイアウト記述はすでに動き、勉強会で実演しました。
現在は、実用アプリを開発しながらnextpytkの機能を追加し、Tkのリリース状況やCPython issueを追っています。
What discussions can you have with attendees through this talk?
参加者とは、Tkinterを使った経験、あるいは避けてきた理由を話したいです。標準ライブラリでGUIを書ける魅力がありながら、なぜ多くのPython開発者はCLI、Web、他のGUIフレームワークへ向かったのか。見た目、書き方、機能、性能、学習コスト、アクセシビリティなど、どこに難しさがあったのかを聞きたいです。
また、Tkinterの使いにくさは、見た目だけでなく書き方のパラダイムにも関係しているのではないかと考えています。GUIウィジェットをPythonクラスとして扱う設計と、部品や状態更新を登録してフレームワークに任せる設計。学習者や実務開発者は、どう使い分けるべきでしょうか。
Tcl/Tkのアクセシビリティ対応が進むこの時期に、書きやすさ、見栄え、標準ウィジェットのアクセシビリティをどう両立させるかを議論したいです。
株式会社シュアルタ代表。2010年頃からオープンソースのスクリーンリーダーNVDAの日本語化に参加。2012年から2022年までNVDA日本語チーム代表。PyCon mini Hiroshima や「すごい広島 with Python」などを開催。2024年から Python Boot Camp の運営にも参加。ウェブアクセシビリティ基盤委員会 WG2 主査。PyCon JP 2025 座長。