Mozilla/Gecko Keyboard Navigation Proposal を和訳する-9

さてこの文書も、もう少しで草稿のための翻訳が完了するところまで来ました。やれやれと思いますが、キーの割付という比較的イメージし易い内容なので、特に難解な文書ではないと思います。事実翻訳の方も、キーを動かして文書の内容を理解しながら進めることができるいので、ありがたいです。しかしながら、問題点があればご指摘いただければ、さらにうれしい限りです。

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

VIII. Unresolved Issues

1. How to access fixed/floating widget using keyboard?
Some widgets (most of them are ads) can be put anywhere in the web page by specifying the absolute position attribute in CSS style. Their physical position may be very different from their logical position.
NOTE: We didn't find anything in Web Content Accessibility Guidelines 2.0 discussing using fixed/floating widget in web pages.

VIII. 未解決の問題点

1. 固定されたり、動いていたりするウィジェットにキーボードを使ってアクセスする方法は？
ウィジェットには（広告が多いですが）CSS の絶対位置属性を決めて、ウェブページのどこかの場所に置かれるものもあります。その場合、物理的位置と論理的位置には大きな乖離が存在することもあります。
注記：この件に関して、固定されたり、動いていたりするウェブページのウィジェットの使用について論じている、ウェブコンテンツのアクセシビリティ手引き 2.0　には何も記載がりません

IX. Differences Between Caret Browsing Mode and Non-Caret Browsing Mode
Behaviors that are different in caret browsing mode and non-caret browsing mode

IX. キャレット検索モードとキャレットなし検索モードの相違点
キャレット検索モードとキャレットなし検索モードにおける異なる動き

→以下は表の項目の翻訳です。表としての体裁は末尾のリンクでご確認ください。
key bindings
caret browsing mode
non caret browsing mode
<(left/right)>
move caret one character left/right scroll page left/right (if the content has horizontal scrollbar)
<(up/down)>
move the caret one line up/down scroll page up/down (if the content has vertical scrollbar)
<(home/end)>
move the caret to the beginning/end of the current line. scroll to the beginning/end of the content.

キー割付
キャレット検索モード
キャレットなし検索モード
<左/右>
キャレットを一文字左/右へ移動させる （もしコンテンツが水平スクロールバーを備えていれば）ページを左/右へ移動させる
<上/下>
キャレットを一行上/下へ移動させる （もしコンテンツが縦のスクロールバーを備えていれば）ページを上/下にスクロールする
<(home/end)>
現在キャレットのある行の最初/最後へキャレットを移動させる 現在のコンテンツの最初/最後へスクロールする

Behaviors that are only available in caret browsing mode

key bindings behavior
<(ctrl+left/right)> move the caret one word left/right
<(alt+[/])>
put the caret out of form control

キャレット検索モードでのみ可能な動き

キー割付 動き
<(ctrl+左/右)> キャレットを一単語左/右へ移動させる
<(alt+[/])>
キャレットを制御から外す


X. Item-oriented Navigation using Javascript Component

Instead of using up/down arrows to navigate by line which is a visual based navigation, there is another navigation mechanism called "item-oriented navigation" can be used for content based navigation. A paragraph, a table cell, a form control, a select menu item, a list item can be defined as an item or the minimal unit of navigation. Arrow keys, as well as the combination of ctrl/shift/alt and arrow keys, will navigate the content based on those items, rather than character by character or line by line in the caret browsing mode. <(ctrl+F7)> is designed for switching between those two mode.

X. JavaScript 部品を使用するアイテム指向の操作

目で見て分かる操作である上/下矢印キーを使用した行ごとの操作ではなく、別の操作方法が存在し、それはコンテンツの操作に使われる「アイテム指向の操作」と呼ばれます。そこでは、段落(p)、表のセル、フォームコントロール、選択メニュアイテム、リストアイテムが、1つのアイテム、すなわち操作の最小単位として定義されます。矢印キーも、ctrl/shift/alt と矢印キーとの組合も、これらのアイテムをキャレット検索モードで、文字や行ごとに操作するのではなく、コンテンツ単位の操作をします。そして、<(ctrl+F7)> はこれら2つのモードを切り替えるように設計されています。

Since javascript is a convenient language for writing mozilla extension, the item-oriented navigation can be implemented as a javascript component. The advantages of doing that are:

* Avoid the complicate hacking work in Gecko and potential regression
* Easily hook up the keyboard event
* Fully configurable & modifiable
* Avoid the versioning and API changes issues
* Platform independent

The detail key binding schema for item-oriented navigation is still under design discussion. We'll list them in another document.
(no plan in the near future, need more discussion.)



Javascript は Mozilla の拡張機能を書くのに便利な言語なので、アイテム指向の操作は Javascript 部品として実装されることが可能です。その利点は:

* Gecko での複雑なプログラミング技術の使用や見直し作業を回避する
* キーボードのイベントに関連づけるのが簡単
* 全面的設定のやり直しや大きな変更ができる
* バージョン管理や API の変更の問題を回避できる
* プラットフォームに左右されない

アイテム指向の操作に対する詳細のキー割付プランは現在なお設計を議論している段階です。別の文書に一覧を作成します。
(すぐに実現はされずに、議論がもっと必要です。)

本日までの翻訳部分です。
See you (^-^)/~~~~ tomorrow.

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-8

アツイナモシ・・・・デモ今日モマタゾ！

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

V. Keyboard Navigation in a Client-side Image Map

* <(tab)>/<(shift+tab)> moves focus between each area of a client-side image map.
* <(space/enter)> has the same effect as mouse clicking on the focused map area.
* No keyboard navigation available for server-side image maps. Web authors shall avoid using it.

