プレスリリースの全文は、OSI Webサイトで入手できます。 また、提起された問題についていくつかの技術的な明確化を行うことは理にかなっています。なぜなら、このトピックの特異性のために、非視覚的アクセス技術にあまり親しんでいないが意思決定者である人々の意思決定者であるという誤解のリスクがあるからです。
初期教育プログラム
まず第一に、ビジョンを使用せずにコンピューターで作業することが可能であり、ロシアを含む通常の慣行であるという事実に注意する必要があります。 同時に、完全に視覚障害のあるユーザーの作業は、特別に作成された作業環境だけでなく、オペレーティングシステムの標準インターフェイスおよび標準アプリケーションでも可能です。多くの場合、平均的な目の見える人のパフォーマンスに匹敵します（ただし、非視覚的な作業の生産性は別の大きな問題ですが、現在のトピックの範囲外）。
さらに、視覚障害者の深刻な職業活動について話している場合、通常、バックグラウンドで実行され、画面上の情報を別の形式で提供する補助ソフトウェアを使用するだけで、一般的な作業環境を使用することにより、最大限の効率が正確に達成されます：音声ストリームまたは触覚ディスプレイにテキストを表示します。
コンピューターでの非視覚的作業の原則に関する詳細は、 Habrahabrの対応する記事に記載されています 。 ここで、私たちは、視覚障害者の職業上の仕事の文脈での代替作業環境の開発についての話は一般的に受け入れられず、それらの失敗は業界全体の発展の歴史によって証明されているため、この問題を提起することさえできないことを強調します。
誰にとっても問題の関連性
プログラムインターフェース、特に1C環境の非視覚的な可用性の問題は、決して大げさではありません。
残念なことに、現代の世界では身体の視覚機能への負荷が何倍も増加しているため、医学の開発にもかかわらず、視力に問題のある人の数は反対に増加しています。 これは、視力の低下または完全な喪失により、毎年リハビリテーションを必要とする人々の数の増加につながります。 さらに、家庭だけでなく専門的なリハビリテーションも含まれます。
州レベルでは、この問題は認識されており、それを解決する1つの方法は、障害を持つ人々の仕事を引用することです。 つまり、州は障害のある人をその州に雇用することを会社に義務付けています（違反の種類は区別されていませんが、参考として、視覚障害のある人の総質量に対する割合は約8％です）。 ある程度まで、高い職業レベルで働くことができる障害のある人々に対する満たされていない需要があるとさえ主張することができます。
視覚障害者向けのプロフェッショナルソフトウェアが利用できないことは、この問題の解決を妨げて、3人のすべての関係者に利益をもたらす要因の1つです。
- 就職を希望する障害者。
- 社会的機能を果たすことを目指している州。
- 有能で効果的な従業員を獲得したい組織。
ロシアおよび多くの地域の個々のCIS諸国向けの1Cソフトウェアパッケージは、事実上の事実上の標準であるため、特定された問題のコンテキストでの可用性の問題は非常に深刻です。
技術的アプローチ
OSIの会長による前述のアピールには、次のフレーズがあります。
... 1Cプログラム（バージョン8）と非ビジュアルスクリーンアクセスプログラム（JawsおよびNVDA）との互換性を確保する問題を解決する必要があります。 暫定的な見積もりによると、この改訂では多大な時間と材料コストは不要であり、この問題を共同で解決するために盲目のプログラマを引き付ける準備ができています。」
これは単なるプレスリリースであるという事実を割り引くべきであり、この情報を行動の指針として受け取らないでください。
まず、JAWSとNVDAはソフトウェアをサポートする特殊なケースですが、最も一般的なものです。 ただし、それらに加えて、ロシア市場には現在でもさらに2つのソリューション（COBRAおよびSuperNova）があり、近い将来、3番目（Window-Eyes）も表示されるはずです。
第二に、アプリケーションのアクセシビリティをより低いレベルで実装する方がより適切であり、場合によっては補助ソフトウェアのレベルまで上昇します。
実際には2つのレベルがあります。
- オペレーティングシステムに実装されているアクセシビリティAPIのレベル。
- スクリーンアクセスプログラムレベル（各プログラムには独自の実装があります）。
また、画面アクセスプログラムレベルは次のように分類することもできます。
- 任意のアプリケーションがそれとやり取りできるScreen Access API。
- スクリーンアクセスプログラム内のモジュール。これは、アプリケーションと対話するための特定のオプションを実装するために特別に記述されたプラグインの一種であり、その可用性が保証されています。
したがって、アプリケーションの可用性を実装するには3つのアプローチがあります。 確かに、彼らはしばしばお互いに流れます。
問題を解決するためのオプション
上記に基づいて、アプリケーションの可用性を実装するための次の戦略を区別できます。
I.プログラムを一般的なシステムアクセシビリティAPIに適合させる
この分野では、開発者は、アクセシビリティと特別なAPIの一般的な技術的推奨事項を使用してグラフィカルインターフェイスを完成させる必要があります。Windowsの場合、一般的に、これはMicrosoft Active Accessibilityおよびより最新のMicrosoft UIオートメーションです。
アプリケーションインターフェイスが個別の環境またはフレームワークを使用して設計されている場合、通常は、Java用のJava Access BridgeやQt用のQAccessibleInterfaceなどの独自のテクノロジがあります。
ルールとして、開発者がフロントエンドフレームワークまたはカスタムクラスを使用すると、知らないうちにアクセシビリティ機能が失われる場合に問題が発生します。これは、標準要素を使用して一般的なルールによってWindowsでインターフェイスを構築する場合、その可用性は通常深刻な問題を引き起こさないためです
これは、すべての画面アクセスプログラムに即座に、つまりユニバーサルアクセシビリティを提供するため、優れた戦略です。
II。 特定のスクリーンアクセスプログラムへのアプリケーションの適合
この分野では、開発者は、特定のスクリーンアクセスプログラムのAPIを介して関連情報の転送を実装するという事実に焦点を当てています。 これは、スクリーンアクセスプログラムの製造元から提供されたdllを使用するか、スクリーンアクセスプログラムに属するOLEオートメーションオブジェクトを呼び出すかのいずれかです。
問題は、すべてのスクリーンアクセスプログラムのAPIが異なるため、それぞれのアプリケーションの可用性を強化する必要があることです。 さらに、APIの機能も異なります。たとえば、音声メッセージとデータ出力の両方の触覚ディスプレイへの送信を開始できる場所もありますが、音声メッセージのみの場合もあります。
さらに、豊富なインターフェイスの可用性を確保しながら、スクリーンアクセスプログラムの機能APIを非常に多く使用することは、非常に不便で効率が低いです。 一般に、これはかなり悪い習慣であり、一部の特定の場合にのみ正当化され、小さなローカル問題を解決するために行われます。
III。 スクリーンアクセスプログラム用のモジュールの開発
このアプローチでは、可用性が保証されている元のアプリケーションはまったく変更されない可能性があります。 作業は、純粋に画面アクセスプログラムのレベルで実行されます。
深刻なスクリーンアクセスプログラムにはカスタマイズ機能があり、特定のアプリケーションのインターフェイス要素を処理する特定のロジックを実装する特定のスクリプトまたはプラグインを開発できます。 伝統的に、これは問題に対する最も一般的な解決策ですが、これが最良であることを意味するものではありません。
その普及率は、アプリケーションの開発者に修正の必要性を説得するよりも、別のスクリーンアクセスプログラム用のモジュールを開発する方が簡単な場合が多いという事実によってのみ説明されています。 つまり、これはアプリケーション開発者と協力する必要なしに利用できる唯一のオプションです。
確かに、開発者の支援なしにアクセシビリティの問題を完全に解決できるとは限りません。 インターフェースは、原則として、視覚的なチャネル以外のデータを受信する機能を提供しない場合があります。 特に、ウイルス対策開発者は、偶然または万が一、アクセシビリティAPIを強制終了することにより、このエラーを犯すことがよくあります。 このような場合、アプリケーション開発者は、システムフォーカスやウィンドウイベントの位置など、一部のAPIに必要なデータを提供するという形で、少なくとも最小限の支援が必要です。
原則として、モジュールはスクリーンアクセスプログラムの開発者によって作成されます。非常に普及しているアプリケーションに関しては、たとえばMicrosoft Officeなど、独立したプログラマーによって、スクリーンベースのプログラムのユーザーであり、独自のタスクを解決します。またはアプリ開発者が雇った外部委託プログラマー。
明確にするために、視覚障害者によって識別されるテキスト署名を持たないグラフィックボタンのアクセシビリティの実装を使用した簡単な例を考えてみましょう。
- 戦略I：アプリケーションインターフェイスのボタン要素にテキストラベルを追加し、すべての画面アクセスプログラムのアクセシビリティを確保します。
- 戦略II：プログラム開発者XのDLLをアプリケーションのパッケージに追加し、システムフォーカスが署名されていないボタンにある場合、DLLを介して、テキストラベルを発音するコマンドを画面アクセスプログラムに渡します。 スクリーンアクセスプログラムYのユーザーがサポートを求めた場合、このプログラムに同様のスキームを実装するか、プログラムXに切り替えるようにアドバイスしますが、彼はこれに満足する可能性は低いでしょう。
- 戦略III：Xスクリーンアクセスプログラムのモジュールを作成する有能なスペシャリストに同意するか、署名のないボタンがフォーカスされた場合にテキストラベルを発音するプラグインを開発するスペシャリストを育成します。 プログラムYのユーザーがサポートに連絡する場合、戦略IIと同様です。
これらは3つの基本的な戦略ですが、それらのさまざまな組み合わせや、より洗練された方法もあります。
アプリケーションの可用性を実現するための最適な戦略を選択するという問題はしばしば議論の余地がありますが、一般的な場合、戦略I、つまりシステム全体のAPIを介したユニバーサルパスを優先することは理にかなっていると言えます。 戦略IIは一般に大規模プロジェクトの場合は効果がなく、戦略IIIは原則として一種の妥協であり、さらに戦略Iが完全に実装されたときにユーザビリティを向上させるために使用できます。