Status of Client-side Image Map Navigation work: Completed.

V. クライアント側のイメージマップにおけるキーボード操作

* <(tab)>/<(shift+tab)> キーはクライアント側のイメージマップの領域から領域へ各々フォーカスを移動させます。
* <(space/enter)> キーではフォーカスのあるイメージマップの領域をマウスでクリックするのと同じ効果を得られます。
* サーバー側のイメージマップをキーボード操作できません。ウェブの作者はそれをしてはいけません。

クライアント側のイメージマップ機能の状況: バグ修正済みです。

VI. Keyboard Navigation into/out-of Plugins (and also Java[TM] Applets)

* <(tab)>/<(shift+tab)> moves focus among the focusable widgets, including plugins, users should be able to <(tab)> into plugin and <(tab)> out of plugin.

VI. プラグインへの出入りにおけるキーボード操作（Java[TM] アプレットも含む）

* <(tab)>/<(shift+tab)> キーはプラグインも含め、フォーカス可能なウィジェット間でフォーカスを移動させます。ユーザは <(tab)> を使ってプラグインをフォーカスしたり、プラグインからフォーカスを外すことができるはずです。

# Once the focus is inside plugin, the keyboard events will go there, plugins may have their own key binding.
# Keys that the plugin doesn't need should get bubbled up to the browser. For example, most plugins should allow alt+left/alt+right through to the browser for history navigation.

# フォーカスがプラグインにあると、キーボードイベントがプラグインで有効になります。プラグインが自分自身のキー割付を備えることもできます。
# プラグインにとって不要なキーはブザウザへバブルアップされます。例えば、ほとんどのプラグインでは、alt+left/alt+right　を使ってブラウザに対して履歴を検索できるはずです。

NOTE: To support this, both mozilla & plugin need to implement xembed protocol. So far, only Java plugin (above 1.5) and Helix plugin implemented xembed. It will be great if Flash and Acrobat reader also have this feature.

Status of Plugin Navigation work: <(tab)> and <(shift+tab)> will move the focus into the plugin/applet, but there is no way to move it out. Bug to be filed in bugzilla.mozilla.org.

注記：この機能をサポートするには、mozilla & plugin は xembed プロトコルを実装する必要があります。いまのところ、Java(1.5 以上) プラグインと　Helix　プラグインだけが　xembed を実装しています。Flash と Acrobat reader もこの機能を備えることができれば、それはすばらしいことです。

プラグイン操作機能の状況: <(tab)> および <(shift+tab)> キーはフォーカスを plugin/applet へ移動させますが、フォーカスを外すことができません。bugzilla.mozilla.org. にバグが登録されます。

VII. Keyboard Navigation in a Sample Web Page

It is useful to examine how this proposal would work on a sample web page. For our examination we have chosen http://www.sun.com

The whole page is in a table. Turn on caret browsing mode by pressing <(F7)>, you can navigate the context using the following ways:


VII. サンプルウエブページにおけるキーボード操作

この提案がどのようにウェブページに効果を及ぼすかをサンプルで調べることは意味があります。 調査用に http://www.sun.com を選んでみました

全ページが表に収まっています。<(F7)> を押すことで、キャレット移動モードを有効にしてください。すると以下に上げる方法でコンテキストを操作できます:

Using arrow key navigation: Pressing <(right)>, the caret will move right, character by character, Press <(down)> the caret will move down, line by line.

矢印キーによる操作を使用する: <右> を押す。するとキャレットは一文字ずづ右へ移動します。<下> を押すと、キャレット一行ずづ下へ移動します。

Using focus/TAB navigation: Focus can be moved along all links and form controls by using <tab>: "How to buy" -> "My Sun" -> "text input" -> "input image button (>>)" -> "Products & Services" -> ... ->"Low Cost Computing" -> "Making connections in Greece" -> "Affordable,..." -> "HP's Problem" -> "Sun Wins StarOffice Deal in Australia“ -> "Find It Fast" -> "Solaris Preview" -> "Sun Java Desktop System" -> "Sun Fire V40z" -> "Get Java Technology For Free" -> "see all features" -> "see all promotions" -> "Contact" -> ... -> "Trademarks".

フォーカス/TAB 操作を使う：<tab>: を使うことで、リンク制御やフォーム制御すべてをフォーカスが移動できます: "How to buy" -> "My Sun" -> "text input" -> "input image button (>>)" -> "Products & Services" -> ... ->"Low Cost Computing" -> "Making connections in Greece" -> "Affordable,..." -> "HP's Problem" -> "Sun Wins StarOffice Deal in Australia“ -> "Find It Fast" -> "Solaris Preview" -> "Sun Java Desktop System" -> "Sun Fire V40z" -> "Get Java Technology For Free" -> "see all features" -> "see all promotions" -> "Contact" -> ... -> "Trademarks".

Form control navigation: Press <(right)>, the caret will move right, character by character, after "sun.com How To Buy | My Sun | Worldwide Sites", the input box will be focused, you can type something into it, and press <(alt+])>, the caret will be after the input box, press <(right)> some times, the ">>" button will be focus. Press <(enter)>, your search will be submitted.

フォーム制御操作：<右> を押します。するとキャレットが一文字ずつ右へ移動し、"sun.com How To Buy | My Sun | Worldwide Sites" の後で、インプットボックスがフォーカスされます。何か入力して <(alt+])> を押すと、キャレットは input box のあとに移動し、<右> を数回押すと、">>" ボタンがフォーカスされます。<(enter)> を押すと、検索内容が送られます。

ニナリタカッタノブハ、ケッキョクシマシタ・・・・・・・・・・・・・・・・・・・・ショックニマケズ、ニモマケズ、ヒタスラホンヤクヘトマイモドルノデシタ・・・・・・・・・・・・・・・・オシマイ

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-7

ほんまに暑いおますな。

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

IV. Form Control Navigation
Move into and out-of form Controls

When the caret is moved into a form control, this form control should be automatically focused. In the mean time, all keyboard events are captured by this form control. <(alt+[/])> is designed for leaving the form control and back to the "caret browsing" mode. <(alt+])> moves the caret to the position that next to the current control (move forward); <(alt+[)> moves the caret to the position that previous to the current control (move backward).
(We're using alt+[/] for this purpose now, but for a long-term we'll change the keybinding. Need more discussion.)

IV. フォーム制御の操作
フォーム制御への移動やフォーム制御からの移動

キャレットがフォーム制御へ移動する時、フォーム制御は自動的にフォーカスされます。その間、すべてのキーボードイベントはこのフォーム制御に捕そくされます。 <(alt+[/])>キーはフォーム制御を離れキャレット検索モードへ戻ります。 <(alt+])> キーはキャレットを現在の制御の次の位置へ移動させます(前進）； <(alt+[)> キーはキャレットを現在の制御の前の位置へ移動させます(後退）。
(alt+[/] はこのように使用されていますが、長期的に見てキー結合を変更するつもりです。もうすこし議論が必要です。)

For example, when you moved the caret beyond the "t" of "input", you entered the input box, then you can start typing in the input box. When finished, press <alt+]> makes the input box lose focus and put caret after the input box, then you can continue moving the caret using <left>, <right> etc. Press <alt+[> makes the input box lose focus and put caret before the input box (i.e. after the "t" of "input").

input <input id="q" name="q" accesskey="s" size="30" type="text">


たとえば、キャレットを"input" の "t" 次に移動させた時、下記のの input box へ入り、そこでタイプを始めることが可能です。打ち終わった時、 <alt+]> を押すと input box はフォーカスを失い、キャレットを input box の先に移動させます。すると、<左>、<右>キーなどを使って、キャレットの移動を継続できます。<alt+[>を押すと、 input box はフォーカスを失いキャレットを input box の前に持ってきます（つまり、"input" の "t" 直後です）。

input <input id="q" name="q" accesskey="s" size="30" type="text">

INPUT (type=text); TEXTAREA

<(arrows)>, <(ctrl+arrows)>, <(home/end/pgup/pgdn)>, <(ctrl+home/end)> moves the caret inside text box;
<(enter)> submits form.
INPUT (type=checkbox/radio)

<(space)> Toggle state. Same as mouse click;
INPUT (type=button); BUTTON

<(space)> Press the button down;
<(enter)> Click the button;

INPUT (type=text); TEXTAREA

<矢印>, <(ctrl+arrows)>, <(home/end/pgup/pgdn)>, <(ctrl+home/end)> キーはキャレットをテキストボックスの中で移動させる;
<(enter)> キーはフォームを送る。
INPUT (type=checkbox/radio)

<(space)> キーは状態を切り替える。マウスでクリックした場合と同じ;
INPUT (type=button); BUTTON

<(space)> キーはボタンを押す;
<(enter)> キーはボタンをクリックする;

SELECT (size>1)

<(space)> Select current item;
<(shift+up/down)> Extend select in multi-select listbox;
<(up/down)> Move focus to the previous/next item and select it;
<()>To make discontiguous selection, use <(ctrl+up/down)> and <(space)>.
<(ctrl+up/down)> Move the focus indicator up/down without affecting the current selection;
<(space)>(after pressing <(ctrl+up/down)>) Toggle the selection state of the focused item.
For example, to select item 1,3,5, the key sequence is <(space)> to select item 1,<()> <(ctrl+down)> twice to move focus indicator to item 3, <(space)> to select item 3, <(ctrl+down)> twice to move focus indicator to item 5, <(space)> to select item 5.

SELECT (size>1)

<(space)> キーは現在のアイテムを選択する;
<(shift+up/down)> キーは複数選択リストボックスで選択内容を展開する;
<(up/down)> 前後のアイテムへフォーカスを移動させ、選択する;
<()> 選択の中断には、<(ctrl+up/down)> や <(space)>　を使う。
<(ctrl+up/down)> キーは現在の選択へ影響を与えず、フォーカスインジケータを移動させる;
<(space)>キーは(<(ctrl+up/down)>　を押した後) フォーカスされたアイテムの選択状態を切り替える。
例えば、アイテム 1、3、5　を選択するのに、キーの順序は、アイテム 1 を選択するのに <(space)>を押し、<()> <(ctrl+down)> を 2 回押してアイテム 3 へフォーカスインジケータをを移動し、<(space)>で、アイテム3を選択し、 <(ctrl+down)>を 2 回押してアイテム 5 へフォーカスインジケータをを移動し、<(space)> でアイテム 5 を選択する。

SELECT (size=1)
<()><(up/down)> Cycle through list items backward/forward without dropping down the list;
<(home/end)> Select the first/last item;
<(alt+up/down)> Close up/drop down the list.

Status of Form Control Navigation work: All known bugs are fixed.

SELECT (size=1)
<()><(up/down)> はリストを下に展開せずに、リストアイテムを前進、後退し順番に回る;
<(home/end)> は、最初のアイテム/最後のアイテムを選択する;
<(alt+up/down)> はリストを閉じたり/下に展開する:

フォーム制御操作の状況: All 既知のバグ はすべて修正されています。

本日までの翻訳部分です。

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-6

台風一過で、突然炎のごとく、熱波に見舞われた日本列島です。こんな日は、が美味しいのです。

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

III. Keyboard Navigation Across Frame Boundaries

Using the key bindings mentioned in section II, you are not able to move the caret across frame boundaries.

* For framesest, <(F6)>/<(shift+F6)> is used to switch to next/previous frame within the current document and the URL bar.
* <(F8)> is used to focus frame's separator, and <(arrows)> to resize frames. (Not implement yet, we don't intent to do it immediately)
* For iframe, both <(tab)> and <(F69> can be used for switching focus into or out of iframe.


III. フレームの境界をまたがるキーボード操作

セクションIIで述べたキー結合を使っても、フレームの境界を超えてキャレットを移動できません。

* 複数のフレームに対しては、 <(F6)>/<(shift+F6)> キーが、現在のドキュメントや URL バー内で、現在のフレームから前後のフレームに切り替わるのに使用されます。
* <(F)8> キーはフレームのセパレータをフォーカスするのに、そして <矢印> キーはフレームのサイズを変更するのに使用されます。（未実装であり、すぐに実装するつもりはありません）
* iframe に対しては、<(tab)> と <(F6)> キーが、フォーカスの iframe へのオンオフを切り替えるのに使用できます。


Browser remembers the most recent caret position of each frame and will return the caret to that position when press <(F6)>/<(shift+F6)>. If it is the first time that caret enters the frame, the caret will be placed at the beginning of that frame (as same as the position after you pressed <(ctrl+home)> in that frame).

Status of Keyboard Navigation Across Frames work: <(F6)>/<(shift-F6)> work, <(F8)> and iframe work not yet implemented. Bugs to be filed in bugzilla.mozilla.org.



ブラウザは各フレームの最新のキャレット位置を記憶しており、<(F6)>/<(shift+F6)> キーが押されてた時、その位置へキャレットを復帰させます。キャレットがフレームに入るのが始めてであれば、キャレットはフレームの最初の位置に置かれます（そのフレーム内で <(ctrl+home)> キーが押されたのと同じ位置です）。

フレームの境界をまたがるキーボード操作の状況: <(F6)>/<(shift-F6)> キーは機能し、 <(F8)> と iframe 機能はまだ実装されていません。bugzilla.mozilla.org.にバグがファイルされます。


翻訳作業も少々夏バテ気味ですのじゃ。

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-5

昨日の節で、残っている部分がありましたので、今日はそこを完了して、テキストブロックにおけるキーボード操作を訳し終えます。

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

Discontinuous Navigation

* <(pgup/pgdn)> scrolls the content one page up/down. The browser keeps the horizontal and vertical distance change of the caret as small as possible. As the browser will automatically scroll the page when the caret is about to move out of the visible area, there is no key binding for horizontal scrolling.
* <(home/end)> moves the caret to the beginning/end of the current line. If the caret is already at the beginning/end of the current line, <home/end> will be no-op.
* <(ctrl+home/end)> moves the caret to the beginning/end of the current frame. If the caret is already at the beginning/end of the current frame, <(ctrl+home/end)> will be no-op.
* <(tab)> moves the caret to the next focusable widget (link, form control etc.).
* <(shift+tab)> moves the caret to the previous focusable widget.


連続しない操作

* <(pgup/pgdn)> キーは１ページのコンテンツを上下にスクロールします。キャレットの上下左右の移動距離を、ブラウザはできるだけ短く保とうとします。キャレットが可視領域から外れようとする時、ブラウザは自動的にページをスクロールするので、横方向のスクロールに対して割り当てられるキーはありません。
* <(home/end)> キーはキャレットを現在の行の最初や最後へ移動させます。キャレットがもしすでに、現在の行の最初や最後に在るなら、<home/end> キーは作動しません。
* <(ctrl+home/end)> キーは、キャレットを現在のフレームの最初や最後へ移動させます。キャレットがもしすでに、現在のフレームの最初や最後に在るなら、<(ctrl+home/end)> キーは作動しません。
* <タブ> キーはキャレットを次にフォーカスされるウィジェットへ移動させます（リンク、フォームの制御など）。
* <(shift+タブ)> キーはキャレットを直前にフォーカスされたウィジェットへ移動させます。


Status of Discontinuous Navigation work: Most commands are working properly, with a few problems remaining with Ctrl+Home/End. See Bugs that Affect Discontiuous Navigation for detailed status.


連続しない操作機能の状況: たいていのコマンドは正しく働きますが、Ctrl+Home/End キーで残っている問題も少しあります。詳細の状況については『連続しない操作に影響するバク』を参照してください。


Text Selection

<(shift)>+any the caret movement keys listed above will move the caret from the current position (A) to the destination position (B) and select the text between A and B. For example, <(shift+right)> will move the caret one character right and select the current character.

Status of Text Selection work: There are some known issues with caret movement for text selection. Bugs to be filed in bugzilla.mozilla.org.

テキスト選択

<(shift)>+すべてのキー:　上記に上げたキャレットを移動させるキーは、キャレットを現在の位置(A)から、目的の位置(B)へ移動させ、AB 間のテキストを選択します。たとえば、<(shift+右)> はキャレットを一文字右へ移動させ現在の文字を選択します。

テキスト選択機能の状況: テキスト選択のためのキャレットの移動には既知の問題点がいくつかあります。bugzilla.mozilla.org.にバグがファイルされます。

See you (^-^)/~~~~ tomorrow.

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-4

本日は長い節ですが、<italic>テキストブロックにおけるキーボード操作</italic> を一気に訳します。代表的キーによるキャレットの動きを詳述しております。

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

II. Keyboard Navigation in a Block of Text

This section can be generally named as "keyboard navigation in text", because the key bindings are applicable to all text in browser content window, no matter if it is just a paragraph text or inside table/form.

II. テキストブロックにおけるキーボード操作

この節は一般に「テキストのキーボード操作」と名づけられるものです。というのは、段落内であれ、表やフォーム内であれテキストであれば、ブラウザのコンテンツウィンドウ内のすべてのテキストにキーを割り当てることができるからです。

Continuous Navigation

* <(left)>^*1 moves the caret one character left. Especially, if the caret is at the beginning of a line, <left> will move it to the end of the previous line. If caret is already at the beginning of the current frame, <left> will be no-op.

^*1→<(left)>と不思議な表示をしているのは、ブログの　editor がタグを解釈て、タグ表示を消さないように、()　を間に挟んでいます。以下も同様にしております。(^-^;

連続操作

* <左> キーはキャレットを一文字左へ移動させます。とりわけ、キャレットが行の開始に在るなら、<左> キーはキャレットを前の行の最後へ移動させます。もし、キャレットがすでに現在のフレームの最初に在るならば、<左> キーはキャレットを移動させません。

<(right)> moves caret one character right. Especially, when the caret is at the end of a line, <(right)> will move it to the beginning of the next line. If the caret is already at the end of the current frame, <(right)> will be no-op.

<右> キーはキャレットを一文字右へ移動させます。とりわけ、キャレットが行の最後に在るなら、<右> キーはキャレットを次の行の最初へ移動させます。もし、キャレットがすでに現在のフレームの最後に在るならば、<右> キーはキャレットを移動させません。

<(up/down)> moves the caret one line up/down. Browser keeps the horizontal distance change of the caret as small as possible. If the target line is not long enough to keep the the caret's horizontal distance, browser will remember the original horizontal distance and will return the caret to that position when possible, see example below. If the caret is already at the first/last line of the current frame, <(up/down)> will be no-op.
For example, there are 3 lines of text:

mnopqrst^uvw
123^
abcdefgh^ijk



When the caret is between 'h' and 'i', <(up)> will move it to after '3^'. Also, as the last the caret position will be remembered, so pressing <(up)> again will move the caret to after 't^' in the first line, or pressing <(down)> will move the caret back to the original position (between 'h' and 'i').

<上/下> キーはキャレットを一行上下に移動させます。ブラウザはキャレットの横の移動距離を最小限に保ちます。もし移動先の行がキャレットの距離を保持できる程度に横方向に短かければ、ブラウザは元の位置までの距離を記憶し、可能であればキャレットを元の位置に戻します。下記のサンプルを見てください。キャレットが現在のフレームの最初か最後の行に在るなら、<上/下> キーはキャレットを移動させません。
例えば、3行のテキストがあります:

mnopqrst^uvw
123^
abcdefgh^ijk



キャレットが「h」と「i」の間にある時、<上>キーはキャレットを「3^」の後へ移動させます。また、キャレットの最後の位置が記憶されるので、<上>キーを再度押すとキャレットは「t^」の後へ移動するか、<下>キーを押すとキャレットは元の位置（「h」と「i」の間）へもどリます。

<(up/down)><(ctrl+left)> if the previous character is a part of a word, <(ctrl+left)> moves the caret to the beginning of that word; if the previous character is blank (spaces, tabs), <(ctrl+left)> moves the caret skip those blank spaces and to beginning of the previous word. For example:

abc def gh^i - the next 3 stops when press <(ctrl+left)> will be '^g', '^d', '^a';
abc def ^ghi - the next 2 stops when press <(ctrl+left)> will be '^d', '^a'.


<(ctrl+左)> もし直前の文字が単語の中の一文字であれば、<(ctrl+左)> キーはキャレットをその単語の最初の文字へ移動させます。もし直前の文字が空白（スペース、タブ）であれば、<ctrl+左> キーはこれらの空白のスペースを飛び越えて、その前の単語の最初の文字へキャレットを移動させます。たとえば:

abc def gh^i - <(ctrl+左)>を次に3回押すときキャレットが止まるのは、'^g','^d', '^a' となり;
abc def ^ghi - <(ctrl+左)>を次に2回押すときキャレットが止まるのは、'^d','^a'となります。


<(ctrl+right)> is more complicated - its behavior depends on a preferences setting layout.word_select.eat_space_to_next_word.
It defaults to true on Windows, but false on Linux/Solaris/Mac.

<(ctrl+右)> はもっと複雑です。その動きは layout.word_select.eat_space_to_next_word の設定[preferences] に依存します。Windows、ではデフォルトですが、Linux/Solaris/Mac では偽 [false] です。


→以下は原文書では本当は表になっていますが、項目のみを訳しています。表の形式での翻訳はお手数ですが、リンクをご参照ください

layout.word_select.
eat_space_to_next_word=
current caret position
behavior
example
false (to be consistent with GTK)
inside a word
moves the caret to the end of that word a^bc def ghi - the next 3 stops are: 'c^', 'f^', 'i^';
before blank (spaces, tabs)
moves the caret skip those blank spaces and to end of the next word abc^ def ghi - the next 2 stops are: 'f^', 'i^'.
true (to be consistent with Windows) inside a word moves the caret to the beginning of the next word a^bc def ghi - the next 2 stops are: '^d', '^g'';
abc^ def ghi - the next 2 stops are: '^d', '^g'';
before blank (spaces, tabs)

layout.word_select.
eat_space_to_next_word=
キャレットの現在位置
動き
例
(GTK では常に)偽
単語の中で
単語の最後へキャレットを移動させる a^bc def ghi - 次の3回は: 'c^', 'f^', 'i^'で止まる;
空白の直前 (スペース、タブ)
空白を飛び越え次の単語の末尾へキャレットを移動させる abc^ def ghi - 次の2回は: 'f^', 'i^'で止まる。
(Windows では常に)真 単語の中で 次の単語の最初へキャレットを移動させる a^bc def ghi - the next 2 stops are: '^d', '^g'';
abc^ def ghi - 次の2回は: '^d', '^g''で止まり;
空白の直前(スペース、タブ)

preferences setting layout.word_select.stop_at_punctuation.
If this setting is true, <ctrl+left/right> will stop at punctuations, for example, "-" in "e-mail".
It defaults to true on Windows, but false on Linux/Solaris/Mac.

layout.word_select.stop_at_punctuationの設定 [preferences]。
この設定が真なら、 If this setting is true, <ctrl+左/右> は句読点で止めます。例えば、"e-mail" の "-" です。
この設定は、Windows では真ですが、Linux/Solaris/Mac では偽です。


An exception, for HTML listing elements (<(ul)>, <(ol)>, <(li)>), the caret won't go through the leading numbers/bullets of the <(li)> element. For example:

1. abc
2. def

When the caret is before "d", <(left)> will move it to after "c" in the previous line.

例外として、HTML のリスト要素 (<(ul)>, <(ol)>, <(li)>) では、数字や <(li)> 要素の黒点マークを無視します。例えば:

1. abc
2. def

"d"の直前にキャレットがある時、 <左> は、前の行の "c" の直後へキャレットを移動させます。


preferences setting layout.word_select.stop_at_punctuation.
If this setting is true, <(ctrl+left/right)> will stop at punctuations, for example, "-" in "e-mail".
It defaults to true on Windows, but false on Linux/Solaris/Mac.

layout.word_select.stop_at_punctuationの設定 [preferences]。
この設定が真なら、 If this setting is true, <(ctrl+左/右)> は句読点で止めます。例えば、"e-mail" の "-" です。
この設定は、Windows では真ですが、Linux/Solaris/Mac では偽です。

Status of Continuous Navigation work: <(left/right/up/down)> basically work well, though some rarely visible bugs remain. See Bugs that Affect Arrow Movement for the detailed status. <(ctrl+left/right)> is finished. See Bugs that Affect Ctrl+Arrow Movement for detailed status.

連続的操作機能の状態: <(left/right/up/down)> は、見えるバグがまれに残っているものの、基本的にうまく機能します。詳細の状況につきましては、Arrow の動きに影響するバグを参照してください。 <(ctrl+左/右)> は、これで終わりです。詳細の状況につきましては、Ctrl+Arrow の動きに影響するバグを参照してください。

台風二マケナイゾ・・・・・・・デモナガイホンヤクデツカレマシタネ・・・・・

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-3

本日は、長い序文の後半部です。キーボードアクセスに対する外部からの要件に対して、 Mozilla の問題の多い現状を概説しています。

原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

The gecko rendering engine of Mozilla (also embedded in other applications such as Firefox, Galeon, and others) presents only a very minimal keyboard navigation scheme for web content, activated when the user presses the F7 key on their keyboard (sometimes called "F7 navigation" or "Caret Browsing Mode"). In the current Mozilla 1.7 and 1.8 codebases, this mode uses existing code written for use in the Mozilla Editor application for generating web content. Unfortunately there are two significant problems with this mode: (1) it provides no means to navigate the rich structure of web content (e.g. tables, forms), and (2) it has a lot of bugs.


Mozilla の gecko 表示エンジンは (Firefox、Galeon などのアプリケーションやその他のアプリケーションにも組み込まれていますが)、ウェブコンテンツに対して最低限のキーボード操作しか提供していず、キーボードで F7 のキーをユーザが押すと動作します（「F7 ナビゲーション」とか「キャレット検索モード」などと呼ばれることがあります）。このモードは、現行の Mozilla 1.7、1.8 のコードべースで、ウェブコンテンツ生成用の Mozilla Editor アプリケーションに使用され、書かれる既存のコードを使います。残念ながらこのモードには、2つの重要な問題が存在します。(1)ウェブコンテンツのリッチな構造（例えばテーブル、フォーム) を操作する手段を備えていないのと、(2)バグが多いことです。


This document contains a proposal by the authors outlining a rich keyboard navigation scheme they propose to implement on the gecko rendering engine and thereby into Mozilla, Firefox, Galeon, and all other gecko-embedding web browsers. It is hoped that a consensus among those interested in open source web accessibility can be reached rapidly based on this proposal, so that it can be implemented quickly. Note: this document proposes these keyboard navigation mechanisms only for when the user is in "Caret Browsing Mode". Section IX highlights the differences between these^*1 two modes.


この文書の内容は、リッチなキーボード操作スキームの要点をまとめている作者による提案になっており、彼らは、Gecko 表示エンジンや、それを使う Mozilla 、Firefox、Galeon、その他 Gecko を組み込んだウェブブラウザにスキームを実装することを計画しています。望ましいのは、オープンソースのウェブアクセシビリティの関係者間で、この提案に基づいて早急に合意が形成され、その結果提案内容が素早くに実装されることです。注記：この文書はユーザが「キャレット検索モード」になっている時だけ使用可能なキーボード操作メカニズムを提案します。セクションIXでは、これら2つの^*1モードの相違点にスポットをあてます。

^*1→2つのモードが何を指すのか、この序文では明確でないようですが、セクションIXで分かり易く対照されています。

ここまで読んで、この文書の意味づけがおおよそ理解できたと思います。明日以降も翻訳を加速したいと思います。

See you (^-^)/~~~~ tomorrow!

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-2

昨日翻訳した部分で、 Mozilla のキーボード操作に関して重要な操作にさえ、すぐに解決すべき問題が存在していることが説明されていました。本日はこの文書の全体の構成を目次で見たあとで、第一節から順番に翻訳を開始します。原文です。

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

Contents

* Introduction
* Keyboard Navigation in a Block of Text
* Keyboard Navigation Across Frame Boundaries
* Form Control Navigation
* Keyboard Navigation in a Client-side Image Map
* Keyboard Navigation into/out-of Plugins (and also Java[TM] Applets)
* Keyboard Navigation in a Sample Web Page
* Unresolved Issues
* Differences Between Caret Browsing Mode and Non-Caret Browsing Mode
* Item-oriented Navigation using Javascript Component
* Reference
* Buglist


目次

* 序文
* テキストブロックにおけるキーボード操作
* フレームの境界をまたがるキーボード操作
* フォーム制御の操作
* クライアント側のイメージマップにおけるキーボード操作
* プラグインへの出入りにおけるキーボード操作（Java[TM] アプレットも含む）
* サンプルのウエブページにおけるキーボード操作
* 未解決の問題点
* キャレット検索とキャレットなし検索の相違点
* JavaScript 部品を使用するアイテム指向の操作
* 参照リンク
* バグ一覧


I. Introduction

A key accessibility requirement of software applications is that all features of that application be achievable via the keyboard (with exceptions made for things like painting programs). See Section 508 § 1194.21(a) which explicitly requires this of software that is acquired by the U.S. Federal Government. One clear feature of a web browser is the ability to copy a region of text from a web page and then paste it elsewhere (perhaps in a text document one is writing). Without a straightforward way to accomplish text navigation and selection within all web pages using only the keyboard, a web browser would fail to meet this key accessibility requirement, and should thus be avoided by U.S. Government purchasing agents and all others who are interested in acquiring and using accessible software applications.

I.序文

ソフトウェアアプリケーションのキーアクセス性における要件は、アプリケーションのすべての機能がキーボード経由で実行される（描画ソフトなどで例外はありますが）ことです。合衆国連邦政府が調達するソフトウェアに関してこの事を明確に要求している セクション 508 § 1194.21(a) をご参照ください。ウェブブラウザのひとつの明らかな機能は、ウェブページからテキスト領域をコピーして、他の場所に貼り付け（書かれているテキスト文書の中に）ができることです。キーボードだけを使ってすべてのウェブページでテキストの選択と操作を簡単に実現する方法がなければ、ウェブブラウザはこのキーアクセス性に関する要件を充たすことができずに、合衆国連邦政府の調達機関や、アクセス可能なソフトウェアアプリケーションに関心のあるその他の組織に採用されることは無いでしょう。

In addition to using keyboard navigation to perform text selection, keyboard navigation of text is important for screen reader users. One of the most common ways that screen reader users interact with software applications in the Graphical User Interface is via the standard keyboard interaction mechanisms of their computer desktop or those unique to the software application: their screen reader receives events from the application in response to keyboard movement (focus or caret events commonly), and then in response reads to the user (or renders via a refreshible Braille display) the appropriate information.

テキストの選択をするのにキーボード操作を使うことも含めて、スクリーンリーダのユーザにとってテキストのキーボード操作は重要です。グラフィカルなユーザインターフェイス (GUI) で、ソフトウェアアプリケーションにスクリーンリーダのユーザが対応するごく普通の方法は、コンピュータデスクトップの標準的なキーボード対応メカニズムや、ソフトウェアアプリケーションの独自のメカニズムを使用します。すなわち、キーボードの動作（普通はフォーカスやキャレットイベント）に反応して、スクリーンリーダはアプリケーションからイベントを受け取り、そして反応時にユーザ（あるいは点字点字ディスプレイ経由であれば読者）へ適切な情報を読み上げます。


長い序文なので、続きは明日にしましょう。本日まで翻訳した部分です。
See you (^-^)/~~~~ tomorrow.

Mozilla/Gecko Keyboard Navigation Proposal を和訳する-1

本日から新文書の和訳に取り組みたいと思います。つい今しがた、リクエストの中から選んで予約宣言したばかりです。そうと決めたならば、間髪をいれずに翻訳にとりかかりましょう。

まずは、原文をご覧ください。

誰も手をつけていない文書を日本語に訳すのは、自分が最初だと思うとなんとも言えず、わくわくしますね。(^-^;

原文：　 青色表示
訳文：　 黒色表示
注記： 赤色表示

Mozilla/Gecko Keyboard Navigation Proposal

Kyle Yuan, Ginn Chen and Peter Korn
Sun Microsystems, Inc.

30 Nov 2004

Preface

Mozilla/Gecko キーボード操作の提案

Kyle Yuan、Ginn Chen、Peter Korn
サンマイクロシステムズ社

2004 年 11 月 30 日

始めに

This is the second draft of the Mozilla/Gecko Keyboard Navigation Proposal from Sun Microsystems, Inc. After a huge volume of feedback, we carefully re-thought a number of things and especially took to heart the frequent request for configurability. To that end we have decided to prune some of the commands from this second draft to cover only "core" navigation to be implemented directly in C in Gecko. Configurability is most easily done in JavaScript extensions, and that is where we feel all of the "item navigation" work is best done. This is also where much of the "specialized for specific accessibility needs" navigation falls as well - blind users for example finding good table item navigation particularly important where a general keyboard user wouldn't benefit as much. Please see the new section Item-oriented Navigation using Javascript Component for more on this.

この文書は、サンマイクロシステムズ社の Mozilla/Gecko キーボード操作に関する２番めの原稿です。膨大な評価情報を受け取ってから、私たちは、たくさんの項目を注意深く再考し、とりわけ、システム設定に対する頻度の高い要求にいつては、特に配慮しました。そのために、この２番めの原稿にあるコマンドの幾つかを省いて、Gecko で直接的に C で実装される中核的な操作のみをカバーすることにしました。システム設定は JavaScript の拡張機能でごく簡単に実現でき、そして、それこそがまさに、「アイテムの操作」の全機能が最大限に実現できる部分だと、私たちは感じております。システム設定はまた、特定のアクセシビリティの必要性に特化した操作が多くの場面で問題を起す部分です。たとえば、普通のキーボードユーザがそれほど便利と思わない場所で、目の不自由なユーザが表の項目を上手く操作することを、特に重要と感じるようなことです。この件で詳細の情報が必要であれば、 JavaScript 部品を使用するアイテム指向の操作 をご覧ください。

Sun plans to implement all of the specific keyboard navigation items discussed below (any exceptions are clearly noted). We believe that item navigation is important, but we don't propose to implement that immeidately - both because there is yet no clear concensus as to how it should be done, and because we feel that it is urgent that we have "core keyboard navigation" working well as quickly as possible. Please see Section XII for the list of keyboard navigation bugs and their status.


サンマイクロシステムズ社は、下記で議論されている特定のキーボード操作のすべてを実装することを、計画しています（例外があれば、明示されています）。アイテムの操作は重要と思いますが、私たちは、それを今すぐに実装する必要はないのではと考えています。その理由は、２つあって、実装方法についてのコンセンサスができていないのと、できるだけ早く中核的なキーボード操作を機能させたいためです。キーボード操作のバグとその状態については、Section XII をご参照ください。





新しい文書の訳し出しは、緊張もし内容の展開を予測して楽しみにも思います。それからあと、いわば、ライブで訳していますので、後で、校正が必要になるかもしれません。(^_^ゞ　本日の和訳分はここです。See you (^-^)/~~~~tomorrow.

Enhanced Extension Installation を校正する -19(終わり）

＼(~o~)／ ＼(~o~)／ ＼(~o~)／ ＼(~o~)／ ＼(~o~)／ ＼(~o~)／ ＼(~o~)／ ＼(~o~)／
ニモマケズ、ニモマケズ、ツイニコウセイガ完了シマシタ!!!!!!!!!カンパイダ"アトハ、ゼンタイヲミナオシテ、マズイニホンゴ、イロイロ、カタチヲトトノエテ、「草稿後悔」カラ『草稿公開』ヘ。m(__)m

原題: Enhanced Extension Installation

訳題: 強化版拡張機能のインストール

原文：　 青色表示
訳文：　 黒色表示
校正文： 赤色表示
校正対象範囲：　黒色太字表示
*注記、コメント:赤色表示

It is possible to order Install Locations using the priority property on an Install Location object. This determines whether or not an extension from one Install Location can "trump" the same Extension installed at a different Install Location.
Install Location→インストールロケーションオブジェクトで、優先プロパティを使用してインストールロケーションに対して順序付けすることが出来ます。このことは、あるインストールロケーションの拡張機能が、別のインストールロケーションにインストールされた同じ拡張機能よりも優先されるべきかどうかを決めます。

User action requested notifications are now sent with the em-action-requested topic through the observer service:

* item-installed

An item has just been downloaded and configured for installation for the first time.
* item-upgraded

A new version of an installed item has been downloaded and configured for installation.
* item-uninstalled

An item has been configured for uninstallation.
* item-enabled

An item has been configured for enabling.
* item-disabled

An item has been configured for disabling.
ユーザの動作が要求した通知→ユーザの要求行為に対する通知は、オブザーバーサービスを通じて em-action-requested トピックと一緒に→によって送信されるようになりました:

* item-installed

項目がダウンロードされてインストールが初めて設定されました。
* item-upgraded

インストールされている項目の新バージョンがダウンロードされインストールが設定されました。
* item-uninstalled

項目のアンインストールが設定されました。
* item-enabled

項目の有効化が設定されました。
* item-disabled

項目の無効化が設定されました。

Things This Upgrade Does Not Do
Replace RDF/XML as a Storage Format

The RDF/XML datasource back end creates unneccessary and undesirable complexity when saving data. It also makes it more difficult to support multiple instances of a single extension at different Install Locations due to the singleton nature of RDF resources. Extension metadata is structured and not relational in the sense encouraged by RDF, and so a simple text storage format is probably desirable. Making the database file format human readable would also help developers debug their installation problems.
この機能向上が対応しない内容
Storage Format として RDF/XML を置き換える

RDF/XML データソースの終端処理は、データーをセーブする時、不要にして望ましくない問題を作り上げ→引き起こします。またそれは、RDF リソースの独立性のせいで、様々なインストールロケーションで単一の拡張機能の複数のインスタンスをサポートすることを一層困難にします。RDF によってある意味奨励されるように→奨励される意味で、 Extension メタデーターは構造化されており、相関的になっていません。従って→そこで、おそらく簡単なテキストの保存フォーマットが望まれるようになります→なるでしょう。データーベースのフォーマットを人間が読める形にすることもまた、開発者がインストールに関する問題を解決するのに役立ちます。

Footnotes

1. The term "Extension" is used in this document to imply any item managed by the Extension Manager, including themes.
2. The term "Firefox" is used in this document to imply any application built on XULRunner that uses the Extension System.
脚注

1. "Extension→拡張" という用語は、テーマを含めて 拡張マネージャによって管理されるすべての項目を示すのに使用されます。
2. この文書において "Firefox" は、拡張システムを使う XULRunner に基づいて作られたすべのアプリケーションを示すのに使用されます。　

See you (/_;)/~~~~ next time.