みんな、accesskeyってどうしてる？　tabindexは？

■掲示板に戻る■ 全部 1- 101- 201- 最新50

1 ：Name_Not_Found ：01/11/20 11:46 ID:y7lJc55x: ユーザのアクセス性を高める目的でaccesskeyやtabindexと
いう属性があることはすでにみんなも知ってると思う。

一応説明しておくと、
アンカーやフォーム、ボタンなんかにキーボードショートカットを
割り当てるのがaccesskey属性。
tab keyを押したときにフォーカスされる順番を設定するのが
tabindex属性だ。

けれど、サイトによって割り当てられている文字やtab順が
統一されていないよね。もちろん、それぞれにサイトオーナーの
考えるところがあってやってるわけだし、どれがいい、わるいと
いえるようなものでもない。
けれど、ある程度の目安があってもいいと思うし、ある程度の
統一が見られた方が、アクセスする僕らも便利になると
思うんだ。

みんなは、どんな文字をどういうケースに対して割り当ててる？
みんなは、tab順、どうしてる？

いろんな例を出し合ってみようよ。できたら、その良否も
含めてさ。
2 ：1 ：01/11/20 11:47 ID:y7lJc55x: accesskeyの場合

次文書に対しては[N]ext、前文書は[P]revあるいは[B]eforeと
いうのが一般的だと思う。
これらは実際理解しやすいし、このようにしている、あるいは
しようとしているサイトオーナーも多いだろう。
でも、僕は使うなら、[N]ext、[B]efore。理由は、NとBは
キーボードの上で隣り合っていて、操作の際に大きく手を
動かす必要がないからだ。

では、index（目次）を提供するアンカー（リンク）に関しては
どうだろう。僕の見てみたところでは、[U]pというものと、
[X]というものがあった。Xの根拠は分からんのだが、
これらはどんなもんだろう。

あと一般的なのでは、ヘルプ文書には[H]elp、ページ検索には
[S]erchが多い。ヘルプでHを使うのはよいとして、だったら
サイトホームページへは[T]opを使う？

一時期、ダイアモンドカーソルを応用しようとした
（前文書[S]、次文書[D]、インデックス[E]）が、
あまりに分かりにくそうだからやめた。けれど、
iモードとかでアクセスするユーザに対しては、
前文書[7]、次文書[9]、インデックス[8]、ホーム[5]とかが
使えそうだ。
3 ：1 ：01/11/20 11:47 ID:y7lJc55x: tabindexの場合

これは自分の設定なんだけど、

1. 入力フォーム（フォームがある場合）。submitとresetボタンは、
　一番最後にフォーカスするようにしている。
2. ローカルナビゲーション。次文書とか前文書にリンクするやつだ。
3. グローバルナビゲーション。ホームや別カテゴリのトップへのリンクだ。
4. そしてヘルプ文書やページ検索、著作権関連かな。

実際、どういう順序が一番便利なんだろう。
4 ：Name_Not_Found ：01/11/20 12:04 ID:bYvek9BZ: INDEXの[X]はinde[x]だからだろ？

漏れは site top は[T]にして、
各ディレクトリのindexを[I]にしてるけど。
5 ：1 ：01/11/20 12:09 ID:y7lJc55x: >>4
inde[X]か！
それは気付かなかった。勉強になったよ。

やはりサイトトップはTが優位か。で[I]ndexにすると。
これらは多そうだね。実際、分かりやすくていい感じだ。
6 ：Name_Not_Found ：01/11/20 12:15 ID:al5HIHw6: Index[I]
Help[H]
Top[T]
Prev[P]
Next[N]

とかやってたらブラウザのヘルプ[H]やツール[T]が開いた。
ガ━━━(ﾟДﾟ;)━━━ン!
7 ：Name_Not_Found ：01/11/20 12:19 ID:uGilf51y: Internet Explorerのツールバー(?)は

ファイル(F)
編集(E)
表示(V)
お気に入り(A)
ツール(T)
ヘルプ(H)

の六つだね。ここら辺のキーは避けたほうが無難？
NetscapeやMozilla、Opera何かはどうなっているんだろう。
[C]ontents
は何か被るのあったっけ？
8 ：Name_Not_Found ：01/11/20 12:29 ID:P5q5tAgB: OperaとMozilla

[F]ile
[E]dit
[V]iew
[N]avigation/
[M]essaging/E-[M]ail
[S]erch/New[S]
[B]ookmarks
[Q]A
[D]ebug
[G]a
[W]indow
[T]asks

どうすりゃいいんですか？
9 ：Name_Not_Found ：01/11/20 12:30 ID:P5q5tAgB: あ、[G]o だった…
10 ：1 ：01/11/20 12:31 ID:y7lJc55x: >>6-7
alt+accesskeyが、本来のキーバインドとかぶる問題だね。
さけるべきものとして、alt+Dというのもある。
WinIEではこれでURL入力欄を選択できるんだ。

基本的にalt押しっぱなしかどうかが運命の分かれ目なんだが、
やっぱりかぶるのはちょっと不便だよな。

> NetscapeやMozilla、Opera何かはどうなっているんだろう。

ごめん、僕マカーなんだ。実際、どうなってるんだろ。
11 ：1 ：01/11/20 12:34 ID:y7lJc55x: >>8
情報、thanx!

Netscape、Mozillaでは、N、S、B、Tが予約済みですか！
実際まいるよなあ。気にせずいっちゃおうか。
12 ：Name_Not_Found ：01/11/20 12:36 ID:zw9icRBo: TabindexやAccesskeyがいまいち使われないのは
やはりユーザーエージェントの持っているショートカットと
かぶってしまうからでしょうかねぇ
13 ：7 ：01/11/20 12:45 ID:uGilf51y: 取り敢えず、試してみた。
accesskeyに[D]を割り振ると、どうやらHTMLの方が優先される模様。
Internet Explorerのアドレス(D)には、どうやっても行かない（多分）。マウスを持っていけば選択されるけど。
[A]や[H]といった他のキーも同様。
Windows 2000 SP2 + Internet Explorer 5.5 SP2で確認。

>>12
User-Agentのショートカットを有効にする方法は無いのかな。
14 ：1 ：01/11/20 12:47 ID:y7lJc55x: >>12
UAの持つショートカットとかぶる問題もあるだろうけれど、
いちいち設定するのが面倒臭いという人や、
そもそも、その存在を知らないという人が
多いような気がする。

link要素についてもそうなんだけど、
UAがその存在、便利さをユーザにアピールできる
ようになってほしいと思う。
例えば、Macintosh用UAのiCabなんかは、
link要素はナビゲーションツールバーの下に
一覧で表示してくれるし、accesskey属性は
該当要素に<文字>という形で表示してくれる。

UAがユーザを啓蒙してもいいと思うんだよ。
15 ：Name_Not_Found ：01/11/20 12:47 ID:ZLLpf5aQ: 別にかぶってもいいじゃん。最悪でも、指定しないのと同じなんでしょう？
16 ：Name_Not_Found ：01/11/20 12:47 ID:P5q5tAgB: 参考までに、accesskeyをサポートしている要素は
a,area,button,label,input,legend、です。
tabindexは、a,area,button,object,input,select,textareaです。
17 ：1 ：01/11/20 12:52 ID:y7lJc55x: >>15
かぶったら、ブラウザの持ってるショートカットが
死ぬ場合があるんだよ。そのショートカットを
普段使ってるユーザにとっては、とっても困った問題。

>>16
ありがとう。本当は僕がやらないといかん仕事だね。
助かりました。
18 ：1 ：01/11/20 12:55 ID:y7lJc55x: >>13
検証ありがとう。
ところで、AやHの場合、alt押しっぱなしじゃなくて、
一度キーを放してからじゃダメかな？
一度試してみて。
19 ：Name_Not_Found ：01/11/20 12:56 ID:CdFI6TqS: アルファベットはかぶるので、私はアクセスキーを1～0の数字にしてます。
尤も、マウス操作の方がやりやすいので、殆ど使用しないけど。
20 ：1 ：01/11/20 12:59 ID:y7lJc55x: >>19
確かに、数字を使うのも手だね。
テンキーを使ってのナビゲーションなら、
前文書[4]、次文書[6]、インデックス[5]、
ホーム（トップ）[8]、検索[7]、ヘルプ[9]
みたいのが便利だろうか？　どう？
21 ：Name_Not_Found ：01/11/20 13:00 ID:P5q5tAgB: やっぱりブラウザのUAよりもHTML内のaccesskeyを優先しますね。
でも、それはaltを押したまま指定したキーを押した場合で、
一度altを押してから放し、指定したキーを押した場合は
ブラウザのUAが優先されるようです。少なくともIEでは。

…あ、>>18さんが既に書いてる！
22 ：1 ：01/11/20 13:02 ID:y7lJc55x: >>21
でも、検証ありがとう。実際に試してくれた結果なんだから、
どうどうと胸はってよ！

ところで、UA=ユーザーエージェント、つまりブラウザのことね。
ごめんね、ちょっと老婆心。
23 ：7 ：01/11/20 13:04 ID:uGilf51y: >>18
>>20
あ、本当だ。ありがとうございます。

#でも、みんながこれを知っているとは限らないしなぁ……。
accesskey属性自体、知名度が高いとは言い難い状況だし……。
「はじめに」とか言うページを作って、そこに書いておくとかした方がベターかな。
Alt押しっ放し + キーと Alt + キーの違いも含めて。
24 ：Name_Not_Found ：01/11/20 13:05 ID:P5q5tAgB: >>22
ああ、すみません。
仕事柄UAと聞くと5パターンくらい別の意味やらなんやらがあるんで
区別するために変な言い方になっちゃうんです。はは・・・
25 ：7 ：01/11/20 13:06 ID:uGilf51y: あちゃ、ごめんなさい、>>23の>>20は>>21の間違いです、ｽﾐﾏｾﾝ。
26 ：Name_Not_Found ：01/11/20 13:13 ID:CdFI6TqS: >>23
おっしゃる通り、大抵はそんなものは知らないし、マウスを使ってるね。
ま、一応アクセスキー設定はしてあるけど、実際使ってる閲覧者は皆無ではないかな。
HTML-Lintで満点取りたい人の自己満足って気も……。
27 ：Name_Not_Found ：01/11/20 13:20 ID:y7lJc55x: >>23 >>26
そう、確かに一般への浸透という点では、はなはだ疑問がある。
実際、ふつうはマウス使うしね。
でも、これって本来はそのマウスを使うことに不便がある
場合を想定しているわけだから、できればそういう環境に
ある人の意見を最重要視したいんだ。

自分の場合、Webで公開されているデータベースから
情報を取得して、Excelに入力する仕事なんかもしてるんだ。
この時は、できるだけマウスを触りたくない。能率が落ちるからだよ。
でも、そのデータベースの検索フォーム内のフィールドをフォーカスする時に、
ページ最上部にあるナビゲーションからタブでいちいちたどっていかないと
ならないので、ちょっと不便を感じるんだ。

こういう時には、tabindex、accesskeyって思っちゃう。

だから、自己満足かも知れないけど、自己満足には
したくないんだ。
それにみんなが知って、これを便利と思う人が増えたら、
広まるしさ。そうなってほしいと思ってるんだよ。
28 ：1 ：01/11/20 13:21 ID:y7lJc55x: ごめん、>>27は1ね
29 ：1 ：01/11/20 13:28 ID:y7lJc55x: >>23
> 「はじめに」とか言うページを作って、そこに書いておくとかした方がベターかな。
> Alt押しっ放し + キーと Alt + キーの違いも含めて。

これは、自分は書いたよ。link要素とaccesskey、tabindexに
触れた、このサイトの歩きかたを掲載してる。

けど、こういうのがこと細かく書いてあるサイトを敬遠する
人も少なくないんだよね。マニアとかって思われちゃう。

まあ、自分がマニアであることは否定しないんだけど……

一番いいのは、こういうことが一般に広まって、
いちいちヘルプ文書に記載する必要がなくなることだよね。
青い文字をクリックすると別のページにジャンプします、なんて
今や誰も書かないし説明しないじゃん。
（というか、青い文字とかクリックって書いてる時点で、
かなりダメな気もする）
30 ：Name_Not_Found ：01/11/20 13:29 ID:zw9icRBo: >>26
>>26
＞HTML-Lintで満点取りたい人の自己満足って気も……
たしかに、僕がAccesskey等を入れる場合ほどんどがこれかも（汗
とはいえ、無くても良いかもしれないけど、あればあったで
分かる人には便利な機能という部分では、入れておいても
良いですよね。
でも結局、UAとのショートカットと被っちゃう～とかって悩み
はじめるのがいやだから、入れていないのもありますね。

>>27
＞それにみんなが知って、これを便利と思う人が増えたら、
＞広まるしさ。そうなってほしいと思ってるんだよ。
その気持ち分かりますよ。うちの会社制作関連なんだけど、
恥ずかしい話、ほとんどの社員がAccsesskey,tabindexを
しらないです。情けない！
31 ：1 ：01/11/20 13:38 ID:y7lJc55x: >>30
賛同ありがとう！　僕もUAのショートカットとのバッティングに
悩んだんだけど、結局入れることにしたんだ。

自分の場合は最初にあげたように、
[B]efore、[N]ext、[U]p、[H]elp、[S]erch、[T]op。
これに決めるのに、いろいろなサイトを回って実例を調べて、
もっとも納得できるものを選んだという感じ。

本当は、ある程度のガイドラインなんてものもあったほうが
いいと思って、このスレッドをたてたんだ。いくサイト、
いくサイトでショートカットがかわるのも不便だしさ。

実際、視覚障碍のある人とかはどうしてるんだろ。
コンピュータを使ってる盲の知り合いはいたんだけど、
最近あってない。メールアドレスも知らないし。
職場でホームページ・リーダー、買ってくれないだろうなあ……
32 ：Name_Not_Found ：01/11/20 15:22 ID:I/aNN9Ot: 優良スレだね。
33 ：1 ：01/11/20 15:27 ID:y7lJc55x: >>32
サンキュ！
34 ：1 ：01/11/20 16:08 ID:y7lJc55x: ちょっと動きが減ってきたので、目先を変えてみましょう。
想定されるリンク先と、そのaccesskeyを考えてみる。
まずは既出のものからまとめるよ。

前文書: [P]rev, [B]efore, [4]
次文書: [N]ext, [6]
インデックス: [I]ndex, inde[X], [C]ontents, [U]p, [5]
トップページ: [T]op, [8]
ヘルプ: [H]elp, [9]
検索: [S]erch, [7]

他に使えそうなもの

別言語版: [A]lternative
用語集: [G]lossary
リンク集: [L]inks
著作権: [C]opyright
mailto: [M]ail, [@]

どうだろう？　リンク集より以下はかなりこじつけっぽいね。

後、どうしてもこの文字はやめてってのも欲しいな。
たとえば、WinIEはalt+DでURI入力を選択するので、
これだけはやめてほしいって人がいたんだ。
使わないでほしい文字と、理由があればその理由も、よろしく。
35 ：Name_Not_Found ：01/11/20 16:12 ID:xSRt0roh: ここで言うUpの代わりにBackを使うところもあるからBeforeよりも
Previousがいいと思う。
でも、ここで出ているタイプの表現って全部relで示せるように
なってるよね？
俺としてはブラウザ側で自動的にキーを割り振ってほしい。
rel="Next"に[N]とか。
36 ：1 ：01/11/20 16:21 ID:y7lJc55x: >>35
[U]pの代わりに[B]ackか。なら、[B]eforeよりも[P]reviousだね。

rel="Next"に対して[N]がつくというのは、いいアイデアだと思う。
これなら、link要素をつければ、すくなくともそのUAに関しては、
共通のナビゲーションを保証してくれる。
実はaccesskeyをつけるにあたって、僕は面倒くさがりやだから、
link要素につけようとしたのね。けど、accesskey属性はlink要素には
使えない。
もしlink要素に使えるんだったら、rel="next"に[H]、
rel="start"に[T]を、一気につけようと思ったんだ。
ずぼらはだめですね。これは使えませんでした。

ところで思うんだけど、このUpやBack、Beforeも、
一つの文書を起点とした相対的なもんだよね。
直感的にBackやBeforeなんかは、ブラウザの「戻る」を
考えちゃうんだ。僕だけかなあ。

揶揄するつもりはなくて、ふと思った疑問なんだ。
気を悪くしたら、ごめんね。
37 ：Name_Not_Found ：01/11/20 16:21 ID:zw9icRBo: >>35
それいいかも。
でも、link要素の属性を調べてみたらCとSが重なっ
ちゃうところが出てくるみたい。
このあたりは実装の仕方にも依ってくるかもしれない
けどね。
38 ：腐れマカー ：01/11/20 16:27 ID:xNN9xuR6: とりあえず「初めて来られた方はキーボードのCtrl+Dを押して下さい」なんて
書いてあるようなサイトがaccesskey使うのはやめていただきたい。
39 ：1 ：01/11/20 16:35 ID:y7lJc55x: >>38
Ctrl+Dはお気に入りに追加だったよね。
そりゃ確かにやだね。気に入ったら自分で追加するさ。

>>35 >>37
link要素の自動accesskey化。iCab Campanyにそれとなくメールして
みようと思っています。なぜか？　それは僕がiCabファンだから。
ごめん……　調子に乗り過ぎた……
40 ：1 ：01/11/20 18:33 ID:OuZ18x0Q: >>39
あ、スペル間違ってる。

Campany -> Company
41 ：1 ：01/11/20 18:42 ID:OuZ18x0Q: ミス訂正だけというのも、なんだから。

実は、積極的にaccesskeyを使ってない要素というのもあるんだ。
それは、フォームのsubmitとresetなんだけど、
これは誤送信や誤って書いた内容を消してしまうなんてことが
ないようにとの配慮からなんだ。

Windowsを使ってるときなんか、全角/半角キーとescを
間違えて、全消去してしまうことがある。へこむよね。
42 ：Name_Not_Found ：01/11/20 21:27 ID:2CBMZwQL: 本当にaccesskeyを使ってる人がいるのかな？
使えそうなキーワードはIE NN NCに使われてるし。
タブキーをポチポチ押してきゃいいじゃんって思う。

その上にtabindexなんぞ入れるなんて過剰すぎやしないか？

submitとresetにアクセスキーを入れないのは、同意。
Enterキーのほうが、動作が直感的。
43 ：Name_Not_Found ：01/11/20 22:26 ID:UZqGDAkq: 障害を持つ方や高齢の方向けのコンテンツを含んだサイトを製作中なのですが、
accesskeyを知らない方のためにその解説を記載すべきだと思い、
注意事項というページにその旨を記載しました。
しかし、ユーザビリティテストを行った結果、当然とも言える結果が出てきました。
｢解説を見るまでaccesskeyの存在は意味を為さないのに、
何故その解説が別ページなのか｣ということです。
つまり、トップページ内のスクロールせずに見える部分に解説を置かないといけない、と。
ですが、accesskeyを利用される方の場合、
UAのそれも既に熟知し利用しているとも推測されます。
どこに表記すべきか、それとも解説自体必要ないのか、
そんなこんなで只今上司と考え込んでしまっている次第です・・・
44 ：1 ：01/11/20 22:42 ID:QyhHdOP3: >>42
正直なところ、自分はaccesskeyはあまり重要視していません。
というのは、いくサイトごとにショートカットが異なるので、
統一的なナビゲーションを得られないからというのが理由だったりする。
だからこのスレッドで、accesskeyに関する整理や目安が、
せめて自分なりにでもつけばいいと思ってるんだ。

で、問題のtabindexなんだけど、こちらは僕にとっては、
accesskey以上に切実な問題なんだ。というのは、
>>27 でも少し触れているんだけど、WWW上にある
データベースを参照して、データをExcelに移す仕事なんてのも
やってるんだ。
この仕事をやっているときは、文字入力が断然メインになるので、
マウスに手を伸ばすのが億劫というか、それだけで
仕事の能率が下がってしまうんだよ。
alt+tabでwindowを切り替えて、tabで項目を移動、検索キーを入力、
Enterしてデータ一覧が出たら、該当データへのアンカーをtabで選んで、
またEnter。これでも、まだマウスで操作するより能率がいいんだ。

問題はそのサイトの作りにあって、フォームの前に、サイト内の
別カテゴリへのアンカーがまとまってあるんだ。だから、その幾つもの
アンカー群を、tabで一気に駆け抜けないとフォームにたどりつけない。

そこは検索のページなんだから、みんな用があるのはフォームだと
思うんだけど、そのフォームに移動するのに上でいったような面倒がある。
これが、最初のtabでフォームにアクセスできるとなると、
正直仕事の能率が上がって有り難いんだよ。

長くなってしまったけど、こういう理由なんだ。
だから、僕にとってはtabindexは決して過剰じゃないんだよ。

> submitとresetにアクセスキーを入れないのは、同意。

賛同ありがとう。とってもうれしいよ。

けど、もし他に異論、反論のある人があったら、どしどし
書き込んで欲しい。いろんな意見があったほうが、きっと
最終的にはよくなると思うから。
45 ：1 ：01/11/20 22:57 ID:QyhHdOP3: >>43
現場で実際におこる問題、紹介してくれてありがとう。
僕の方でも、もう少ししたら上司と本格的に話し合うことになってるので、
とても参考になったよ。

僕は、自分のサイトでは、こういったナビゲーションに関することは、
このサイトの歩きかたといった、別の文書に書いてるんだ。
理由は、毎回目にするトップページに、注意書きがいつも表示されるのは
鬱陶しいだろうと思ったからなんだ。でも、現実問題として、
こういった注意書きを読む人って、サイトを隅々まで見てくれている
人だとも思う。だから、あんまり意味がないのかも知れないと
思うこともあるんだよ。

今僕が職場で扱っているサイトというのは、潜在的に視覚障碍者からの
アクセスが予想されるものなので、なおさらこの辺りの問題には
注意を払いたいと思ってるんだ。

僕の案では、トップページの上の方に、
「このサイトは、キーボードだけでご利用いただけるよう、
充分に注意を払っております。詳しくは、<a>このサイトの利用法</a>を
ご覧ください。」
といった、簡単な案内を用意しようと思ってる。それで、
<a>でかこっているアンカーで、accesskeyの説明をしたいと思うんだ。

もしかしたらもっと短くなるかも知れないし、文面自体が
様変わりするかも知れない。でも、なにも書かないより親切だし、
この文章を読んでアクセスしてくれる人がいるとしたら、
なおさら有り難いと思う。

見た目を気にするある上司なんかは嫌がるかも知れないけど、
accesskeyなどの、いろいろなアクセス手段が知られていない
現在は、仕方がないと思う。それに、もしaccesskeyが
知れ渡る日が来たとしても、それを知らない初心者は常に
存在し続けるわけで、熟知している人よりも、新たに何かを
知ろうとしている人に、親切でありたいと僕は思ってる。

でもだとしたら、さっきの文章はもっとわかりやすく
しないといけないね。もっと、練り直してみるよ。
きっと、まだまだ甘いよね。鍛えどころは、まだまだあるよ。
46 ：42 ：01/11/20 23:51 ID:2CBMZwQL: >>43
「どれかのキーを押しながらどれかのキーを押す」という
accesskeyという行為自体、障害を持つ方や高齢の方に
ふさわしい操作とは思えない。
うちのかーちゃんに[Ctrl+C][Ctrl+V]を教えても
「そんな器用なことできん！」って逆切れされるもんね。

もし、Webページの先頭にキーボードで操作できる方法を書くならば
accesskeyより先に
[BackSpace]
[Spece]
[PageUp]もしくは[↑]
[PageDown]もしくは[↓]
[home]
[end]
これら先に教えるべきだと思うな。たぶん知らない人多いと思う。

>1
accesskey然り、tabindexも頻繁にそのページを頻繁に利用してこその
機能ね。
47 ：7 ：01/11/21 00:00 ID:STjgE9Fv: >>46
話が逸れるけど、Windowsには固定キー機能があるから、
それを使えば多少はよくなると思われ。Macは分からないけど。
［コントロールパネル］→［ユーザー補助のオプション］→［固定キー機能］
で設定が出来ます。Shift、Ctrl、Altが固定可能。

って、二つキーを押すと言う時点でかなり辛いのか……うーん。
48 ：Name_Not_Found ：01/11/21 00:38 ID:9tHVk8Qg: >>46
それはなんとなく健常者の視点になってしまっている気がする。
障害者や高齢の利用者って予め知ってるんじゃないの？
そういう一連の操作方法。
マウスが使えない以上、むしろそれを基本にしてるというか。
高齢者はよくわからんけど…。
でも確かにキー2つ同時押しはきついのかもしれないね。
それはこういうシステム自体に問題がある気がする。

なんだか、accesskeyはそういう人達のためというよりも、
単純にキーボードオンリーの健常ユーザーを対象にしてるだけなのかもと思ったりする。
実際そうなのかもしれないが。…なんだか話がまとまってないなぁ・・・。
49 ：1 ：01/11/21 09:58 ID:zBIsPyZu: >>46-48
まとめてでごめん。

複数のキーを同時押しすることで操作するaccesskeyは、
実際の話、人によっては難しく考える人もいると思う。
けど、これは「人によっては」というところが重要だと思うんだ。

若い人でもキーボードショートカットに難色を示す人はいるし、
うちの五十代後半の母親みたいに、みようみまねでショートカットを
使っている人もいる。だから、ケースバイケースだよね。

たとえばMacintosh用のUA、iCabなんかでは、accesskeyの利用に、
キーバインドの必要がないんだ。直接、指定されている文字を
押すだけで、accesskeyが働いてくれる。こういうUAもあるんだ。
だから、オプションでaccesskey利用の際のキーバインドを設定できる
ようになれば、もっとも望ましいと思うんだ。せめて、alt+か
キーバインドなしかだけでも選べるようになればいいと思う。

それと、同じ選べるのなら、accesskeyを押したときに、その
要素をフォーカス（選択）するだけか、クリックしたのと同様に
ヒットするかどうかも、選べるようになってほしいよ。
だって、ジャンプ先のURIや、場合によってはtitle属性の値を
見たいだけって時もあるじゃない。

こういう、ユーザの選択範囲を広げてほしいな。
ごめん、理想論だね。絵に描いた餅だ。

実際のところとして、ユーザはまず基本機能を
よく習熟したほうがいいとは、僕も思う。これは、
障碍、健常ユーザの区別なしにね。
で、こういったaccesskeyなんかは、より操作性を
向上させたいって人のための、追加機能という
認識でいいと思うんだ。

誰だって、より便利にアクセスできたらいいなって思うんだ。
だから、もしかしたら障碍、健常と分ける必要も
ないのかもしれない。

>>47
固定キー機能ね。Macintoshにもありますよ。
確か、
コントロールパネル -> イージーアクセス
だったと思う。
ごめん、うろ覚えで。今日は、Windowsの日なんだ。
50 ：Name_Not_Found ：01/11/27 12:47 ID:H4lrts2h: link要素のナビを取り入れました。

age
51 ：1 ：01/11/27 16:40 ID:eIy5eaeX: >>50
久々にあがってて、ちょっと嬉しいよ。

link要素のナビを取り入れたというのは、
つまりlink要素で一般的に用いられているような、
nextとかprev、start、index、contentsといったリンクタイプを、
accesskey属性に応用したという感じなのかな？

accesskeyによるナビゲーションは、
前後ページやホーム、ヘルプなんかの、
ある程度の恒常性があるページへのリンクに
用いられることが多そうだね。
こういう場合には、確かにlink要素における
リンクタイプを参考にするとよさそうに感じる。

他では、目次の上から1、2、3、4と順番に、
accesskeyが設定されているところもあったかな。
リンク先が増えないのならこれもいいアイディアだけど、
どんどん項目が増えていくようなページだったら、
管理は大変かもしれない。

実際、どういうのが便利なのかなあ。
まだ悩み、模索中。なおもアイデア募集中。
52 ：Name_Not_Found ：01/11/27 17:16 ID:NgVBWnob: 「実質使えない」との意見も。↓
http://www.remus.dti.ne.jp/~a-satomi/nikki/2001_11c.html#day25num03
53 ：50 ：01/11/27 22:05 ID:zeOc498e: >>51
実はaccesskey、tabindexは取り入れてません。
以前に取り入れようとしたことがあったのですが、
tabキーを押すごとに通常左上から順にフォーカス（？）されるリンクが、
いきなり飛んだりするので非常に違和感を感じてしまったからです。
accesskeyに関しても、まだまだ普及してるとは言えない現在、
どのリンクにどのキーを割り当てるか悩んでしまって、結局諦めました。

今回はlink要素のstart、indexやchapterを取り入れました。
全てのページを関連づけるのはかなり難しいので、
next、prevなどは使わず、start pageと各カテゴリindexへのリンク、
rev属性でメールアドレスを記載するにとどめました。

>>52のリンク先の意見は、かなり説得力がありますね。
おかしな使われ方をすれば、悲惨なナビゲーションになりかねませんからねぇ。
とはいっても、特に邪魔になるもんでもないので、
どうすればもっと便利になるか考えつつ取り入れていこうとは思っています。
54 ：1 ：01/11/28 11:54 ID:UiUPjdl+: >>51
そうなんだ。本当のところをいうと、
tabindexもaccesskeyも使いにくいものなんだ。
だって人によって"H"が、
[H]omeだったり[H]elpだったりするのが、
accesskeyの現状。
たとえばアプリケーションによって、
コピーがCtrl(Cmnd)+CだったりKだったりしてまちまちだったら、
ストレスがたまるどころの話じゃない。
その点、娘娘飯店さん（リンク先）のいわんとするところは、
僕の思うところと同じと言っていいよ。

で、僕としてはこの先に進みたいんだ。
まちまちのaccesskeyにおける、
ある程度の目安はもてないだろうかということね。
人によって多少の違いがあれど、
大体同じaccesskeyを使うようになれば、
> オリジナルの腐ったUI
は避けられるんじゃないかと思うし、
僕縛自身、独り善がりのUIは避けたかったんだ。

ものすごく独自すぎるaccesskeyを設定して、
逆にアクセシビリティの面で劣るというのは、
本末転倒。ある意味不幸だよね。

>>53
tabindexの、まちまちなタブ移動は確かに問題なんだけど、
これはうまくさばけない問題なのかな。
うちは、サイト内カテゴリへのリンクとパン屑リストを
各ページの先頭に置いてるんだ。
内容が文章だけのページなら問題ないんだけど、
これが目次を提供するとなれば、
tabでアンカーを選択しているユーザにとっては
面倒ないじゃないかと思ってる。
僕自身、
>>44
で書いたように、
tabを使ったナビゲーションの面での面倒を感じることがあって、
せめてフォーム入力を求めるページでくらいは、
tabindexを使ってほしいと、思うんだ。

accesskeyもtabindexも、
利用者にとって便利という観点を離れて、
ページ製作者の勝手な思い込みで設定されたときが、
多分一番の不幸なんだ。

ならどういうのが便利なのか。
いろいろ考えるんだけど、一概には言えなくて、
ここが僕のいまの悩みかな。

link要素は、全ページにつけるのは非現実的だよね。
実際僕は、一部を除いてchapterやsubsectionは入れていない。
それらを入れているのは、論文だけかな。
実用面ではstartとcontentsあるいはindexがあるだけで、
大きく違うと思うよ。だから、僕はこれらとhelp、copyright、
そしてメールを全ページに入れた。
あとは、ケースバイケース、だよね。
55 ：1 ：01/11/28 22:13 ID:4o4MUmVo: tabindexで問題とされやすい、
tab移動順がまちまちになるという懸案。
これこそaccesskeyと併用することによって、
解決できる問題ではなかろうか。

つまりですよ、
サイト内の別カテゴリやトップ、ヘルプなどにはaccesskey、
ページ内の内容にはtabindexというように、
それぞれを、それぞれ適していると思われる要素に対して、
分業させてしまう。

実際、目次ページの目次にaccesskeyはいらないと思うし、
逆にすべてのページについているようなグローバルリンクに
tabindexはいらないと思う。

どうかな？　ちょっと考えが偏狭かな？
56 ：Name_Not_Found ：01/11/29 16:43 ID:RcxRIZAa: 画像に alt 属性付けられないようなところに診断されてもな。
57 ：Name_Not_Found ：01/11/29 16:44 ID:RcxRIZAa: >>56は誤爆です。ｽﾏｿ。
58 ：Name_Not_Found ：01/11/29 18:00 ID:VIhLs7Pa: 「ブラウザ自身がlink要素にショートカットを割り当て」
これはいいアイデアだなあ。
59 ：1 ：01/11/30 08:55 ID:aBoqGcqV: >>58
賛同ありがとう、でもこれにはちょっと問題点もあるんだよね。

問題点っていうのはアイデアの方ではなくて現実面でのことなんだけど。
ブラウザの種類はふえて結構多様化してきているのに、
未だにlink要素にさえ普通に対応しないものが
現在のシェアを二分（正確には二分じゃないけど）している問題。

こんな現状下でlink要素を解釈して、accesskeyが他に設定されていなかったら
ショートカットを割り当てる機能なんて到底望めない。
それにlink要素を設定しているサイトの大半は、
accesskeyも視野に入れているだろうし（設定してるかどうかは別だよ）。

アイデアとしてもいいし、どのリンクタイプになんのキーを割り当てるかを
ユーザがカスタマイズできるのなら、かなり有効に活用できそうな気はするんだ。
人によっては、ページ制作者ごとにまちまちになりやすいaccesskeyを
無効化したい人もいるだろうし、そういう要望にもこたえてさ。

ただそれ現実化する手段が……　うー、無力だよね。
60 ：ちょこら ◆DmcC0DXc ：01/11/30 09:21 ID:p59I43m3: Moz でだったら P 氏が何とかしてくれたりして。
ってそこまで何でもできるわけではないのかな。

外野の呟きでした。
良スレなので ROM ってます。
61 ：1 ：01/11/30 10:10 ID:aBoqGcqV: >>60
Mozillaでまず装備してもらって、その後他のUAに伝播。
そううまくいけば、僕としてはうれしいなあ。

今はちょっと忙しい（三週連続で休みが潰れてる）ので、
この状況を抜ければ、各ブラウザデベロッパーあてに、
このアイデアを採用してくれるようにメールを書こうと思ってるんだ。
無力だ無力だと、おのが無力を嘆くよりも、
少しでも動けるものなら動きたい。

とりあえず、iCabとOperaには送りたい。
最後に、NCとMSかなあ。MSは黙殺するだろうなあ、なんとなく。

とりあえず送り先としては、どんなところが妥当だろう。
iCab, Opera, Mozilla, NN, IE。
自分のマシンにはこれだけしか入れてないんだけど、
これははずしちゃ駄目だろうというのがあったら、
みなさん、フォローよろしく。

> 良スレなので ROM ってます。
ありがとう。励みになります。
62 ：Name_Not_Found ：01/11/30 10:48 ID:Zt+nai7+: IE6+WINでアクセスキーの挙動が変わったので
アクセスキーやめてJavascriptによるナビゲーションにしました。
63 ：1 ：01/11/30 11:07 ID:aBoqGcqV: >>62
accesskeyをやめて、JavaScriptでのナビゲーションか。
そういうのもありだろうけど、ECMAScriptはoffにしてる人も
少なくないからなあ。

ところで挙動がかわったって話だけど、
どういう風にかわったの？
WinIE5とWinIE6で試してみたけど、
どちらも要素がフォーカスされるだけで、
ジャンプはしなかった。
64 ：Name_Not_Found ：01/11/30 11:14 ID:6QIwZTyq: >>63
Internet Explorer 4の頃は、問答無用でジャンプしていたような。
5.0からフォーカス“するだけ”に変わって驚いた記憶があります。
って、そういう話じゃない？
65 ：1 ：01/11/30 11:32 ID:aBoqGcqV: >>64
ありがとう。WindowsIEは5以降しかなかったので、
そのあたり分からなかった。

ちなみに、MacintoshのIEは問答無用ジャンプ型。
問答無用ジャンプよりも、フォーカスするだけのほうが、
ユーザビリティに関していえば優れていると思う。

できれば、そのフォーカスしたときに、
「title属性値（href属性値）」を
ポップアップしてくれると（ステータスバーにでもいいけど）
有り難いんだけど。
現状は、hrefだけだよね。
66 ：P ：01/11/30 23:09 ID:3yXA2Ut2: Mozなら、Site Navigation Bar にアクセスキーを指定するよう要望を出してみるのもよさそうですね。
個人レベルで拡張してもそれが一般に通用するわけじゃないし、なるべくならオフィシャルで対応してもらわないと……
67 ：1 ：01/11/30 23:18 ID:+BJEosV5: >>66
個人レベルでの拡張というのは、
僕みたいなのにはちょっとむりそうなので、
やはり専門家にお願いしたい話になっちゃう。
専門家は、link要素にアクセスキーを割り当てるなんてアイデアを
面白いと思ってくれるのか？

思ってくれたらいいなあ。
機能が追加されたらなおいいなあ。
68 ：ちょこら ◆DmcC0DXc ：01/12/01 00:42 ID:sodq5xcb: >>66
全くもってそのとおりだと思った。
69 ：50（iCabユーザ） ：01/12/01 00:49 ID:vOIZZ3TT: >>54
>僕自身、
>>>44
>で書いたように、
>tabを使ったナビゲーションの面での面倒を感じることがあって、
>せめてフォーム入力を求めるページでくらいは、
>tabindexを使ってほしいと、思うんだ。

そうですね。
tabindexを指定しないかわりに、
入力フォームの順番に気を使ったりしましたけれど、
でも、導入してみようかなぁ。

いや、このスレいいですよ、ほんと。
>>1さんの律儀且つ行動的なところも(･∀･)ｲｲ!
70 ：Name_Not_Found ：01/12/01 00:59 ID:sOjEoBkF: >>63
俺もJavaScriptでのナビゲーションにしてる。
オンロードイベントではじめに書き込むべきフォームに
フォーカスを当てる。

必須個所に書きこがなければそこでalertを出してその
フォームにフォーカスを当てる。
71 ：Name_Not_Found ：01/12/01 02:07 ID:prir8wES: ちょっとまて、>>1が「一応」でも説明しなければならないこの機能を
世間一般のユーザは知ってるのか？
もしくは使ってるのか？
72 ：Name_Not_Found ：01/12/01 02:28 ID:3QelEyQi: >>71
このスレの途中に書いたけど、うちの会社（制作会社）では
恥ずかしながら知らない人の方が多かった。
どうしても見た目にも派手な機能等に目がいってしまうのも
そうなのでしょうけど、いろいろなブラウザレビューなどを読
んでも、使い方を考えればすごく便利なんじゃないかなと思
うこの機能についてほとんど取り上げていないのも事実。

ユーザーが知ってる、使ってるという所から見ればたぶん×。
だからこそ、もっと使い勝手のいいaccesskey,tabindexの
使い方を考えようっていうところから>>1さんがスレ立てたん
じゃないかと思う。
73 ：まったくの素人である、と一応断わりを入れておいて、 ：01/12/01 02:41 ID:gO/Pb2Li: >>61
どこから流れが広まるかわからないから、Omni Groupもお願いします（藁
MSだって、アクセシビリティにはそれなりの理念を持って
対応している会社だと思うので、悲観しないで。
無視されたら……メールの山に埋もれてしまったと考えましょう。
他に思いついたのは、
アプリケーションのユーザビリティを考え、標準を策定する
デベロッパーの団体とかって無いものですかね…、とか無駄なこと。

>>66
問題が起こりうるとしたら、
Webブラウザのナビゲーションバーの「戻る／進む」と、
iCabでいうところのスタンダードリンクの「Prev／Next」とがあると
一般ユーザが多少混乱するおそれがある、ということかもしれません。
（実際私もiCabを使い、最初は何が何だかわかりませんでした）
専門家の方の御意見をお伺いしたい。

今までlink要素については「結局自己満足…」と思い、避けていたのですが、
このスレッドを読んで、きちんと書くことに決めました。
なんか協力できるものならなぁ。
74 ：Name_Not_Found ：01/12/01 13:52 ID:oMDGvUMT: 1さん、
時間が許されるなら
ここの話をまとめて1つサイト作ったらどうだい？

・主旨
・accesskeyとlink要素とtabindexの役割
・これらの好ましい設置方法好ましくない設置方法
・これらの操作方法（←案外知らない人多いと思う）
・一般ブラウザのふるまい方やスクリーンショット
・今後の提案と共通キーの推進

なんてあると良いサイトになるんだけどねえ
いつかは倉庫行きになってしまうのが実にもったいない。
75 ：Name_Not_Found ：01/12/01 20:08 ID:qhYSDkTx: フォーム要素のtabindexだけど、MacIE5はデフォルトでopt+tabで
テキストフィールドだけをジャンプする様になってる。
昔はtabでフォーカスしてくれるのはテキストフィールドだけだったから、
tabでテキストフィールド移動、opt+tabでリンクも移動、って設定も出来る。

俺はMacIEを常用してるんで>>44みたいな
検索キー入力でtabindexが必要だとは思う事はなかった。
ブラウザの機能を改良するだけでも大分違うと思うよ。
76 ：1 ：01/12/01 23:06 ID:l8SIorwQ: >>69
入力フォームの順番に気を使うというのも、
結構重要なことと思うよ。
タブは頭から順番に進んでいくのが
やはり自然だと思うので、
その自然から外れることで、
ユーザを戸惑わせてはならないと思うんだ。

でも順番をきっちり守ると、
tabindexの意義が薄れるんだよね。
なので、とりあえずはresetボタン以外に
tabindexをふることで満足してる。
というのも、はずみでresetしてしまうことが
多くて多くて、その度にへこむもんだから。
escでresetしたことも多数。
話ずれたね。ごめんね。

> このスレいいですよ、ほんと。

ありがとう。むしろ恐縮してしまったよ。
皆さんのおかげですよ。

>>70
JavaScriptのオンロードイベント利用で、
フォームにフォーカスをあてるというのは、
ナイスアイディアだね。
ちょっと目から鱗。

tabindexを0に指定することで、
これと同じ挙動が得られるなんてのは、
いくらなんでもやり過ぎかなあ？

ブランクの必須箇所にalertを出すのはポピュラーだけど、
ここでフォーカスするのもいいね。

勉強になった。ありがとう。

>>71
>>72
残念ながら、世間の人たちはaccesskeyも
tabindexもlink要素も知らないと思うよ。
正直このスレを立ち上げたときは、
誰からも相手にされないのではないかとさえ思ってた。

accesskeyやtabindexはマイナーなので、
利用に関するマナーやガイドラインなんかが、
ほとんど整備されてない状況だと思うんだ。
大体の慣例はあるけれども、
割り当てられているキーも
恣意性に寄りすぎているところが多い。

なので、自分がaccesskeyを設定しようと考えたときに、
迷ってしまったんだ。
その迷いを取り払いたい、いろんな例を知って、
スタンダードに近いものを作り上げたい。
それがこのスレの第一動機でした。

でも、これらが周知のものになると、僕も嬉しい。
そうなってくれたらいいなと、本気で思っている。
77 ：1 ：01/12/01 23:07 ID:l8SIorwQ: >>73
OmniWebだね。忘れてたわけじゃないんだ。
なので、メールを送るときには、Omniにも送るよ。
MSにも当然送るよ。駄目なときは駄目とあきらめる。
でも、はじめる前からあきらめちゃ駄目だよね。
なので、頑張ってみるよ。

自動キー割り当てが各社ばらばらに始まると、
結局はブラウザごとに全然違う挙動になってしまいかねない。
これはちょっと望ましくないので、
W3Cにまでメールを出すのは、正直やり過ぎかな？
でも、出してみようと思うよ。

ナビゲーションの「戻る／進む」と
link要素の「前ページ／次ページ」は
確かに紛らわしいかも。
僕も、最初はなにがなんだかわからなかった。
でもこれも慣れなのかと思うけどね。

>>74
ここをまとめてひとつのサイトですか。
僕がやるには、正直不遜な感じがしてしまうよ。

過去ログ倉庫にいくまではここで続けてみるよ。
やはり2chの知名度と人の多さというのは、
大きな力だと思う。

でも、最後にはひとつにまとめたものを作りたいと思うよ。
その時には、74さんのあげてくれた項目を反映したいね。

>>75
IEにおけるタブを使ってのフォームナビゲーション。
便利な使い方を教えてくれてありがとう。

実際こういうことは知らなかったよ。
おかげで、仕事の能率が上がる。有り難いです。

こういった、すでに用意されている機能を
開拓する必要もある。素直にそう思った。

基本に立ち返らせてくれた。ありがとう。
78 ：1 ：01/12/04 00:03 ID:AgJBKsmh: >>75
ごめん、ずっと心にひっかかってたことが。
MacIEの話だよね。
WinIEの話だと思って、
opt+tabっていうけどWinにoptなんかあったっけ、
ああそうか、altのことか、
けど、alt+tabって窓切り替えだよねえ。
あ、MacIEの話だ。とひっかかりがとれた。

ごめんなさい。大勘違い。

基本中の基本：人の話は正しく聞く
79 ：Name_Not_Found ：01/12/08 21:01 ID:QcpbLuGU: 2ちゃんねるにはレス番号ごとにtabindexがあったら便利だなーと思います。
80 ：Name_Not_Found ：01/12/09 01:46 ID:w0CXnRhK: >>79
かちゅ～しゃならできるよ(知ってたらｽﾏｿ)

アクセスキーもタブインデックスも、2chのようなよく利用するページではかなり便利だね。
2chの他によく利用するページといったら、データベースとか検索サイトかな？
81 ：1 ：01/12/18 11:33 ID:TEQpMhUZ: みんな、ご無沙汰。1です。やっと時間が取れたよ。

以前にいっていた、link要素を解釈してショートカットキーを設定するというアイデア。
各企業、団体に提出する英文の作成、完了したよ。
とりあえず以下に掲げてみるので、一度見てみてよ。

問題なければ、今日明日中には送信したいと思ってる。
クリスマスまでに間に合って、ちょっとほっとしてるよ。
82 ：1 ：01/12/18 11:36 ID:TEQpMhUZ: Subject: about the use of accesskey and link element

Dear Sirs.

We had an occasion to discuss the use of the accesskey attribute on a BBS named 2 channel.
We had an idea and we would like to propose it to you.
We gathered from our discussion that user agents should offer us a system of consistent
shortcut keys to navigate. At present, site owners arbitrarily set the accesskey, for example,
both Home page and Help page are assigned arbitrarily to the H key, so we users cannot get
a universal operation system and cannot learn by our experience on the accesskey. We do not think
the condition is desirable.
We hope that you producers of user agent add to your product a function which interprets
the link element and assigns it appropriate shortcut keys. The use of the link element is more common than
the use of the accesskey attribute and it is much less arbitrary. So we think the link element is
suitable for automatic allotment of shortcut keys.
It is difficult for us to realise this idea, but it is possible for you. We sent the same e-mail to the following
organisations and companies: iCab company, Microsoft Corporation, The Mozilla Organization, Netscape,
The Omni Group, Opera Software and The World Wide Web Consortium. We hope you will consider
our idea favourably.

Sincerely yours
My Name
My e-mail address

P. S.
A list of predominant examples of shortcut keys in our discussion.
[T]op page
[C]ontents
inde[X]
[P]revious
[N]ext
[H]elp
[S]erch
etc...
83 ：1 ：01/12/18 12:15 ID:TEQpMhUZ: 一応、それぞれの企業、団体のWebサイトと連絡先と思しいところを書き出してみたんだけど、
どう？　これであってると思う？
あからさまに間違ってそうなのがあったら、指摘してほしい。

iCab company
http://www.icab.de/
mailto:info@icab.de (concerning the concept, marketing etc: )

Microsoft Corporation
http://www.microsoft.com/
http://register.microsoft.com/mswish/suggestion.asp?from=cu&fu=%2Fisapi%2Fgomscom%2Easp%3Ftarget%3D%2Fmswish%2Fthanks%2Ehtm

The Mozilla Organization
http://www.mozilla.org/
mailto:suggestions@mozilla.org

Netscape
http://www.netscape.com/
http://home.netscape.com/feedback/product.html (Product Feedback)

The Omni Group
http://www.omnigroup.com/
mailto:info@omnigroup.com (- For business queries or website comments)

Opera Software
http://www.opera.com/
http://support.opera.no/bin/customer (Support Desk)

The World Wide Web Consortium
http://www.w3.org/
mailto:web-human@w3.org (Tim Berners-Lee, W3C Director@Do you have a technical comment?)
84 ：Name_Not_Found ：01/12/18 22:07 ID:YrjPbxAM: ｶﾞﾝﾊﾞﾚあげ
85 ：：01/12/18 22:56 ID:Kphf2uHr: >82
とりあえず [S]earch．あとは見てない，というか，英語板にでも行くほうがよいのでは？
86 ：1 ：01/12/18 23:45 ID:7hentgp/: >>85
[S]earchだよね。ありがとう。訂正しておくよ。

本文のほうは多分大丈夫。
今日、ちゃんとネイティブチェックを通したんだ。
職場、使いまくりだよ。

>>81-83
は、ミス訂正をして欲しいからだけではなく、
今までこのスレッドに関わってくれた人に対する、
報告のつもりが強いです。

でも、おかげで間違いが見つかったわけで、
本当にありがとう。

>>84
応援、ありがとう。頑張るよ。
出来るだけのことは、やってみる。
87 ：Name_Not_Found ：01/12/19 00:58 ID:ahD9vy14: >>86
Mozillaについては、Bugzillaにpostした方がいいのでは？
新機能の要望も受け付けてるようですし……
といってもあの使い辛さでは仕方ないですか（苦笑）
88 ：1 ：01/12/19 10:12 ID:wILQcYuq: >>87
Bugzillaで、新機能の要望受付をしてるとは、
思わなかった。
うん、そちらも検討してみるよ。
ありがとう。

とりあえず、時間がもしできたら、
上の英文の和訳を掲載するよ。
というか、当然やっとくべきことだったね。
89 ：1 ：01/12/19 10:52 ID:wILQcYuq: 和訳ができたよ。

accesskeyとlink要素の使用について

拝啓

私たちは2チャンネルという掲示板で、accesskey属性の使用について話し合う機会を持ちました。
私たちはあるアイディアを得て、それをあなた方に提案してみたいと思ったのです。

私たちは話し合いによって、ユーザーエージェントが一貫したナヴィゲーションの
ショートカットキー体系をわれわれに提供するべきだと、結論しました。
現状では、サイトオーナーが恣意的にaccesskeyを設定しています。たとえば「ホーム」ページと
「ヘルプ」ページの双方に、「H」キーが恣意的に割り当てられているようにです。そのため
私たちユーザーは普遍的な操作体系を得ることも、またaccesskeyを経験から学ぶこともできません。
私たちは、この状況が望ましいとは思いませんでした。

私たちは、あなた方ユーザーエージェント製作者たちが、あなた方の製品に、link要素を解釈し、
それにふさわしいショートカットキーを割り当てる機能を加えてくれるよう、望んでいます。
link要素の利用は、accesskey属性の利用よりも一般的で、より恣意的ではありません。
なので私たちは、ショートカットキー自動割り当てには、linkエレメントがふさわしいと考えています。

このアイディアの実現は、私たちには難しいですが、あなた方には可能です。
私たちは同様のe-mailを以下の組織、企業に送りました。iCab company、マイクロソフト・コーポレーション、
Mozillaオーガニゼーション、ネットスケープ、オムニ・グループ、オペラ・ソフトウェアそしてW3Cにです。
私たちは、あなた方が私たちのアイディアに賛同し、検討してくれることを望んでいます。

敬具
My Name
My e-mail address

追伸
私たちの話し合いで提出された、有力なショートカットキーの例をリストにしました。
[T]op page
[C]ontents
inde[X]
[P]revious
[N]ext
[H]elp
[S]earch
等等
90 ：Name_Not_Found ：01/12/19 12:20 ID:Z/mhvweS: いいねー
91 ：Name_Not_Found ：01/12/19 12:39 ID:D7z+ad3+: Web管理人が独自にショートカットキーを割り当てることが出来るaccesskey属性。
その割り当てが、てんでばらばらという点で何か共通したものを望む。
link要素にアクセスキーを埋め込むことが出来るなら
全てのショートカットキーとまでは行かなくても
そこそこ共通したキー割り当てが出来て
サイト間でキー操作の統一が出来る。
でも、現状ではlink要素にアクセスキー埋め込むことが出来ない。
だからHTMLの指針を決める組織とブラウザを作ってる団体に
お願いメールを送りましょう。

こゆことですか？
92 ：50（iCabユーザ） ：01/12/19 13:32 ID:VHJ5Kvca: いつのまにか、話が進んでるっ

(･∀･)ｲｲ!ねぇ
行動力のある>>1さんに乾杯！

まずW3Cあたりが仕様を決定してくれるといいなぁ。
93 ：50（iCabユーザ） ：01/12/19 14:05 ID:CVjzUiGu: そうそう、忘れてた。

mozillaに関しては、本家の.orgでもいいけど、
http://mozilla.gr.jp/　に提案してみるのはどう？
メーリングリストなんかで意見を募ってるみたいだけど。

日本語が通じるから、
このスレ自体を読んでもらう事もできそう。
94 ：Name_Not_Found ：01/12/19 14:49 ID:JNQDYI07: 結局こういうのが一般的には関の山かとおもいます

<li><a href="top.html" accesskey="1">[1]トップメニュー</a>
<li><a href="http://2ch.net/" accesskey="2">[2]ちゃんねる</a>
95 ： ◆AubwG1Yw ：01/12/19 14:52 ID:03h10RFT: 1の喋り方が凄く素敵sage

ちなみにaccesskeyは適当にしてます。
[T]opとか。
96 ：1 ：01/12/19 15:15 ID:wILQcYuq: >>91
おおむねそんな感じの理解でいいよ。
でも、link要素に関してはちょっと違う。

link要素にaccesskeyを設定したいのじゃなくて、
link要素のrel属性の値を参照して、
適切なショートカットキー割り当てを望みたい。
そういうことなんだ。

rel="prev"なら[P]、
rel="next" なら[N]を割り当て、
って感じでね。

ことば足りなかったかなあ。わかりにくかった？

>>93
mozilla.gr.jpかあ。
日本語が通じるんだったら、
それに越したことないよね。

一度行ってみます。

>>90
さんも、
>>92
の50さんも、応援ありがとう。
mail欄の応援も見てるよ。うれしいよ！

そして、参加してくれてるみんな、ありがとう。
みんながいなければ、僕はここまでがんばれなかったよ。

日付を見れば、明日がちょうど一ヶ月目なんだ。
だから、明日メールを送ろうと思ってる。
97 ：1 ：01/12/19 15:36 ID:wILQcYuq: >>94
数字によるナヴィゲーションだね。
うん、そういう使い方もよく見かける。
数字のいいところは、
そのユーザーエージェントが持ってる
固有のショートカットと
ぶつかりにくいところだと思う。

だから、数字のナヴィゲーションもありだよね。

でも、accesskeyの実際を見てみると、
意外に文字によるナヴィゲーションが多いんだ。
そしてそれぞれが、悩んだり考えたりした末に
つけたんだなという工夫が見えてきたりする。

でも、ユーザーエージェントがlink要素なんかを解釈して、
一律にショートカットキーを割り当ててくれたら、
一般サイトオーナーはaccesskeyに振り回されることも、
場合によれば、accesskeyを設定することさえいらなくなる。
それだけでなくて、ユーザーも
いろいろあるショートカットキーのバリエーションに
振り回されなくなるんだ。

これって結構よくない？　という話になってるかな。

>>95
accesskeyを適当にというけど、
[T]opはぜんぜん適当じゃない。
いい感じだよ！

> 1の喋り方が凄く素敵sage

ほんと？　なんか照れるよ。
98 ：Name_Not_Found ：01/12/19 15:40 ID:rFTYF64u: >>97
現在、携帯端末では数字のアクセスキーしか受けつけないのでは。
将来性を考慮したらアルファベット式は再考すべきかも。
どっちにしろ好みもあるし、あらかじめ統一しろってのがそもそも無理ある気もします。
99 ：Name_Not_Found ：01/12/19 16:16 ID:cCs79jQN: CSS3（策定中）でも定義されてますね。
http://www.w3.org/TR/2000/WD-css3-userint-20000216

> 5.2.1 Key equivalents: the 'key-equivalent' property
> 5.2.2 Tabbing order: the 'tab-index' property
100 ：1 ：01/12/19 16:44 ID:wILQcYuq: >>98
そのサイトが対象としているユーザーの環境を
配慮するのは、必要だね。
だから、モバイルフォンでアクセスするユーザーが
いることが分かってれば、当然、
accesskeyは数字になるよね。

accesskeyを事前に統一しようという気は、
僕にも、そして多分いままでここに参加していた人たちにも、
なかったと思うよ。
多様すぎる（といってもいいよね）accesskeyから、
ある程度標準のものを抜き出して、
それを一応の目安としてみたい、
というのが、このスレッドの趣旨だったから。

それと、上の英文はちょっと別ね。
あれはaccesskeyと同様の機能を、
ユーザーエージェントにlink要素を解釈してもらって、
実現しようというものだから。
だから、これはそれらPC用ブラウザに限定される話なんだ。

>>99
accesskeyがCSSで実現できるなら、
>>98
の問題も、解決するよね。
すごくいい感じ！

media属性をうまく使ってやれば、
PCならPCに適応した、
モバイルならモバイルに適した
accesskeyを割り当てられる。

これがlink要素にも使えたなら、
すぐさまユーザースタイルシートを書くのに･･････
101 ：Name_Not_Found ：01/12/19 20:27 ID:ZWKSLNv8: ヤコブ先生はどう考えているのだろうか。
102 ：1 ：01/12/20 16:34 ID:6r/fNNfg: 送信完了しました。

ただ、ちゃんと正しいところに送れたかどうか、
とてつもなく不安なんだよね。

でも、送ることは送ったよ。
返事があれば嬉しいけど、
反面返事を怖れてるのも事実。
不安だなあ。
103 ：50（iCabユーザ） ：01/12/20 16:53 ID:1burOZnz: 返事が楽しみだなぁ。>>1さんありがとう。

私はいつも他力本願だから、その行動力が頼もしく感じます。
104 ：Name_Not_Found ：01/12/20 18:02 ID:/pErEqmM: 1の行動力age
105 ：Name_Not_Found ：01/12/20 18:34 ID:5TO9w5gy: なんて爽やかな1なんだ
106 ：Name_Not_Found ：01/12/21 06:51 ID:p7+qCQXx: たしかに、なんか魅かれる喋りかた(書きかた?)だネ。
応援してますよん。
107 ：Name_Not_Found ：01/12/21 07:17 ID:9h0cQWcO: このスレ知らなかった。何でだろ。

ざっと読んでみて思ったのは、
「>>1はエンターテイナーだ」ということ。

アクセスキーはね。
自分も信者気味なソース書いてるけど、どうも設定しづらくて困る。
設定しづらいものが使いやすいものになる筈ない、と結論付けてパスしたよ。
108 ：1 ：01/12/26 15:40 ID:S3TTSs/m: ちょっと、お休みをいただいていました。

>>101
ヤコブ・ニールセンだね。
彼の本は僕も買って読んだけど、
accesskeyに関する指針は、
明確に打ち出されてなかった。
もしかしたら、
accesskeyに関する良案でも、
どっかで発表してるのかもしれないね。

あるかどうか、ちょっと気をつけてみるよ。

>>103
返事は楽しみのような不安なような。

現在、クリスマス明けの時点では、
一通の返事も受けていないんだ。
厳密にいうと、
Operaからの自動返信が一通。

長い目で見ていったほうがよさそうだね。
それと同時に、
使いやすいaccesskeyとはなにかを、
もう一度考え直すのもよいかもしれない。

>>107
やっぱり、accesskeyって設定しづらいよね。
それで、僕も最初は敬遠してた。
というか、現状でも少々疑問を感じているくらいなんだ。

僕の疑問は、自分の設定したkeyが
本当に使いやすいかどうかということ。
それと、HTMLの大本を考えると、
論理的なマークアップにはまったく関係のない、
accesskeyという属性そのものに関して、かな。

なので、CSS3でaccesskeyを設定できるようになったというのは、
僕にとってはかなりの朗報だった。
けど、CSS3非対応ブラウザのことを考えて、
きっと僕はaccesskeyを使いつづけるんだろうな。

とりあえずaccesskeyの評価は、
普及してから、だよね。
気長にいこうよ！

>>104-107
応援ありがとう！
みんなの応援があって、僕はがんばれたんだよ。
109 ：MOULIN ◆ROUGEr/U ：01/12/30 02:13 ID:AC6qUqu1: 応援ｱｹﾞ
110 ：1 ：01/12/30 16:57 ID:RsBgJgyL: >>109
アリガト

一応報告しますと、
自分の方ではまだなんの動きもでてないよ。
職場の方ではわけの分からん対立軋轢が発生。
accesskeyやtabindexがどうこうといってられるような
状況ではなくなった。
屑HTMLを書き散らす人間が、
どうしても自分で運営したいとごねているんだ。
分割運営案を提案。分離してもらう予定。

ここで言うことじゃなかったね、ごめん、ただの愚痴だったよ。
現実は思ったようにいかなくて弱ることが多いんだけど、
せめてここだけでも、
みんなで理想的な環境をめざして、
がんばりたい。
難しいとは思うけど、
それでもがんばりいたい。
111 ：Name_Not_Found ：01/12/31 01:30 ID:nGfFDFLE: 参考になりました。アリガト
112 ：1 ：01/12/31 02:08 ID:KPev+pdZ: >>111
このスレッドを参考にしてくれたんだね。
うん、ありがとう、僕の方こそ嬉しいよ。
113 ：Name_Not_Found ：02/01/05 14:06 ID:jcCRXiqx: ちょっとこのスレageたい
114 ：1 ：02/01/05 15:02 ID:2XhgAINu: >>113
このスレッドを上げたいのかい？
うん、ありがとう。思わずきみを抱擁したい気分だよ。
そして熱い口付けを‥‥おっととっと火傷するぜ、ベィベェ。
115 ：Name_Not_Found ：02/01/05 15:07 ID:35P9UQ5I: 誰だよ（藁
116 ：1 ：02/01/05 23:38 ID:vj6yFkPf: >>113
ありがとう。
新しい動きがない以上、
自分からは積極的にあげないつもりなので、
こうやってあげてくれると正直嬉しいよ。

一応報告しとくと、
新年明けて、まったく動き無し。
このまま埋もれてすたれるんじゃないかと思ってた。

動きを待つばかりじゃなくて、
自分から新しい発想やなんかを
押しだしていかなければいけないと思っている。

けど、今はなにも思いつかないので、
とりあえず近々、
このスレッドの動きをまとめてみるよ。

>>114
もしかしたら、僕ってこんなふうに見えてるの？
ちょっとショックかもなあ。

ともあれ、新年もなんとか明けたわけで、
みんな、今年もよろしく。
117 ：Name_Not_Found ：02/01/05 23:49 ID:JxIePMOj: accesskeyが基本的に不可視だから問題になっているって点もあるな。
UNIX TerminalやDOSのエディタみたいにキーと機能を常に表示させていれば
あるいは使い易くなるかも。もちろんposition:fixedで。

そう言えばOmniWebはrel=NextとPreviousに林檎+→と林檎+←を当ててた様な記憶が。
118 ：1 ：02/01/06 00:16 ID:zJAdRinh: >>117
accesskeyのキーバインドを、
画面上に常に表示しておくというのはいいアイデアかも。
画面の下とか、どこか邪魔にならないところに
置いておけばいいんだし、
印刷時にはdisplay: noneにしとけば問題もないだろうし。

これは一度試してみよう。面白そうな気がする。

> OmniWebはrel=NextとPreviousに林檎+→と林檎+←を当ててた様な記憶が。

これは、ちょっといいかも。今度、チェックしてみるよ。
今自宅なんで、OmniWebは動かないんだ（OS9なんだよ）。
119 ：Name_Not_Found ：02/01/06 00:32 ID:SDPmf0AJ: ｺﾞﾒｿﾅｻｲ　使っていません
120 ：Name_Not_Found ：02/01/06 00:49 ID:TwYG8OQ9: >>117-118
これ使おう！・・・acceskeyを今まで敬遠していたものより。
121 ：1 ：02/01/06 01:01 ID:zJAdRinh: >>119
いや、あやまる必要はないと思うよ。
それを採用するしないは、
あくまでサイト作成者の思うところによって
変わるわけなんだから。
実際僕も、accesskeyの存在を知りながら、
以前は使っていなかった。

今僕が悩んでいるのは、
link要素にしか記述していない、
サイトについてページと著作権ページへのリンクを、
body内のどこに置こうかということ。

そんなわけで、僕もaccesskeyに関しては、
全然駄目なんだよ。

>>120
このアイデア、かなりのものだよね。
アンカーに(N)みたいにして、
accesskeyの値を書いている以上に、
うったえるものがあると思う。

これは、accesskeyの啓蒙にもなる。
すごいことだと思う。

なので、僕の課題は、
このアイデアをどう活かすか。
うまく活かしたいと思うよね。
122 ：Name_Not_Found ：02/01/10 05:45 ID:qsLAeEIw: ちょっとageておくね。
123 ：Name_Not_Found ：02/01/10 20:30 ID:Okkdzgpq: みんな、閲覧環境のキーボードはASCIIキーボードだと
決めてかかってるけど、実際にはテンキー+α程度の
携帯電話とかもある訳ですよね。

accesskey="A"とかそういう記述自体が環境依存的で、
望ましくないと思うんだけど。

どうしてもそういうものが閲覧者にとって必要である
ならば、閲覧環境側で自動的に割り振って、それを
表示する機能を搭載すれば良い話だ。コンテンツ製作側が
割り振っておく事は有益ではないばかりか、有害ですらある。
124 ：Name_Not_Found ：02/01/11 01:00 ID:FIKg6eDN: >>123
そーなのよ。
で、>>89なのよ。
もしや、ドコモとかにもメールしてもいいのかな？
125 ：1 ：02/01/11 01:07 ID:p20HjCU9: >>123
いや、それは誤解だよ。

当初はたしかにPCからのアクセスを
想定していたかもしれない。
けど、それにたいする批判的意見もたくさん出て、
方向は修正され続けてきたんだよ。

たとえば、
accesskeyの値として数字を設定するという話は、
>>19-20
携帯端末でのアクセスを考えるなら数字がよいだろうという話は、
>>98
accesskeyがCSSでサポートされるという話は、
>>99
UAのaccesskey自動割り当ては、
>>35
で、すでに提案されてるよ。

UAによるaccesskey自動割り当ての限界は、
現時点でのaccesskey自動割り当ての手がかりとして、
link要素を参照する以外にない、ということなんだ。
君のいうように、
実際accesskeyを割り当てるのは、
個別のサイトオーナーの恣意性のもとではなく、
より一貫性の高い設定を与えることのできる、
UAのほうが望ましいのではないかという意見は既出だ。

でも、だからといって、サイトオーナーが、
すぐさまaccesskeyを割り振っておくことが有害である
と結論するのは、ちょっと性急すぎるよ。
少なくとも、accesskeyへのキー割り当てに悩み、
それでもより一般性の高いものを
求めようとしている人たちに関しては、
その批判は当たらないよ。

現在、accesskeyに関する混乱が収まらないのは、
一定の方向性というのがないからなんだよ。
でも、だからといって、混乱しているからといって、
もしかしたら何人かのユーザに対して
有益であるかも知れないものを求めること、
その気持ちを諦めさせる理由にはならないよ。
そして、このことによって非難される謂れもないと思うよ。
126 ：1 ：02/01/11 01:08 ID:p20HjCU9: 続き

さて、現在のaccesskeyが
決して望ましいばかりのものではないということには、
僕も同意するよ。
とりあえず現在の問題点は、
多様な閲覧環境に対応できないこと、
これが最大のものだと思う。

でも、僕はこの点に関しては、
CSS3でのaccesskeyサポートに期待してる。
CSSでなら、media属性によって、
少なくとも閲覧環境の違いに対応する
accesskeyを提示することができるしさ。

そして、その時にはaccesskeyを
適用可能な要素に関しては、
ある程度普遍的なclassを与えられると
いいなと思ってる。
もちろんこれは、ユーザスタイルシートで、
閲覧者が自由なaccesskeyを設定できるから。

少しでもよい方向にむかうように、
考えていこうよ。

>>122
サンキュ！
127 ：1 ：02/01/11 01:11 ID:p20HjCU9: >>123
いや、それは誤解だよ。

当初はたしかにPCからのアクセスを
想定していたかもしれない。
けど、それにたいする批判的意見もたくさん出て、
方向は修正され続けてきたんだよ。

たとえば、
accesskeyの値として数字を設定するという話は、
>>19-20
携帯端末でのアクセスを考えるなら数字がよいだろうという話は、
>>98
accesskeyがCSSでサポートされるという話は、
>>99
UAのaccesskey自動割り当ては、
>>35
で、すでに提案されてるよ。

UAによるaccesskey自動割り当ての限界は、
現時点でのaccesskey自動割り当ての手がかりとして、
link要素を参照する以外にない、ということなんだ。
君のいうように、
実際accesskeyを割り当てるのは、
個別のサイトオーナーの恣意性のもとではなく、
より一貫性の高い設定を与えることのできる、
UAのほうが望ましいのではないかという意見は既出だ。

でも、だからといって、サイトオーナーが、
すぐさまaccesskeyを割り振っておくことが有害である
と結論するのは、ちょっと性急すぎるよ。
少なくとも、accesskeyへのキー割り当てに悩み、
それでもより一般性の高いものを
求めようとしている人たちに関しては、
その批判は当たらないよ。

現在、accesskeyに関する混乱が収まらないのは、
一定の方向性というのがないからなんだよ。
でも、だからといって、混乱しているからといって、
もしかしたら何人かのユーザに対して
有益であるかも知れないものを求めること、
その気持ちを諦めさせる理由にはならないよ。
そして、このことによって非難される謂れもないと思うよ。
>>124
フォロー、ありがとう！
すごく、嬉しかったよ。

というわけで、ドコモとかにもメール出す？
面白いかも知れないけど、
ちょっと怖い気もするなあ。
128 ：1 ：02/01/11 01:14 ID:p20HjCU9: ごめん、消しそこなった文章を、
再送信してしまった。
初歩的なミスなんだけど、
かなりみっともないよね。

すごくごめん。

それと、
僕は123の彼をせめるつもりはないんだ。
できるだけ真摯に対応したいと思っただけなんだ。
それだけは分かって欲しい。
129 ：120 ：02/01/11 04:09 ID:0HTk9cW2: @media handheld がまともに使えればいいねぃ。。。
130 ：1 ：02/01/11 09:09 ID:8MsDbD0Y: >>129
うん、そうだねぃ。
このあたりは、handheld UAメーカーが対応してくれるのを、
気長に待つしかないのかなあ。

もし、a要素なんかに設定されているaccesskey属性が、
CSSの提供するaccesskey属性に上書きされるのなら、
おそらくCSS対応の点で携帯端末よりも前進的と思われるPCに向けては、
accesskeyをCSSで提供したいと思うよ。

例えば、
<a href="example" class="next" accesskey="6">
見たいなかたちにしておいて、
a.next {key-equivalent: accesskey-N}
を設定しとくみたいにね。

現状では、希望的観測でいきましょう。
131 ：Name_Not_Found ：02/01/11 10:11 ID:93n8VRdv: >>125
> UAによるaccesskey自動割り当ての限界は、
> 現時点でのaccesskey自動割り当ての手がかりとして、
> link要素を参照する以外にない、ということなんだ。
A 要素は確か LINK 要素と同様に rel 属性を持っていたと思う。
<a href="example" rel="next">
という方向性もあるのかも、とふと思った。
132 ：1 ：02/01/11 10:52 ID:8MsDbD0Y: >>131
ほんとだ。
Strict DTDを見てみたら、
確かにrelやrevも使えるよ。

となると、nextやprevは、
これらで示すのがよりよいよね。

アンカーやリンク要素を用いたナビゲーションに際しては、
UAがリンクタイプを参照して、
適切なaccesskey割り当てをしてくれるようになるといいなあ。

と、ほのかに希望しておこう。

重要な指摘、ありがとう！
133 ：Name_Not_Found ：02/01/11 11:47 ID:MA5jaacH: >>66-68でも少し言及されていますが、「accesskeyを自動割当する
UA拡張を自作」ってのは一般に通用しないからダメでしょうか…

一応、手持ちのUAで拡張できるかどうか調べてみました。

[Mozilla/Netscape 6]
　スキンを作るだけでできるかも。

[Windows版Internet Explorer 4以降]
　Browser Helper Objectsを使って拡張可能。

[Netscape Navigator(Communicator) 2.X～4.X]
　プラグインを作成すれば、キー入力による遷移などは可能。
　ただしlink要素を認識しないので、遷移先の取得は面倒かも。

[Opera (バージョン不明)]
　Netscape Navigatorと同じプラグインを使用可能。
　ただし、こちらもlink要素を認識しない。

[w3m/Lynx]
　ソースコードを修正する必要あり。
　w3mのソースを眺めてみたが、よくわからなかった…

Macは所有していないのでわかりません。ごめんなさい。
134 ：1 ：02/01/11 12:30 ID:8MsDbD0Y: >>133
自動割り当てを実現するUA拡張自作か。
チャレンジするに値する、
かなりいかす提案だよ。
ちょっとわくわくするね、
頑張ってみてもいいかも知れない。

完成したらフリーで一般頒布して、
それが大人気になればデフォルトで装備されるかも。
って、ぜったい大人気にはならないと思うんだよ。
難しいところ。

さて、僕はMacintoshユーザで、
熱狂的ではないiCabファンなんだ。
とりあえず、iCabのサイトにいってみたけど、
機能拡張の方法については不明だった。

正直このあたりは、
ソフトの機能拡張等に詳しい御仁に、
教えを乞いたいところ。
僕の手には、ちょっとあまってしまうよ。
135 ：1 ：02/01/11 12:40 ID:8MsDbD0Y: >>117
OmniWebで、Commnd+カーソルキーを試してみました。

これって、rel="next" or "prev"に対応してるんじゃなくて、
普通の「戻る」「進む」に対応してるみたい。
これが普通の挙動といえば普通なんだけど、
ちょっと残念と思わないこともない。
136 ：Name_Not_Found ：02/01/12 13:51 ID:gqK26sWN: 1さん、その後各ソフトウェア会社からの連絡はどうですかぁ～？
昨年暮れの今日じゃまだまだだよねぇ。返事が楽しみです。

http://pc.2ch.net/test/read.cgi/hp/991400015/

ここのスレで紹介されているIE(Win版)用のスタイルシート切り替え
ボタン（スキリボ）なんだけどIEでLINK要素もたどれるようにしてくれ
ます。
ダウンロードサイトには、ソースコードも公開されているみたいで、
僕は開発とか分からないけど、うまくいけば、アクセスキーの割り当
てとかできるようになるのかなぁって思うんだけど・・・
137 ：Name_Not_Found ：02/01/12 14:17 ID:SM6I6M0Y: まじめな話、返答は帰ってこないでしょう。
世間はそんなに甘くない・・・
138 ：1 ：02/01/12 18:43 ID:s/zTSKJx: >>136
残念ながらソフトウェア会社からは、
まったく返答無しです。
覚悟はしてたんだけど、
小さなソフトハウスとかからなら
返事があるかもと期待してた。

世の中思い通りにはいかんのだよね。
まったく、>>137 さんのおっしゃるとおりです。

でもいいよ。
連絡ではなく、機能追加で返答してくれたらいいよね！

ス切リボ、見たよ。ちょっとすごいね。
正直、感動してしまった。技術があるって、すごい！
僕は口ばっかりで技術無しだから、
こういうことができるってことに素直に憧れる。

あそこまで見事にできてるのなら、
アクセスキーの割り当ては可能だと思うんだけど、
実際にはどうなんだろう。

Macintosh用ソフトではリソースエディタを使って、
ショットカットをカスタマイズすることができたんだ。
（しくじると、ソフトを壊しちゃうけどね）
Windowsではどうなんだろう。
他力本願でいけないんだけど、なんか期待してしまうよね。

「ス切リボ」サイトURI
http://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/

いちおう、ここはaccesskey & tabindexスレッドなので、
上記サイトのaccesskeyをまとめたよ。

[S]tart
[C]ontents
[I]ndex
[P]rev
[N]ext
[A]ppendix
[M]ailto

他にもあるかも知れないけど、とりあえずはこれだけ発見。
リンクタイプを参照したと見られる、
非常にスタンダードなものだよね。

アクセスキーがついてたおかげで、サイト巡りが非常に楽でした。
こんな僕は、やっぱりキーボード派なんだろうなあ。

>>137
同意したくないけど、同意だ。
想像してはいたけど、
一件もかえってこないのは正直寂しいなあ。

まあソフトハウスからしたら、
マイルドなspamみたいなもんだったから、
しかたないよね。
139 ：H&A ：02/01/13 00:35 ID:vHku4SWm: >>136のスレッドでご紹介いただいた「ス切リボ」の作者でございます。
#>>133も私です
「ス切リボ」へのアクセスキー割り当ては、技術的には十分実現可能です。
>>134で心強いお言葉をいただいたことですし、実装してみようかと思います。

さて、>>133の続き。
どうやら、Macintosh版Netscape Navigator/Internet Explorer/iCab/OmniWebは
すべてNetscapeプラグインをサポートしているようです。
ただ、(Windows版でもそうですが)NetscapeプラグインだけではHTML文書自体へ
アクセスできないため、「文書にどんなリンクが設定されているか」を取得するのが
面倒そうです。
iCabだと「スタンダードリンクツールバー」があるので、これのボタン操作にキーを
割り当てることができればオッケーですね。
140 ：1 ：02/01/13 01:19 ID:TMGdw3m2: >>139
おお、作者のかたでいらっしゃいましたか。
サイトを>>139 さんの紹介で知って、
ものすごいショックをうけたんですよ。
自分は技術のない口先だけで生きている人間なので、
正直技術があるということに、
憧れて尊敬してしまいます。

リンク要素を解釈するiCabになら、
Netscapeプラグインを利用して、
自動accesskey生成が可能そう、ですか。
それは、僕にはきっと無理だなあ。

僕は、VBAでExcelやAccessを
ちょっと便利にするくらいしかできない。
勉強すればなんとかできるのかも知れないし、
踏み出さなければなにも変わらないことも分かってるけど、
これ以上、器用貧乏度を高めてもなあ。

でも他力本願はいけないと思っているので、
簡単にあきらめないで、
自分にもなにができるかをさぐってみます。

正直、ああいうクールなものができてくると、
僕も頑張らないとな、
と思う。切実に思う。

開発、頑張って下さいね。
期待してますよ！

自分がその恩恵にあずかれないのが、
本当、残念！
うちにあるWindowsマシンは、
人からもらったPC9821。CPUは486だった……かな？
141 ：Name_Not_Found ：02/01/13 04:00 ID:YYVXGh2K: キーボードを使わない場合のアクセスキーってどうするべきなんだろ。
音声で操作をしてる場合とか。

って、メディアタイプがきっちり使えるようになって
CSS みたいに外部で定義出来るようになれば
そこらへんは全部OKOKになりそうではあるね。
142 ：1 ：02/01/13 11:49 ID:F1ZF9edP: >>141
僕は音声操作にも詳しくないんだけど、
IBMのVIA VOICEだっけ？　は
コピーとか貼り付けとかの
簡単な操作を音声で指示できるし、
昔はMacintoshにも、
そういう音声操作の機能を追加するソフトがあった。
Macintoshのは、北米言語だけだったけどね。

だから、将来を考えれば、
accesskeyにキーワードを指定して、
そのvoice commandでのナビゲーションが
可能になってもおかしくない。

実際の話、
そういうのがどれだけ普及するかわかんないけど、
ちょっと未来的発想で、面白いよ。
その場合は、accesskeyword? accessword?
なんかそういう新しいかたちで、
出てきそうな気がするね。

GO next! とかいう感じかな？
143 ：Name_Not_Found ：02/01/13 11:58 ID:YYVXGh2K: >>142
しかし、
現在の CSS のプロパティの記述能力で
音声だのなんだのを一挙に記述するのは大変そうですね。
VoiceXML とかがつーんと利用出来ないかしらん。
144 ：Name_Not_Found ：02/01/13 12:09 ID:YYVXGh2K: なんか、散文ゴメンなさいって感じで。

>>142
結局のところ、コンピュータ様が認識出来るものは
なんだってトリガとして利用出来ちゃうわけで....
HMD の首振りで次のページとか、
モーションキャプチャで手振りで次のページとか。

でも結局は、ここで何度もでてるサイト毎のアクセスキーの違いが
問題になっちゃうんでしょうな。
他人がカスタマイズしたエディタを使わされてるみたいだし。

やっぱり<.. rel="next" ..> みたいなコンセンサスが必要だよねぇ。

コンテンツがいっぱいあって、
コンテンツ毎の頭文字を accesskey に当ててるなんて場合は
どうしようもない気もしますけど。

でも、スタイルシートの accesskey 属性で、例えば enumerated-assign み
たいなのが使えればいいかも。

ナビゲーションに利用するリンクタイプって、どんなのが欲しいですか？
145 ：Name_Not_Found ：02/01/13 12:25 ID:j4JHUieY: >>142
> accesskeyにキーワードを指定して、
> そのvoice commandでのナビゲーションが
> 可能になってもおかしくない。

a要素やlink要素内のrel属性か、或いはtitle属性を
探すのが筋だろうね。
146 ：1 ：02/01/14 00:24 ID:MGHMIJYJ: >>143
うん、音声認識のどうこうをあつかおうとすれば、
今のaccesskeyをどうこうという以上に、
大変でデリケートなことになりそう。
でも、いずれはこういったことも
自然に取り上げられ、考えられるようになるんだろうね。

VoiceXMLは、そのものは面白そうに思うんだけど、
どうも身近に感じてこないので、
僕はピンとこないんだ。
でも、HTMLが閲覧環境を問わないというのなら、
VoiceXMLで行えるようなサービスにまで、
飛躍したい。
でも、それはやっぱりUA次第なのかな。

>>144
>でも結局は、ここで何度もでてるサイト毎のアクセスキーの違いが
>問題になっちゃうんでしょうな。

>やっぱり<.. rel="next" ..> みたいなコンセンサスが必要だよねぇ。

>>145
>a要素やlink要素内のrel属性か、或いはtitle属性を
>探すのが筋だろうね。

なんか、話が戻っちゃったね。

このスレッドにおける、
昨年の一応の結論めいたものっていったら、
accesskeyなんてものは、
サイトオーナーが自由に設定するよりも、
UAが一貫したものを提供したほうがずっと便利だ、
というものだった。

自分が逆戻りしてしまっていたことに、
いわれて気付いているわけか。
僕はつくづく成長も変化もしないねえ、
溜息。
147 ：1 ：02/01/14 00:25 ID:MGHMIJYJ: >>144
>enumerated-assign

例えば目次ページなんかで、
リストアップされている項目ひとつひとつに
accesskeyがふられてることがあるけど、
僕はそれをあんまり利用しないんだ。
こういう場合は、tabで指定してることが多い。

コンテンツの頭文字でといっても、
そこになにがあるのかわからない時点じゃ、
いきなりアクセスするなんてことはないし、
tabで充分と思ってしまうんだ。

どうなんだろう。
こういうaccesskeyの使い方に
僕が慣れてないだけなんだろうか。

enumerated-assignができるとすれば、
olでひとつひとつ項目に入れられた
a要素に対して指定するのかな？
でも、これって項目の増減でaccesskeyが変わって、
あまり使いやすくないかも、と思ってしまう。

accesskeyは、
ある程度恒常的なものに指定されていると、
便利だな、と、
僕なんかは思ってしまうのです。
148 ：1 ：02/01/14 00:25 ID:MGHMIJYJ: >>144
>ナビゲーションに利用するリンクタイプ
ちょっとスレッドの議題からはなれぎみだけど、
関連することだし、問題ないよね。

僕は、もう現状のでお腹一杯かなあ。
だって、仕様書で紹介されているのでも
以下のとおり。
熱狂的でないiCabユーザである僕としては、
iCabの解釈するものを中心に考えてしまう。
それが、以下のとおり。

スタートがあって、目次、インデックスがあって、
前後関係が結構しっかりあって、
ヘルプやら検索やらおまけやら……

これ以上は、
僕の枯渇した想像力では生み出せそうにない。
もっと別のが欲しいという人、いるのかなあ。

いたら、教えてよ。
ちょっと僕も興味が出てきた。

■仕様書から
Alternate
Stylesheet
Start
Next
Prev
Contents
Index
Copyright
Chapter
Section
Subsection
Appendix
Help
Bookmark

■iCabが解釈するもの
home, start, top
contents, toc
begin, first
prev, previous
next
end, last
up
index
find, search
help
copyright
author, made
149 ：Name_Not_Found ：02/01/14 01:30 ID:nshQtBjN: >>148
更に言うと、それぞれを組み合わせることも出来ますからね……実装はともかく仕様上は。
"Next Chapter"とか"Alternate Contents"とか、もう殆ど自由自在。
これらをUser-Agentがきちんと解釈し、link typesに応じた適当なaccesskeyやらtabindexを振ってくれれば
いいんですけど……正直、組み合わせが多すぎ。

参考：
ttp://homepage.mac.com/syect/~howl/200110.html#d21
150 ：Name_Not_Found ：02/01/14 07:35 ID:nAal6A84: >>149
組合せられるってのを初めてしりました。
個人的には、section と subsection は構造化して記述したいから
link 要素で使う場合は使い辛い点ぐらいかなぁ。
151 ：139 ：02/01/14 14:14 ID:TqGKzzyd: HTML 4.01 Spec.には
> User agents, search engines, etc. may interpret these link types in a
> variety of ways. For example, user agents may provide access to
> linked documents through a navigation bar.
と書いてあるだけだし、組み合わせについての合意を得るのも難しそう
ですね。
152 ：参考までに ：02/01/14 17:25 ID:Z5uGt9Qp: http://fantasai.tripod.com/qref/Appendix/LinkTypes/ltdef.html
これ読むとhomeって制作者じゃなくってユーザーが設定するみたいだけど。

……どうやって？
153 ：Name_Not_Found ：02/01/14 17:41 ID:PxIzBJQL: >>152
http://www.kanzaki.com/docs/sw/dublin-core.html#rdf-html-link
http://purl.org/net/uriprofile/
みたいに（この例は"Meta" Link Typeだけど）、
自分で"Home" Link Typeの定義を書けばいいと思われ。

或いは、開き直って使うか。そこら辺の規定は殆ど有名無実と化してるし、
開き直って使っても特に問題は無いと思う。
154 ：152 ：02/01/14 19:56 ID:+EbYxnAb: >>153
すまんが、何の話？
俺が言ってるのは、製作者ではなく訪問者が設定するって話だが。
まぁそれも古いドラフトの事で、次のドラフトじゃ変わっているけど。
155 ：152 ：02/01/14 20:19 ID:+op6wwUP: >>154
あぁ、ごめんごめん、勘違いしてた。
Homeを設定するって、単に「ホームページ」のことじゃないの？
WWW_HOMEって、Mosaicか何かで「ホームページ」を設定する環境変数だったと
思うけど。
156 ：1 ：02/01/14 20:31 ID:/CPTYPXr: >>149-151
そういえば、組みあわせ可能だったね。
でも、現実的に、これらを組みあわせている人って、
どれくらいいるんだろう。

このlink要素というものを、
該当HTML文書に関連する他文書を示すものであるという
本質だけを考えて使うのならともかく、
現実的には、UAがサポートする機能に応じて、
限定的に使っているのがほとんどだと思う。

実際、僕もそうだし、多くはそうだろうし、
でも、真面目に組み合わせを考慮しようとすると、
UAはきちんと解釈できない……
これも、accesskeyを自由に設定可能という問題に、
ちょっとばかし似てるような機がするね。

UA製作者は、このあたりに関しては、
すぱっと割り切らざるを得ないだろうし、
設定するわれわれも割り切るべきなんだろうか。
少なくとも、僕は割り切るつもりでいるよ。

機械（ソフトウェア）が処理するということが前提なら、
もっと限定的なものにして欲しいと思うのであった。

>>151
一応読んでみたよ。
なんか、とんでもないことが書いてあるね。

HTML UAは、あらゆる著者の提供する「REL=HOME」の設定を、
無視すべきである。

これを読むかぎり、the userは閲覧者だよね。
じゃあ、このHOMEというのは、
ブラウザを立ち上げたときに最初に開かれるページ、
それをさすんだろうか？

とりあえず、例えばでいわんとするところが、
僕にはまったくわからなかった。
一体どういうことなのか、僕にはわかんないよ。

とりあえず、予約済みというリンクタイプ、HOMEは、
金輪際使うものかと決意したのであった。
157 ：1 ：02/01/14 20:34 ID:/CPTYPXr: >>152
やっぱり、「ホームページ」のことだよね。

でも、あの例えわかりにくいよ。
158 ：Name_Not_Found ：02/01/14 21:09 ID:8oLP6yOK: >>156
> とりあえず、予約済みというリンクタイプ、HOMEは、
> 金輪際使うものかと決意したのであった。
そんなに嫌わんでも……。例えば、
> REL=Home
> The link references a home page or the top of some hierarchy.
The link references a home page or the top of some hierarchy.
と言うHTML 3.0 Draftの意味で行けば、rel="Contents"との使い分けがはっきりして
便利だと思うけど。rel="Contents"は「そのページの見出し(top of this page)」なのか
「そのWebサイト全体の見出し(top of this site)」なのかよく分からない（ことがある）。

#まぁ、"Start Contents"や"First Contents"とすれば十分代替出来るような気もするけど。
iCabやらMozillaでは、"Home"をどう定義付けてるのかしら？

取り敢えず、私は「アホなUAに付き合ってたら、いつまで経ってもWebの進歩は無い！」と信じる派なので、
（今現在の）UAが解釈出来ない組み合わせでもどんどん使っていきたいと思う。
もちろん、来訪者を混乱させないように、他のナビはしっかり付けている（つもり）。

初心者の方はlink typeなんか知らないだろうから、混乱することは無い。
link typeを知っていてバリバリ使っている程のユーザーの方なら、説明すれば理解してくれるだろう。
……とか思った。甘い考えだろうけどさ。
159 ：1 ：02/01/14 21:47 ID:/CPTYPXr: >>158
HTML 3.0 Draftの解釈だと、いわゆるサイトトップになるよね。
これだと、わかりやすいし、使いやすいね。

僕の、職場で作っているサイトは、
トップページをHomeと表記してるんだ。
だから、リンクタイプはhomeを使ったほうが、
しっくりくると思う。
でも、現実にはstartを使ってる。

これは、ごくごく些細でつまらない理由による。
僕が、はじめてlink要素を意識したのは、
iCabがそれをサポートしてたからなんだ。
僕がiCabに装備されたHTMLチェッカーに、
警告やなにやを出されないようにサイトを手直ししたとき、
iCabの仕様にあわせてしまった。
そして、その際参考にしたのが、
次のサイトの、次のページだったんだ。
http://www2.tok2.com/home/icab/dokuzi/09.html

これって一首の刷り込みだよね。

ちなみにiCabのサイトでは、homeが使われている。
つまりiCabにとって、homeはstart, topと等価なんだ。

神崎正英著の『ユニバーサルHTML/XHTML』に、
主なリンクタイプの例として、
homeが紹介されていなかったのも、
刷り込みのひとつだよ。

ところで、上で紹介したリンク先で、
upが「章の頭」とされているんだけど、
これってどうなんだろう。

> 甘い考えだろうけどさ。

いや、考え方には幾種類もあるし、
別に甘いということはないと思うよ。

正直、僕のやり方、
UAの実装状況によって変えていくというのも、
とんでもない甘い、日和見主義だよ。
ただ、いろいろな考え方をしているのは当然、
大事なのは、そのどこかにあるだろうベストを模索し、
先に続く道を見誤らないということだと思う。

そういう意味で、
僕はこのスレッドでたくさん教えられた。
accesskeyだけでなく、
前進しようという意思を持つ大切さを、
教えられたと、心から思ってるよ。

ただ、今はなにか決め手に欠けてるね。
ブレイクスルーが欲しいと思う。
このlink typeから、次への一歩が見えるといいね。
160 ：Name_Not_Found ：02/01/14 21:57 ID:TqGKzzyd: >>158
> iCabやらMozillaでは、"Home"をどう定義付けてるのかしら？

手元にあるMozilla {Build ID: 2002011103}では、"Home"だろうが
"Start"だろうが"Top"だろうがすべて"Top"ボタンに割り当てられて
いました。

> 取り敢えず、私は「アホなUAに付き合ってたら、いつまで経ってもWebの進歩は無い！」と信じる派なので、
> （今現在の）UAが解釈出来ない組み合わせでもどんどん使っていきたいと思う。

たしかに、「このUAが解釈しないから…」として利用する要素・属性などを
限定していくのはあまり面白くありませんね。
ただ、組み合わせにある程度の合意がなければ他の人にも解釈されない
(あるいは、誤解される)場合があるのでは。
161 ：160 ：02/01/14 22:12 ID:TqGKzzyd: >>160
なんか意味不明。

> ただ、組み合わせにある程度の合意がなければ他の人にも解釈されない
> (あるいは、誤解される)場合があるのでは。

これは、たとえば"Start Contents"を
・複数ある目次文書のうち、先頭のもの
・当該文書の含まれる文書群にとって先頭文書であり、かつ目次となっているもの
のどちらに解釈するかが人によって異なるのではないか…と書きたかったのでした。
162 ：158 ：02/01/15 01:37 ID:mfLGuOxG: >>159（>1氏）
御丁寧に、ありがとうございます。
> ちなみにiCabのサイトでは、homeが使われている。
> つまりiCabにとって、homeはstart, topと等価なんだ。
そうなんですか。"Home", "Top"はまだしも、"Start"は意味が違うような。
> 『ユニバーサルHTML/XHTML』
そうですね。あれは、（HTML 4.01&XHTML 1.0の）仕様書がベースですから。
#別に"Home"が載っていないからどうこう……と言うつもりはありませんけど、
"Home"や"Top"と言った拡張も、紹介する程度でいいですから、隅っこに載っけて欲しかったなぁと言う気はしますね。
> upが「章の頭」とされているんだけど、これってどうなんだろう。
"Up"は一階層上へ行くとか、そう言う意味だと思っていました。
章の頭……パッと思い付くのは"Chapter Start"とか"Chapter Contents"でしょうか。うーん？
> ただ、今はなにか決め手に欠けてるね。ブレイクスルーが欲しいと思う。
そうですね……今複雑なlink typeを記述しても、解釈してくれるUAは皆無ですし。
Mozillaには期待しているんですけどねぇ……。

続きます。
163 ：158 ：02/01/15 01:49 ID:mfLGuOxG: >>160-161（>160氏）
> 手元にあるMozilla {Build ID: 2002011103}では、
おぉ、ありがとうございます。
いや、私が言いたかったのは、
「iCabやらMozillaでは"Home"をどう定義しているのか。
先の例で言えば、"top of this page"なのか"top of this site"なのか、或いは別の意味なのか？
どこかに、そう言うのを記したdocumentsは無いものか？」
と言うことなんですけどね。言葉が足りませんでした、すみません。

> "Home"だろうが"Start"だろうが"Top"だろうがすべて"Top"ボタンに割り当てられていました。
私の手元にあるMozilla {Build ID: 2001121803}でも確認してみましたが、同じみたいですね。
"Home"と"Top"の両方を記述すると、"Home"の方が優先されるようです。
しかし、さっきも言いましたけど"Start"は明らかに違うような……続き物の先頭に戻るのが"Start"では？
#例えば、小説の第五話から第一話に戻るのが"Start"で、小説の目次に戻るのが"Home"or"Top"or"Contents"と言う感じ。
> ただ、組み合わせにある程度の合意がなければ他の人にも解釈されない(あるいは、誤解される)場合があるのでは。
それは確かに、そうですね。皆が自分の考えで適当に使っていては、質の高いナビゲーションは提供出来ませんし、
ユーザビリティの向上などは望むべくもありません。
#私の意見としては、本当は、W3CでもIETFでもMicrosoftでもmozilla.orgでもいいですから、
link typeの使用と、組み合わせ方のガイドラインを出してくれると嬉しいんですけどね。
完璧とはいかないまでも、ある程度の合意は得られますし。

実際、「Alternate」「Prev」「Next」との組み合わせに対応するだけでも、自由度はかなり増すと思うんですが。
#「Prev Chapter（前の章）」「Next Chapter（次の章）」といった具合に。

> これは、たとえば"Start Contents"を～
そうですね……私ならば、「複数ある目次文書のうち、先頭のもの」を"Start Contents"として、
「当該文書の含まれる文書群にとって先頭文書であり、かつ目次となっているもの」は
<link rel="Start" ...>
<link rel="Contents" ...>
と言う風に分けて書く（"Start Contents"で一フレーズと言う考え）かと思いますが、160氏は
どうお考えになりますか？

すみません、凄い長文になってしまいましたね。
では、お休みなさい。
164 ：Name_Not_Found ：02/01/15 02:39 ID:7iLqCSCi: 実際問題として、next + chapterが「次の章」なのか「次のページで、且つ、章」なのか、といった部分の話は明確に定められてないわけでしょ。
仮に「次の章」のような表現ができるとしても、どれとどれであれば組み合わせ可能なのかということだって何も決まっていない。

あれこれ悩むくらいだったら、MozillaやiCabのようにリンクをツールバーに割り当てるよりも、
むしろリンクタイプをリンク先URIの横に表示して全部一様に列挙した方がまだ分かりやすいかもしれない、とか思ってしまう。
165 ：サーバーどう？ ：02/01/15 02:49 ID:uPkEhYtT: □□□□■■■■□□□□□■■■□□□□□■■■■□□□□
高性能、低価格のお奨めサーバーを是非ご利用下さい。

貴方御自身の専用ドメインも無料で取得、管理します。

複数のメールアドレスもご提供しています。その他

様々なサービスがお得なプランで取り揃えてあります。

http://eyes.mariansela.com/service/shopping/saba/index.html

□□□□■■■■□□□□□■■■□□□□□■■■■□□□□
166 ：Name_Not_Found ：02/01/15 08:53 ID:+w0TQSal: "next chapter" のような紛らわしいケースは
HTML 側としては title 属性で補えば済むんだろうけど。
UA としてはどうするのがいいんだろう？
167 ：160 ：02/01/15 09:33 ID:nsur9Nwv: >>163
> 「iCabやらMozillaでは"Home"をどう定義しているのか。
> 先の例で言えば、"top of this page"なのか"top of this site"なのか、或いは別の意味なのか？
>どこかに、そう言うのを記したdocumentsは無いものか？」
あ、「現状の実装がどうなっているか」ではなく「各UAメーカはリンク形式を
どう解釈しているのか」だったんですね。失礼しました。
Mozillaだったら、Bugzillaとかで議論されているような気がします。
# http://bugzilla.mozilla.org/show_bug.cgi?id=2800かな?
# 先頭部分しか読んでないので違うかも

> しかし、さっきも言いましたけど"Start"は明らかに違うような……続き物の先頭に戻るのが"Start"では？
> #例えば、小説の第五話から第一話に戻るのが"Start"で、小説の目次に戻るのが"Home"or"Top"or"Contents"と言う感じ。
たしかに、章の中ではその章の先頭文書を"Start"にするほうがふさわしい
かもしれません。
私は何も考えずに"Top"と同じ考えでいたのですが、考え直したほうが
よさそうですね。

> 160氏はどうお考えになりますか？
私は、単純に「Alternate以外は、複数指定された場合複数の役割を持って
いるだけ」と考えています。
つまり、"Start Contents"は「"Start"兼"Contents"」であって、LINK要素を
複数指定されたのと同じ→>>161の例では後者の解釈、と。
ただ、この考えだとAlternateとの一貫性がない…
168 ：160 ：02/01/15 09:43 ID:nsur9Nwv: >>164
> あれこれ悩むくらいだったら、MozillaやiCabのようにリンクをツールバーに割り当てるよりも、
> むしろリンクタイプをリンク先URIの横に表示して全部一様に列挙した方がまだ分かりやすいかもしれない、とか思ってしまう。
同意。rel/rev属性つきのLINK/A要素を抜き出して一覧にして、それぞれに
ショートカットを割り当てるという方が利便性が高いような気がします。

スレッドの趣旨に立ち返ると、「ユーザの利便性を高めるための仕組みが
HTMLには(ある程度)用意されているのに、うまく使われていない。そこで、
この仕組みの利用についてある程度合意をとればよりよいのではないか」
ということですよね。
ですので、仕様の解釈より「どう利便性を高めるか」というか、そういう点を
重視したほうがいいのかなと。

なんか言ってる事が支離滅裂ですね。すみません。
169 ：Name_Not_Found ：02/01/15 10:57 ID:nsur9Nwv: Piro氏の「N6 & Moz 用コンテキストメニュー拡張」が、Ver.2.1.20020114あたりから
キーボードショートカットを実装した模様。
http://www.cc-net.or.jp/~piro/works/_moz-extensions.html#keyboard-shortcut
170 ：1 ：02/01/15 22:30 ID:BYxVkDRr: なんだか、話が進んでて、びっくりした。
最近、ちょっと活発だね。

■リンクタイプの複数記述■
リンクタイプの複数記述に関しては、
僕はおそらく、よっぽどの合意が出ないかぎりは、
やらないと思う。
今までの僕の発言から見てもわかるように、
僕はかなり保守的。
現状の中で働かないものに対しては、
あまり積極的ではないんだ。

ただ、これでは駄目だと思うのも事実。
表現できる幅が極端に拡がる複数記述は、
UAという機械的なものではなく、
人間が評価できるようになればより
よく活用できるように思う。
この点においては、Lynxみたいに、
ページ上部に羅列されるかたちが、
わかりやすいのかも知れない。
>>164 氏のいうところって、
こういうことだよね。

でも、Lynxのリンク要素羅列は、
少なければいいけど、多くなれば
結構わけがわからなくなるんだよ。
僕はちょっと、それはいやかも知れない。

The Web Kanzakiに書いてあった。
> HTMLの「直接の利用者」は人間ではなく、
> ブラウザなどのコンピュータのソフトである
<http://www.kanzaki.com/docs/html/lesson1.html)
のなら、なんとかコンピュータソフトが
解釈できるようなかたちで落ち着いて欲しい。

だから、やはり
>>163 (158)氏がいってくれたように、
どこかの機関なりなんなりが、
ガイドラインを打ちだすべきだよね。
多分、話し合いはされていると思うけどね。
171 ：1 ：02/01/15 22:31 ID:BYxVkDRr: ■章の頭■
章の頭に関しては、
僕は今は "Up" にしている。
理由は、刷り込みという、情けないもんだけどね。

仮に小説を考えてみたら、
Startは小説の頭、いわば表紙、
Contentsは目次、
ChapterなりSectionなりは章節を表して、
本文の頭は "First" にしたい。
そして、
章の頭を表すために "Up" を使わないなら、
"Chapter First" という組み合わせで表現したい。

章というのを
ひとつのディレクトリと考えるなら、
"Up" もあながち外れてないとは思うけど、
この表現が「章の頭」に直結しないという点で、
わかりにくいというのが問題なんだ……よね。

>>168 (160)氏
全然、支離滅裂なんかじゃないよ。

> 仕様の解釈より「どう利便性を高めるか」というか、そういう点を
> 重視したほうがいいのかなと。
あくまで決まりは決まりであって、
その範囲の中で（あまり逸脱しないかたちで）
最もよい何かを求めているのが、
ここに集まっている人たちだと思う。

今は先行きが見えないから支離滅裂に思えるだけで、
いつかすべてが繋がって、
先に進む道が見えることを信じていこうよ。
僕は、
迷いが大きければ、それだけ答えも大きいと、
そう思いながらいきたい。

>>169
これって、>>66 のP氏なのかな？
そうでも、そうでなくても、
こういう機能が実現化するのは嬉しいことだし、
こういうところからすそ野が拡がっていくと、
僕としては、最高に嬉しいよ。

だから、Piro氏は迷惑に思うかも知れないけれど、
僕は最高度の感謝を贈りたい。
ありがとう！
172 ：p ：02/01/16 00:11 ID:UpmFb/Tv: ええっと。
キーボードショートカットからでも複数のリンクを選択できるようにしたので、
仕組み的にはchapterやsectionにもショートカットを指定できるようになったんですが、
実際やるとすると、それぞれどのキーを割り当てるのがベターでしょうか。
ご意見を頂ければ幸いです。
173 ：136 ：02/01/16 00:56 ID:UqqXU9nz: >>170
＞なんだか、話が進んでて、びっくりした。
＞最近、ちょっと活発だね。
これも1さんの人柄なんじゃないかなぁ。すごく好印象です～
僕はこのスレ立ったときからず～っと見守ってる人たちの一人
です。

話が前後しちゃって申し訳ないのだけれど、
Mac IEだったらページホルダを拡張した形というのもよいかも！
ページホルダ自体は、IE標準の実装だから、これ自身をあれこれ
かえるのってむずかしいよね（たぶん）。でももしここがいじれるの
であれば、ここを拡張してLINK要素を表示してキーを割り当てる
ってのも面白いかななんて思ったよ。

検索タブをGooglに変えてしまうことができるパッチがあったから
できるのかなぁ。でも僕には作れません・・・
174 ：1 ：02/01/17 00:19 ID:wnZ8mrzk: >>172
やはり、p氏 = Piro氏でしたか。

サイトの方は、確認してますよ。
有言実行の人ですね。感動的です。
今手元にはMozillaもN6もないので、
環境が整い次第試してみますね。

ページで確認したところでは、
Search: F3というのが斬新に思えました。
普段、ファンクションキーを使っていないので、
ないものと思ってるんだ。

しかし、ソフトウェアっていうのは、
こんなにもカスタマイズできるものだったのか……
すごい、目から鱗。

http://www.cc-net.or.jp/~piro/works/_moz-extensions.html#keyboard-shortcut
175 ：1 ：02/01/17 00:20 ID:wnZ8mrzk: >>173 (136)氏
技術的に可能かどうかは僕には分からないけど。
すごく面白そうな提案だね。

Mac IEのページホルダ機能。
こういう機能があるってこと、全然知らなかったんだ。
実は、僕は、便利機能はあまり使ってない。
ブックマークもしない、ものぐさものなんだ
（記憶に頼ってる。原始人か……）。

ちょっと感動したよ。
iCabのリンクマネージャと同様の機能。
どちらが先かどうかはおいておくとして、
多くのリンクが含まれているページで利用したら、
かなりの効力を発しそうだ。

でも、残念ながら、link要素は表示しないみたい。
やはり、IEはstylesheet以外は無視してるのか。
外部stylesheetを読むんだから、
その気になりさえすれば、
すぐにでも他のリンクタイプにも
対応できそうな気がするんだけど。
こういう考えは甘いのかもね。

ページホルダで「リンク」表示にすると、
ソースの確認ができなくなるんだね。
iCabのリンクマネージャのほうは、
リンク部分だけを抽出してHTML化してる。
そのときに、
上からaccesskeyを指定するとかできれば、
と思ったんだけど、
それは無理なのかもしんない
（a 要素に手は加えられていない）。

どちらにせよ、
自分に技術と知識がないということが、
とにかく歯がゆい、よ。

> すごく好印象です～

ありがとう。この言葉だけで、
僕はまだまだ頑張れそうな気がする。
技術的なところでは人におうところばかりだけど、
自分にできることが見つかったら、
立ち止まらないで進もうと思える。

ありがとう。
176 ：p ：02/01/17 01:27 ID:O8LRcupA: >>174
SearchがSでなくF3なのは、W/Sの見出し間移動（Operaのキーバインド）とかぶってしまったからで・・
Shift+Sあたりにできたらなァ。

>しかし、ソフトウェアっていうのは、
>こんなにもカスタマイズできるものだったのか……

XMLでUIを作ってJavaScriptで挙動を記述するというMoz(NS6)ならではですね。
シロウトでもWebページ感覚でサクサク作れるのが魅力。
Moz以外だと、CやVBなどの経験がない自分には満足に動く物すら作れません。笑。
177 ： ◆R4.ALMK. ：02/01/17 04:01 ID:BTtNnouN: >>52でリンクされてるトコの人です。

MacIE5のばやいは…どうだろう
拙作某べんりせっとでやってるように、AppleScript から JavaScript を発射すれば、
DOM 使って link 要素の href とか rel の属性値を IE に読み出させて、
AS に返せるんですよ。ただ、日本語文字列はバケちゃってどうにもならなかった。
でもって、GUI は AppleScript Studio で作ると。フローティング窓に
できればいいのだけど、ぼくにはそこまではまだ分からないっす。

…しかしそーなると、OSX10.1.2 以上専用になっちゃうという。
178 ：1 ：02/01/17 23:35 ID:gkZmjBOk: >>176
> かぶってしまったからで・・

このかぶってしまう問題というのが、
accesskeyには絶えずつきまとってきたと思います。
WinIEの場合、Alt+Dの回避不能型を筆頭に、
Altを押しっぱなしか、いったん離すのかという、
興味を持っている人相手になら有効でも、
そうでない人にとってはわずらわしいものになりかねないのが
accesskeyだったと思っています。

一般に全然浸透していないというのが、
そもそも問題なんですよね（いや、知る人ぞ知るでもいいのですが）。

ある程度浸透すれば、
よりよい機能を求める人も出ます。

興味を持った人、便利機能を求める人から、
H&A氏作成の「ス切リボ」であるとか、
http://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/
Piro氏作成の「N6 & Moz 用コンテキストメニュー拡張」
http://www.cc-net.or.jp/~piro/works/_moz-extensions.html
であるとかの、既存UAを便利化するツールを試し、
それら機能が有用である認知されるようになれば、
オフィシャルでも採用されるのではないかと。
僕は、それをひそかに望んでいるのです。

この意味で、ソフトウェア作家のかたがたは、
先陣に立ちよりよい状況に斬り込んでいく
存在であると、僕は思っています。

> シロウトでもWebページ感覚でサクサク作れるのが魅力。

この発言は、実に興味深い。
ちょっと頑張ってみようかななんて、
思いはじめたりなんかしてる。
でも、これ以上器用貧乏になって僕はどうする気なんだろう。

はじめて見ると、面白そうですね。
今はまだ、他人事みたいにいっている僕ですが。
179 ：1 ：02/01/17 23:35 ID:gkZmjBOk: >>177 (>>52でリンクされてるトコの方)
実は、ファンです。
以前、CSSを導入しようとしていろいろかぎまわっているとき、
随分参考にさせていただいたのです。
結局僕は、必要最低限しか指定しないという選択をしましたが、
迷っていた昨年秋、随分助けられました。

さて、べんりせっとでやっているような仕組みでもって、
link要素からrel属性、href属性を読み出し。
フローティングウィンドウに配置したボタン群から、
MacIEを操作できる可能性があるのですね。

なんだか、文系生活にどっぷりの僕には
敷居高めの話になっているのですが、
不可能でないとすれば、
なんか、どことなく頑張りたくなってくる話です。

OSX10.1.2専用は、致し方ないとしましょう。
まずはできることができると嬉しい。
僕になにができるか分からないけど、
とりあえず、明日職場ででも、
AppleScriptを使ったIEの操作を、
実験してみます。

なんか、動きが出てきたものだからハイになっちゃって、
自分でもなんだかわけ分からないです。
多分失礼なこといってそうだけど、
気に障るところがあったらいってください。
謝ります。

■参考資料■
DOMってなに？
Document Object Model
http://www.atmarkit.co.jp/aig/01xml/dom.html

ジオン軍の重モビルスーツではありませぬ。
180 ：Name_Not_Found ：02/01/18 11:14 ID:4rqWFPhT: >>179
AppleScriptとJavaScriptで相互に文字列を
やり取りしようとすると化けちゃうけど、
JavaScriptだけなら標準DOMじゃなくて
innerHTMLとかを使えば化けずには済む。
だから、ID/NAME表示とかと同じ様に
ページ内に書き込む方法であれば何とかなると思うし、
書き出したa要素にaccesskeyを指定するだけだから簡単。
これなら使うのはIEだけだからクロスバージョンにもなる。

ただ、ID/NAMEなんかと同じでどうしても
書き出す為のトリガーはユーザーに引いて貰わないと。
フォルダアクションみたいに読み込み終了時に
AppleScriptを実行させるとか出来ればいいんだけどな。
181 ：1 ：02/01/18 11:32 ID:lyBYUDfa: ■UA便利化ツール試用日乗：「ス切リボ」篇■
おそまきながら、「ス切リボ」を試用してみたよ。
もちろんここはaccesskeyの話題を扱うスレッドなので、
stylesheetよりも、link要素巡回ボタン中心の記述になるよ。

「ス切リボ」はあくまでメニューの追加であるので、
キーボードショートカットによる操作ができない。
でも、巡回用のボタンを連打することによって、
link要素で指定されている次の頁へと移動できるのは、
便利だと思う。
しかもこのボタン、意外と賢くて、
nextがなくなると、up、
nextもupもないと、contentsが選択されるみたい。

とりあえずこの機能があるおかげで、
次々と頁を見ていきたいときには、
重宝する。

ツールバーの固定オプションを外せば、
「ス切リボ」を切り離して好きな位置に配置できるわけだから、
それぞれのリンクタイプに特化したボタンがそれぞれ用意されれば、
それこそiCabやMozillaに装備されている
ナビゲーションツールバーと同様の機能を実現できそうな気がする。
link要素（rel属性か）、それぞれ巡回ボタンセットなんていうのも、
意外と需要がありそうに感じたよ。

あとは、ショートカットさえ装備されれば、いうことなしな感じ。
入れてなにか不便が生じるものでもなさそうだし、
インストールもボタン一発で簡単。
こういうことに興味があるWinIEユーザは、
迷わず入れて良し、といった感触でした。

「ス切リボ」のダウンロードは、以下のURI!
http://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/
182 ：1 ：02/01/18 11:34 ID:lyBYUDfa: ■UA便利化ツール試用日乗：「N6 & Moz 用コンテキストメニュー拡張」篇■
このツールの便利なところは、それがN6あるいはMozillaであれば、
プラットフォームを問わず対応してくれるところ。
とりあえず、MacintoshとWindows環境のMozilla9.7で使ってみたよ。

導入は実に簡単。
ダウンロードしたファイルをドラッグ & ドロップするだけで、
後は自動的にインストールされる。

機能は豊富。特に面白いと思ったのは、
googleとインターネットアーカイブのキャッシュにアクセスできる機能。
これは自分の頁がどうよそで使われているかという、
一つの目安として利用できそうな気がする。
あるいは、今見ている頁の古いバージョンにアクセスしたいと思ったときなんかに、
役立ってくれるかもしれない。
いつ使うか分からないけど、使えると素直に便利かもしれない機能だと思う。

断然便利な機能としては、
ページアウトライン表示と、S/Wキーによる見出し移動。
適切に見出しが設定されている頁なら、
全体を一望するのに実に役立ち、
快適な頁閲覧を可能にしてくれる。
ただし、これはフレーム頁では使えない。
もちろんこれはこの機能拡張の問題ではないんだけど、
フレームが使われている長い頁では、
この機能を使いたい。
いちいちフレーム内文書を取り出さないといけないのが、
不便に感じてしまった。

自分の作っている職場頁に、こういうのがあるんですね。
ナビゲーションフレームで、見出しを表示している。
見出し移動をサポートしていないUAでは、
確かにフレームを使う方が便利なんだろうけれど、
このツールには正直そぐわないよ。
だから、フレームはやめようといったのに、
フレームなんて飾りです、それが偉い人には分からんのですよ……

そして、accesskey自動割り当て機能。
link要素に設定されているrel属性をもとに、
一貫性のあるキーボードナビゲーションを実現。
これが、実に便利だったりする（ずいぶん、手前味噌っぽい発言ですが）。
やはり、サイトごとにaccesskeyが異なる現状は、
ユーザにとって望ましい状況であるとはいえないと、
実感できるほど快適になります。

初めて訪れたサイトであっても、
link要素が設定されていることさえ分かれば、
いつもと同じキー操作で頁を巡ることができる。
この、もしかしたら些細に思えることが、
本当に便利と感じた。
むしろ、今までこういう動きが出てこなかったのが、
不思議でしようがないといってもいいくらいに、快適。
183 ：1 ：02/01/18 11:34 ID:lyBYUDfa: ところで、メニューバーから機能拡張を使おうとすると、
作動しないものがあるのはうちだけなのでしょうか。
コンテクストメニュー（右クリック）なら動くのですが……
それと、Preferences... を選ぶと、
必ず落ちるようになったのも、うちだけなのでしょうか？？？

でも、必ず便利になるといっても過言ではないこのツール。
一度、試してみて下さい。損はしませんって。

「N6 & Moz 用コンテキストメニュー拡張」のダウンロードは、以下のURI!
http://www.cc-net.or.jp/~piro/works/_moz-extensions.html
184 ：1 ：02/01/18 11:34 ID:lyBYUDfa: ■UA便利化ツール試用日乗：「MacIE5 べんりセット」篇■
Script Runnerで使ってみました。

正直、AppleScriptを使って、
MacIEをここまで便利に使えるとは、
目から鱗的衝撃。
とりあえず、このスレッドで話しているaccesskeyに関しては未サポートなんだけれど、
便利な機能が用意されていて、嬉しくなってくる（だって、*べんり*セットだし）。

引用を適切に使う人に便利なのは、
qおよびblockquote要素のcite属性の値を追加表示してくれる「引用元表示」と、
「ID/NAME 属性値表示」。
他所の文章を引用するさい、cite属性の値を適切に指定しやすくなります。
（ソースを見なくてもすむのね）
なおこの機能は、先述の「N6 & Moz 用コンテキストメニュー拡張」にも装備されています。
やはり、引用であるとかをする人たちにとって、
この機能は便利 & 求められているということなのでしょう。

自分ではHTMLは書かない、読むだけ、という人に便利なのは、
「URLへ飛ぶ (選択文字列)」でしょう。
HTMLタグを展開しないBBSでは、リンク先としてURIだけが、
ただの文字列として表示されます。
そういうURI文字列を選択した後にこの機能を使えば、
コピー & ペーストすることなしに、
該当の頁に飛んでいくことができる。
これは、便利。ttp://もサポートだそうなので、
半角板でもすいすいブラウズできるようになるかも。
同様の機能として、選択文字列でGoogle検索というのも、
自然に便利、いい感じです。

あと、
<a href="http://pc.2ch.net/test/read.cgi/hp/1006224399/" title="みんな、accesskeyってどうしてる？　tabindexは？">
<cite>みんな、accesskeyってどうしてる？　tabindexは？</cite></a>
というのをボタン一発で作成してくれる「リンクタグ into ClipBoard」はいいな。

この「べんりセット」は、
自分でもサイトを作成しています、という人にとって、
かなり有益であると思われます。
ひとつふたつなら手でコピー & ペーストや、
id/name属性を探してソースを見るのもいいですが、
その作業が積み重なると煩わしいもの。
これら作業を簡略化できるのは、ちょっといいなあ。

「MacIE5 べんりセット」のダウンロードは、以下のURI!
http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/MacIE5_benriSet.html
185 ：1 ：02/01/18 13:23 ID:lyBYUDfa: >>180 >>◆R4.ALMK.さん
とりあえず、午前中でJavaScriptに挫折。
ちゃんとした本でも買って、
よく言えば独自、有り体に言えば勝手な、
適当書方から脱そうと決意したところ。

そんな、全く持って何も分かってないような僕がいうのもなんですが、
link要素のrelとhrefの属性値を取得して、
bodyの開始タグの直後に、
<p id="id_optional">#</a> <a href="*.html" rel="next" accesskey="N">[N]ext ></a> ...(以下続く)</p>
みたいなのを置けないもんでしょうか。
idの値を設定しているのは、Lynxみたいに#で
このリンク要素一覧にジャンプできるようにと、
思ってるわけです（つまり、<a href="#id_optional">*</a>をどこかに置いておく）。

これって、無茶というか、
わけ分からない要求でしょうか？
決して不可能だとは思わないのですが。

ただ、問題は、
accesskeyが重なる可能性が大ということでしょう。

批判、批評、大募集中。
186 ：1 ：02/01/18 13:25 ID:lyBYUDfa: ごめん、間違いだ
<p id="id_optional">#</a> <a href="*.html" rel="next" accesskey="N">[N]ext ></a> ...(以下続く)</p>
->
<p id="id_optional"># <a href="*.html" rel="next" accesskey="N">[N]ext ></a> ...(以下続く)</p>
187 ：1 ：02/01/18 13:26 ID:lyBYUDfa: まだおかしかった……
<p id="id_optional"># <a href="*.html" rel="next" accesskey="N">[N]ext</a> ...(以下続く)</p>

だめだめ、だね……
188 ：Name_Not_Found ：02/01/18 14:04 ID:sqJ8bEQK: >>182 なんですが、
個人ディレクトリにインストールするにはどうしたらいいんでしょうね。

なかなか上手くいかない...
189 ：1 ：02/01/18 14:22 ID:lyBYUDfa: >>188
僕の場合、
ダウンロードしたファイルをダブルクリックするだけでは無理だったので、
ファイル（extensions.xpi）をMozillaにドラッグ & ドロップしたら、
なにごともなくインストールできたよ。
それこそ、全自動といった感じだった。

Mozillaのバージョンが違うとか、
あるいは別のなにが原因なのかな？

ドラッグ & ドロップで駄目なら、
僕にはちょっと分からない。
力不足で、ごめんね。
190 ：Name_Not_Found ：02/01/18 14:45 ID:481Q8Ro4: あと、微妙にスレ違いっぽい質問になりますが...
<link rel="next"... /> についてです。

日記や BBS みたいに過去のリソースが膨大にある部分では、
全部参照なんて普通めったにしないですよね。

こういうところって rel="next" はどうすべきでしょう。
最新の所だけ next, prev の輪に入れるべきでしょうか。

今のところ、サイトのトップ(= rel="contents") には rel="next" は設定されておらず、
そこからリンクされてる各プレゼンテーション毎に
start, end, next, prev が設定されてます。
各々のプレゼンテーションはまったく接続されてません。

あと、rel="next" つかってサイト全体を巡回するのって、
初めて来た時だけって気もしないでもないですね。
何度も来てるサイトって更新されたところにダイレクトに飛ぶってかんじですし。
191 ：p ：02/01/18 14:48 ID:ZEpmvhm5: >188
プロファイル別のディレクトリにインストールというのは以前試したのですが、
XULの上書きが働かないというMozilla側のバグがあるため、今の形に戻しました。
というわけで、向こうの修正待ちです。

>182-183
アクティブなフレームでもS/Wが使えるように修正しました。
あと、メニューバーやPreferencesの問題というのは当方環境（Win98）では起こっていません……
もしかしてMacでの話でしょうか？
192 ：Name_Not_Found ：02/01/18 14:51 ID:481Q8Ro4: >>191
手動でインストールすることって出来ないでしょうか？
chrome.rdf を書換えたりすると出来るとか...
193 ：p ：02/01/18 17:41 ID:H6ZVKYA/: 問題なのは
%profile%/chrome/overlays/
に置いたoverlay.rdfが無視されるというバグですので、手動でも対応は不可能です。

でも最近のビルドでは試してないので、もしかしたらできるようになってるかな・・？
194 ：p ：02/01/18 17:41 ID:H6ZVKYA/: 訂正。
%profile%/chrome/overlayinfo/
でした。
195 ：1 ：02/01/18 19:03 ID:yyzoDBch: >>190
■rel="next"■
日記やBBSでの、過去の参照にrel="next"を使うかどうか？
僕が日記にそれを設定するなら、月度ごとにファイルを分け、
その月々に対してrel="next" / rel="prev"を設定したい。
そして、各月度文書の毎日の日付を見出しにして、
ページ概観（アウトライン）で見るようにする。

これなら、一年で12ファイル。
一月にはfirstで、十二月はlastでとべる。

年をchapterに、月をsectionに、
日をsubsectionにするというのもありかも知れない。
でも、これはさすがにやり過ぎのような気がするよ。

> 何度も来てるサイトって更新されたところにダイレクトに飛ぶってかんじですし。

何度も読みたい文書でなければ、
一度読んだら終わりですね。
ということは、
next, prev等の基本的なナビゲーションこそ、
一貫したものであって欲しい。
そう、改めて、思うよね。

>>191
> アクティブなフレームでもS/Wが使えるように修正しました。

ありがとうございます！

それと、
> Preferencesの問題
は解決しました。

日本語パックが入っていない環境で、
言語 / エリアとして日本語を指定すると、
どうやらPreferencesで落ちるようです。
Mac OS Xでも、Windows98でも、
どちらでも同様でした。

英語にしてやれば、問題なしでした。
でも、アンインストールしたりインストールしたり、
今日はちょっと大変だった……

■訂正・重要■
>>183 において指摘されている、
Preferencesに関する問題は、
日本語環境が整っていない状態で、
言語 / エリアで日本語を指定したのが原因と見られます。
ツールの問題ではありませんでした。
誤解を招いたことをおわびしますと同時に、
皆さんは安心してどしどし使ってください。

■rel="alternate" の問題■
Mozilla 0.9.7にバージョンアップしたら、
今まで使えていたOther Versionが使えなくなったのですよ。
これってうちだけ？
皆さんの環境では、使えていますか？

MacOS X、Windows98ともに使えません。
どうしよう……
196 ：Name_Not_Found ：02/01/18 19:22 ID:2/ZMHV0A: Win2000 でも使えてない。 hreflang 属性をつけると発生。
さらに rel=alternate hreflang="**" 以下の全ての LINK 要素が全滅。
すぐ Bugzilla に出るだろうと思ってたんだけど
もしかしてまだ報告されて…ない？
197 ：p ：02/01/19 03:44 ID:AZBSczvJ: >>195
Preferencesの問題、確認しました。
確かにその条件で墜ちます……
何故ダ？　ちょっと前までは問題なかったのに。
とりあえず、注意書きに追記しておきます。
198 ：p ：02/01/19 03:46 ID:AZBSczvJ: そういえば、0.9.7では日本語パック適用で墜ちるためもじら組からのJLPは無いという話がありました。
もしかしたらこの（>195）問題のことなのかも。
199 ：1 ：02/01/19 19:44 ID:5b4lzYFt: >>196
ありがとう！　うちのだけじゃなかったんだね。
確かに、僕の確認したrel="alternate"を持つlink要素は、
どちらもhrefang属性を設定していたものだったよ。

Mozillaの問題だったんだね。よかった（わけじゃないけど）。
なおるのを、待ちましょう。

>>197
わざわざ確認してくださったんですね！
ありがとう。

理由は不明ですか。
> とりあえず、注意書きに追記しておきます。
そのほうが、よさそうですね。

しかし、開発をしていると、
環境の変化で問題が発生したりして、
大変ですね。
大変さにめげず、頑張ってください。
200 ： ◆R4.ALMK. ：02/01/21 11:20 ID:3o+wpMsQ: >>185 (>>1)
と、とりあえずこんなとこなのですがが…。
http://www.remus.dti.ne.jp/~a-satomi/nikki/2002/01c.html#d21n02
201 ：Name_Not_Found ：02/01/21 14:36 ID:1aGrTPMb: linkのリストアップと統一されたaccesskeyでそれなりに便利になったかもしれないけど、
linkのあるページって少ないから、あんまり意味ないようにも思う・・・

ページの内容を自動で解析というのは無理でも、ディレクトリ構造とヒストリからいくらかは推測できるだろうか？
でも僕の頭じゃせいぜいup/parentとchildくらいしかわかりません（それでもあればあったで便利か？）。

誰か、インテリジェントなAIをJavaScriptで書いてみませんか。笑。
202 ：Name_Not_Found ：02/01/21 14:44 ID:zqi4Xy8u: >>201
＞インテリジェントなAI

Intelligent Artificial Intelligence

冗長。
203 ：Name_Not_Found ：02/01/21 14:54 ID:fLNhJg2C: 知的な人工知性

それほど不自然でもないと思うけど。
204 ：ひよこ名無しさん ：02/01/21 15:14 ID:zqi4Xy8u: 危ない危険がいっぱいだ。
205 ：158 ：02/01/21 15:55 ID:yfs3P/04: どうも、お久しぶりです、158です。
久しぶりに覗いてみたら、随分話が進んでいるみたいで……とりあえず、
いくつか気になった所だけでもレスしたいと思います。

>>164
それは確かに、その通りなんですけどね……そこら辺のconsensusがもう少し取れれば……。
> むしろリンクタイプをリンク先URIの横に表示して全部一様に列挙した方がまだ分かりやすいかもしれない、とか思ってしまう。
なるほど、それもいいですね。CSSで表現すると、
a:link:after { content: " ( " attr(accesskey) " )" }
と言う感じでしょうか。
>>167
度々申し訳ありません。ありがとうございます。
> # http://bugzilla.mozilla.org/show_bug.cgi?id=2800かな?
やはり、「曖昧だ」と思っている方がいらっしゃるみたいですね。
# 「空白で区切られた語は"A and B"として、"-"で繋がれた語は複合語として解釈するべし」みたいな形だったらよかったのかなぁ。
>>168
> ですので、仕様の解釈より「どう利便性を高めるか」というか、そういう点を
> 重視したほうがいいのかなと。
そうですね……いくら仕様としては正しくても、実際に使えなければ悲しいですし。
"link types"の解釈にこだわりすぎていたようです。申し訳ありません。
>>190
うーん、Webサイトの構造をどう捉えるかと言う問題もありますね。例えば、site topを頂点に、そこから各コンテンツへと
放射状に伸びていくピラミッド型（階層型）とか、（link typesならPrevとNextで表現出来る、）一直線に繋がれたライン型（リニア型）とか。
そうですね……私ならば、最新の所“だけ”をPrev&Next(Chapter)の輪に入れて、各リソースへの過去ログは"Prev Section"とするとか。
しかし、190氏の構造（文章から察するに、階層型でしょうか？）でも十分だと思いますよ。
> あと、rel="next" つかってサイト全体を巡回するのって、
> 初めて来た時だけって気もしないでもないですね。
> 何度も来てるサイトって更新されたところにダイレクトに飛ぶってかんじですし。
そうかもしれませんね。私も、専ら（Internet Explorerの）履歴を使っていますし。

あと、「最新」に対する考え方の違いもありますね。
1. 最新のリソースは"Last"と考え、以前のリソースへはPrevでマークするひと
2. 最新のリソースは"First"と考え、以前のリソースへはNextでマークするひと
私のよく行くサイトでも、二種類の考えがあるみたいで……私は1派なので、2派の方のサイトへ行くと、
どうも混乱してしまいます。
>195,>196,>199(rel="Alternate")
今、私の使っているNightly - Mozilla {Build ID: 2002011403}では再現しませんが……修正されたのかな？
206 ：Name_Not_Found ：02/01/21 16:11 ID:MNhtDxyd: >>203
知的な性質が知性だろヴォケ
頭痛で痛んでろ
207 ：Name_Not_Found ：02/01/21 17:50 ID:CrYmWZWx: >>203
知的な人工知能と訳せよ。
>>206
現行の人工知能ははたして知的ですか？
208 ：p(201) ：02/01/21 18:00 ID:4nHeD1/M: 賢いAIを、という程度の意味だったんですが。
209 ：1 ：02/01/21 22:59 ID:R4CENG6O: ごめん、ちょっと戻ってくるのが遅かったかも。
今の現状、ちょっと悲しいよ。

僕は最初、>>201 を読んで、
今盛んに取り上げられているところにはひっかからなかった。
それは、インテリジェントなAIを欲しているところに、
共感しこそすれ、それ以外のことを思わなかったため、
そして、この文章の主題が、
このスレッドのひとつの悲願であった、
一貫したaccesskeyの装備に関するものであったため。

僕には、些細な言葉じりをとらえて、
揚げ足を取る余裕なんてないよ。

だから、みんなやめようよ。
僕はIntelligent Artificial Intelligenceという表現は、
むしろ、現状のAIに対する、ほどよい皮肉とさえ思ったよ、
嫌みじゃない、むしろこの先の
よりよいもの、より高いを目指したいという、
内心の表れだと思っている。
些細なことは問題じゃないんだよ。
言葉の向こうにある、
真意にこそ目を向けようよ。

>>201
link要素をリストアップして、
それらに対しaccesskeyを自動設定する。
単一のリンクタイプに関しては、
現状でひとつの目安が見えた感じだね。
実際、すごいいい感じだと思う。
将来的にでも、この機能がiCabに搭載されないのなら、
僕はMozillaに転んでしまうかも知れない。
それくらい、意義あることだと思う。

ただ、そうなってくると、すべてのページに、
link要素の設定されていないという問題が……

これも難しいよね。

ただ、link要素に関しては、
accesskeyの多様ぶりに対し、
随分一貫性があると思う。
それだけでも随分増しだと思うよ。
でも、ここで立ち止まってちゃいけないんだろうね。
210 ：158 ：02/01/21 23:05 ID:WwnKxB94: link要素の設定されていないページは"unknown"とでもして強引に……って、
それじゃlinkの意味がないか……。
211 ：1 ：02/01/21 23:24 ID:R4CENG6O: >>205 (158)
link要素、リンクタイプに関する同意は、
accesskey属性値に対するなら随分と整備されているとはいえ、
その使われから、意味するところから見れば、
まだまだといわざるを得ない。
そういう意味において、
僕は、同意見だよ。

正直、僕もリンクタイプの適用に対し、
今もずっと迷い続けてる。
上の方でいってる（ >>159 ）ように、
Upに関しては、僕のなかでまだ確定していない。

こんな状況だから、リンクタイプの複合なんて、
僕にはもう、手も足も出ないよ。

このへんの、
より明確でかつわかりやすい例のついたもの。
それを、僕は求めちゃうなあ。

> 1. 最新のリソースは"Last"と考え、以前のリソースへはPrevでマークするひと
> 2. 最新のリソースは"First"と考え、以前のリソースへはNextでマークするひと

僕は、1. だなあ。
やっぱり、Last Updateというくらいなんだから、
最新は、Lastだと思ってしまう。
明日、ネイティブに会えたら、聞いてみますね。

rel="alternate" の問題は、
明日、Mozillaをダウンロードして、
再確認してみるね。

それと、
>>200
も、明日確認してみるよ。

だって、うちにはOS Xがないの……

>>209
> 今の現状
というわけで、
僕も馬から落馬してみたよ。

みんな、かりかりせず、
のんびりゆったりいこうよ。
焦ったってしかたがない。
212 ：1 ：02/01/21 23:27 ID:R4CENG6O: >>210 (158)
> "unknown"とでもして強引に……って、

なんか、iCabでいえばリンクマネージャ、
MacIEでいえばページホルダみたい。

これらの、ページ内のリンクを抽出してくれる機能。
使ってみれば結構便利、なんですよね。
213 ：Name_Not_Found ：02/01/22 02:12 ID:Gm0tWAfG: しかし、ページ内にもナビゲーション用のリンクを記述してる現状を思うと、
link 要素によるナビゲーション部は少々冗長な気がしないでもない。
head 要素部だけ読み込んで解析の手間を減らす、とかの用途でもあるんだろうか。

<ul>
<li><a href="index.html" rel="index">インデックス</a></li>
<li><a href="network.html" rel="chapter">ネットワークの解説</a></li>
<li><a href="link.html" rel="chapter">リンク</a></li>
</ul>

こういう a 要素の中の rel を認識してくれる UA ってあるんでしょうか？

あと、賢い AI のあたり。
Piro 氏の h* 要素を元に outline を作成するのなんてのもそういうのに入らない？

それと、ちょっとスレ違いかもしれないけど、
CSS の aural メディアタイプをきちんと解釈する UA って現在存在するんでしょうか？
214 ：p ：02/01/22 03:08 ID:Mpt2Ya75: >>213
>h* 要素を元に outline を作成するのなんてのもそういうのに入らない？
fontやbで装飾された文字列までも見出しとして判別できれば、AIと言えるでしょうけど……
215 ：Name_Not_Found ：02/01/22 03:17 ID:Gm0tWAfG: >>214
そこまでいくと、文脈を読まなきゃいけなくなったりして
自然言語処理の世界に飛んじゃいそうなんで...
さくっと作るのは難しそうですね。

正しいマークアップをしましょうって啓蒙してまわるしかないのかなぁ...
なんか、なにもかわらないってかんじてさみしいです。
216 ：1 ：02/01/22 16:27 ID:gYdnjqSM: >>200
新べんりセット、試してみました。

端的に感想をいうと、多少のタイムラグが出てしまうところに
ちょっと残念さを感じてしまった。
これは仕方がないんでしょうね。

ページ上部にナビゲーション一覧が表示されること自体に関しては、
やはり便利だと思いましたよ。
どういうページが用意されているかというのが、
該当ページとの関連性も含めてアナウンスされるわけだから、
link要素の利点は感じられた。

rel属性値を抜き出して、一覧のリンクを作成、
それをページ内に一覧可能リストとして表示してやるだけで、
ずいぶん便利になりそう。

そんな感想を持ちました。
217 ：1 ：02/01/22 16:28 ID:gYdnjqSM: >>213
body内にナビゲーション用a要素、
headにもlink要素でのナビゲーション。
確かに、多少冗長さを感じるのは否めない。

a要素にもリンクタイプを設定できるのに、
そのうえlink要素が設定された理由ってなんなのか、
考えてみるとよく分からない。

やはり、UAに対する便宜なのでしょうか。
なら、ぜひUAには頑張ってもらわないと……

■media="aural"
これは、僕の方でもまだ未確認。
自分の関わっている職場サイトでは、
潜在的に視覚に障碍を持っている
ユーザが多いはずだから、
いずれはaural用CSSを書こうと思ってるんだけど、
今だと、テストができないんだ。

IBMのホームページリーダーなんてのは、
auralメディアタイプを解釈するのかなあ？

>>214-215
適切なh*要素が設定されていないページで、
適切なアウトラインを作成してくれるAIって、
場合によれば、人間以上の読解力を求められそう。

だって、HTMLをよく知らない人の作ったページって、
まずfont要素で見出しが作成されているし、
もっと酷いものになると、
p要素さえない（インライン要素、body内に直置き）。
過去に僕が見た、最も凄いHTMLドキュメントは、
title要素とpre要素、そしてa要素しかなかったくらい。

そういうHTMLを、UA越しに見る分にはかまわないんだけど、
時折そういうのを手直ししなければならないときがあって、
そういうときは、
いったいどこのなにを見出しにするかというところから迷う。

そんなこんなわけなので、
アウトライン作成AIは、
恐ろしく高度なものにならざるを得ないと思う……
その手間と実現するまでの時間を考えるのなら、
正しいマークアップ普及を頑張るべきなのかも知れない……

> なんか、なにもかわらないってかんじてさみしいです。

いつか、きっと変わると信じようよ。
すくなくとも、昔に比べるとずっと整備されてきてると思うよ。
だから、いつかはきっと……
218 ： ◆R4.ALMK. ：02/01/22 18:53 ID:u7IyvPhD: > 多少のタイムラグが出てしまうところにちょっと残念さを感じてしまった。

ここがぼくの限界なのですよよよ…。
AppleScript アプレットの側から、IE 上のページ移動と表示完了を知る術がない
というか、わからないし。それがわかるなら、そのタイミングを狙って
DOM いぢり JavaScript を発射すればいいのだけども。

> body内にナビゲーション用a要素、
> headにもlink要素でのナビゲーション。
> 確かに、多少冗長さを感じるのは否めない。

link は meta の中にありますが、とゆことはこれは人間向けの情報ではなく
コンピュータ（プログラム）に対する情報、ですよね。
対して、ページ中に表示されるナビゲーションは対人間用。
両方用意してるのだから、冗長感があるのは仕方ないところです。

link 要素を見て作られる、ブラウザ自体が提供するページ移動ナビリンク UI が
普通の装備である時代が来たなら、対人間用ナビゲーションなんて
用意する必要がそもそも無くなるわけで、冗長感も昔話になるかと。

そういう理想の未来の利便を今ちょっとだけかいま見てみるため、というとこに
link の rel を抜きだしてアンカーリスト化するものを作る意義があるのかな、と。
今現時点での実用性よりも、むしろそっちかな、と。
219 ：Name_Not_Found ：02/01/22 19:16 ID:+GNFQJs7: >>218
再び Piro 氏の outline なんですが、
あれって自動で index 作成してるようなもんですよね。
ああいった機能が標準になってくれると、
<a href="#section1">セクション1</a>
<a href="#section2">セクション2</a>
...
<h1 id="section1">ほげ</h1>
...
<h1 id="section2">はげ</h1>

みたいなともすれば冗長なマークアップをしなくても済むようになるんでしょうな。
個人的には、Mozilla 本体の配布に統合してもらえたらうれしかったりして。

あと、media=aural な UA って別に視覚傷害がなくても便利に使えそうな気がするんだけど。
テキスト主体の日記なんか読ませると便利な気がしますよね。
IBM のホームページリーダ、15000円かあ。試しに買ってみようかしらん。
220 ：1 ：02/01/22 23:32 ID:XSSWZEhz: >>218
> ここがぼくの限界なのですよよよ…。

ごめん。ちょっと言い過ぎだったよ。
正直なところをいうと、
それでも僕がやるよりもスマートに、
望んだ機能を実現してくれたのです。
嬉しかったし、それだけに多く望んでしまった。

僕自身が勉強したいなどといいながら、
まだまだ全然いたらない身であるわけです。
僕にとっては、自分自身のこの状態のほうが、
無念なのだなあ。

Apple Eventかなにかで、
IEの挙動を逐一把握できたらと思うんだけど、
僕自身、これについては分からなかった。
Microsoftのサイトで、検索かけてみても発見できず。
なにか、手はないのかなあ。
もうちょっと、僕の方でも調べてみます。

> そういう理想の未来の利便を今ちょっとだけかいま見てみるため、というとこに
> link の rel を抜きだしてアンカーリスト化するものを作る意義があるのかな、と。

この前向きな考え、素敵ですね。

現状の冗長さを感じさせる原因は、
このUA向けに用意されているメタ情報を、
二大ブラウザがほぼ黙殺していることでしょう。
IEにせよN6にせよ、外部スタイルシートは読むんですから、
その気になれば、対応すること自体は難しくないはずなのに。

こういう現状を、アリミカさんやPiroさんたちのされているような
ユーザーサイドからの活動、提案から変化させられると、
本当によいと思う。
同様に、僕のような一般ユーザーも、
与えられたものをそのままに受け入れ続けるのではなくて、
よりよいものを求め、発言していくことで、
もっとよい方向に向かっていけるんじゃないかって思ってる。

ごめん、ちょっと話が長いよね。

link要素とa要素で、
まったく同じナビゲーションを用意している現状。
これは確かに冗長なんだけど、
僕はそれでもこの二つを用意し続けるだろうと思う。

今のlink要素の状況とa要素の状況が、
逆転する日がくるのかも知れない。
でも、ちょっと、ナンセンスかも知れないけど、
一覧できるものを欲するのも人間だと思うんですよ。
だから、人間用のアンカーも書き続けると思うんだなあ。

とかいいながら、僕のサイトにはlink要素だけで書いて、
a要素で用意してないリンクがあったりする。
いってることとやってることが違いすぎだ……
221 ：1 ：02/01/22 23:34 ID:XSSWZEhz: >>219
Piro氏によるoutline機能、
iCabにも「概観」というかたちで装備されてるんだ。
これ、実に便利だよね。
それこそ、見出しへのアンカーが無意味に思えるくらい。
僕はこの機能を知って、
h*要素をしっかりと意識して書くようになったんだ。

link要素もそうなんだけど、
僕はiCabに随分と啓蒙されてる。
StrictなHTMLを書くようになったのも、
link要素や見出しに気を使うようになったのも。
全部iCabからだったんだ。

いまここのスレッドで紹介されているツールたちが、
こういったかたちで多くのユーザーに対して、
知らなかったもの、よりよいものを知らしめてくれると、
僕は嬉しいなあ。

> media="aural"

読み上げは、視覚障碍者だけのものではないという意見。
僕も、そう思うよ。

こういったものを自然に自分の中に取り込んでいくことで、
お互いが自然に近しいものになって、
お互いにとって便利なものが生まれてくるのが、
理想だと思ってるよ。

というわけで、読み上げブラウザを探してみた。

■for Windows
○ブラウザ
ホームページ・リーダー Windows版 V3.01
http://www-6.ibm.com/jp/accessibility/soft/hpr.html
視覚障害関連開発サイト（VoiceExplorer98）
http://www.osakapref-sb.ed.jp/Vips/
○読み上げソフト（スクリーンリーダー）
システムソリューションセンターとちぎ（95Reader）
http://www.ssct.co.jp/barrierfree/95reader/
ようこそoutSPOKENのページへ
http://www.tokaido.co.jp/fukushi/osw/osw-page/index.html
ボイスサーフィン特設ページ
http://www.amedia.co.jp/vs/

■for UNIX & Windows
Bilingual Emacspeak Project
http://www.argv.org/bep/

■参考ページ
視覚障害者情報教育用ソフトウェア(29/Sep/2000)
http://netweb.k.tsukuba-tech.ac.jp/home/ge/murakami/softj.htm
障害者もアクセスしやすいように、論文をHTMLで公開する時の注意点 (案)
http://www.shonan-it.ac.jp/each_science/info/nabeken/voice/WAI_WIT/WIT_template.html

とりあえず、こんな感じ。
ところで、このスレッド。
どんどん、accesskeyやtabindexから離れていく。
でも、動きとしては悪くないと思ってるんだけどね。
222 ：136 ：02/01/23 00:05 ID:IPCI6Icx: >>221
＞どんどん、accesskeyやtabindexから離れていく。
＞でも、動きとしては悪くないと思ってるんだけどね。
もともとはaccesskeyをLink要素から取得して～ところから発展してきてるん
ですよね。それが、ここにあつまる偉大な方々の助言などでここまで膨らん
だんだなぁと、ちょっとすごい！って思ってます。

ホームページリーダーは、2.5は使ってます。といより制作の際の確認用とし
て会社に購入させました。でも、でも・・・、悲しいことに結局ビジュアル優先で
マークアップの基礎なんてあったものではなく、当然LINK要素なんて社内じゃ
殆ど知られていない。
このあいだ、社内でbAのサイトが話題になったんだけど、あのサイトでLINK
要素使っているのを見て、みんなこれ何？って聞いてくるんだから情けないよ
ね。これって何の意味があるの？とか、ブラウザで何処に表示されるの？と
か・・・。
これで制作会社名乗ってるんだから困りもの。
当然そのときの説明は、私がしましたが・・・

ちょっと雑談と愚痴ということで。
223 ：Name_Not_Found ：02/01/23 00:58 ID:LvWp85ME: >>220
>今のlink要素の状況とa要素の状況が、
>逆転する日がくるのかも知れない。
私としては、
むしろ link rel="next" みたいなのはいらないんじゃないかな
って意見です。a 要素で使えるんですもん。
a 要素に rel を付ける方がより直感的に書けませんか？
UA ははやいこと a 要素の rel も判断するようになって欲しい。

>Emacspeak
期待してるんですけど、動いてるとこ見たことないのが残念。
emacs-w3m が喋るのかぁ。いいなあ。使いたい...

>VoiceExploer98 の次期バージョン VE2000
これ、使ってみました。
自分の日記読ませてみたんだけど、
結構読んでくれますね。
誤字脱字の発見に役立つことも発見しましたし。
2001/10/10 を「じゅうぶんのじゅうにせんいち」って読まれたのはショックだったけど。

「目が見えない人でも、夢をみるのか？」
http://ton.2ch.net/test/read.cgi/body/1004374543/
なんか読んでみるのも参考になるかも。
全盲の人や聾の人がどんなふうに 2ch とか見てるのかが出てて参考になりますよ。

個人的に、もういっこあるユーザビリティより
こっちのスレの雰囲気の方が好きなんで、
ユーザビリティ関係もここで話したいです。
まったく関係ないってわけじゃないですしね。
224 ：136 ：02/01/23 02:13 ID:IPCI6Icx: >>223
＞2001/10/10 を「じゅうぶんのじゅうにせんいち」って
＞読まれたのはショックだったけど。
そうそう、私の場合HPR3.01で読ませたときに同じ様に読み上げられたときは
さてさて、やっぱり日本語として○○○○年○月○日って書かないとまずいの
か？って思いました。
あと、「～を行って・・・」というのがATOKとかだと「おこなって」と打つと変換され
るんだけれど、HPRだと「いって」って読まれるんだよね。
「行なって」と書くときちんと読んでくれるんだけれど、ちょっと頭を抱えてしまっ
た。

>>1さんごめんなさい。ちょっとスレずれちゃったので、ｓａｇｅます。
225 ：Name_Not_Found ：02/01/23 02:28 ID:LvWp85ME: >>224
読みなんだけど、これって結構無駄なことしてるなって思うんですよ。
文章書くときは一旦ひらがなで打って、漢字に変換しますよね。
そのとき、「読みがな」メタデータは失なわれてしまうという。
で、その文章を利用するときに読みはなんだったか推測しなきゃいけない。
それでも文脈からは判断出来ない部分はたくさんでてきてしまう。

文章作成時に一意な読みが判ってるんだから、その情報をなんとかして
残せないものかとつねづね思ってるんですが。

ruby 要素も一つの解かもしれないけど、正直全ての漢字に ruby 要素付ける
なんてことはしたくないし。読みまで含むエンコード方式でもあったらいいのに。

あと、2001/10/10 とかで思ったんだけど、HTML に date 要素ってあってもい
いような気がしてきた。var 要素とかなんかよりよっぽど使える気がしません？

はあ。妄想吐くのは気持ちいいんですけど、
吐くだけじゃ意味ないんですよね。行動がともなわないと。

有言実行な >>1 氏や Piro 氏その他を見習わないとなあ。

散文しつれいしました。
226 ：1 ：02/01/23 11:56 ID:VAKp3XgO: accesskeyやtabindexの話は、
僕のかかわっているサイトの潜在的なアクセス層として、
盲のユーザーが多いだろうというというところからの
発想でもあったわけだし、そんな僕が話している以上、
こういう話題に落ち着いたのは、ある意味自然なのかも……

だから、今しばらくはこのままで大丈夫でしょう。

さて、本当に偶然なんだけど、
今日、盲の友人が職場に来たんだ。
その人は、メールもネットもしていて、
本のコピーや製本も全部自分でしてしまうような、
ちょっとすごい人なんだよ。

せっかくなので、どんなソフトを使ってるか聞いてみた。

Webの閲覧に使ってるのは、ホームページリーダーということだった。
昔はフレームにぶつかると黙ったということなんだけど、
今ではフレームも普通に読み上げてくれるので、
問題なく、平気で閲覧できるってことだったよ。

それと、最近ではAcrobat書類を読み上げるソフトもあるとのことで、
普通のWeb閲覧に関してはずいぶんよくなったっていう話だった。

普段のPCの利用は、PC Talkerというのを使ってるとのこと。
この読み上げエンジンは、ホームページリーダーと同じ、
Pro Talkerだから、親和性が高いという話だった。
ただ彼女がいうには、Explorerのほうが使いやすいんだって。

操作体系は、テンキーを使ってるとのことだった。
テンキーを、カーソルキーみたいにするんだろうか？
この辺がよく分からないから、
こんどホームページリーダーをトライアルしてみるよ。

メールアドレスを教えてもらったから、
いろいろとまた聞いてみるつもり。
いやあ、本当にいい偶然だった。
227 ：1 ：02/01/23 11:57 ID:VAKp3XgO: >>222
bAのサイト、僕も見てみた。
すごい気合の入ったlink要素の山。正直参りました。
僕も、まだまだがんばらないといけないと、素直に感じた。

link要素やその他、いろいろとある目立たない要素、属性群。
やはりそれらを知っている人というのは、少ないと思うんだ。
むしろそういうのよりも、marqueeやbrinkといった、
視覚に訴えやすいもののほうが知られてしまってるよねえ……
僕は、この両要素、嫌いなので、OFFにしてる（話がずれた……）。

link要素やaccesskey、stylesheetのmedia属性など、
知られてないもののなかに、意外と便利なものがある。
こういうのが浸透していくのは、もっと先なんだろうね。

なお僕の業界では、見出しが存在しないサイトも山ほどある。
なんでこのfont size="+2"をh1なりh2にしないんだ、と、
いくらでも叫べるよ。
だから、啓蒙的催しを、きちんとした場で僕はしたい。
一般の人に向かって、きちんと説明したい。
理念だけじゃなくて、便利ということも含めて、さ。

こんど、企画書を書いてみよう……

>>223
> a 要素に rel を付ける方がより直感的に書けませんか？

そうなんですよ。僕も、こちらのほうが自然だと思う。
僕はこういうナビゲーションのアンカーに、
nextなら→を、prevなら←をつけてる。
これらに対して、relを設定するだけなんだから、
ずっと自然で、普通に入っていけそうだ。

でもこうなってくると、link要素の存在意義っていうのに、
少々の疑惑も感じてしまう。
いや、こういう疑惑が整理されるころにこそ、
よりよいアクセス環境が整えられていそうな気がする。

僕が今、link要素を書くのは、
本当に一部UAのため、だけですよ。
これじゃいかんような気も、ちょっとしてる。
228 ：1 ：02/01/23 11:57 ID:VAKp3XgO: ■読み上げ
やはり、皆さんいろいろ試してらっしゃるんですね。
僕も、ダウンロードしてみよう。

> 2001/10/10 を「じゅうぶんのじゅうにせんいち」って読まれた

僕には、spanで括って、title属性に"2001年10月10日"と書くとかしか、
現状では思いつかない。
僕はHTML4.01で書いているので、rubyが使えない。
だから、spanのtitleで表現してるんだ。

>>224 (136さん）の、「行って」の読みに関しても、
<span class="*" title="いって">行って</span>
<span class="*" title="おこなって">行って</span>
という風にして、stylesheetに頼るしかないのかなあ。
となれば、どれだけそれら音声ブラウザが対応しているかという問題が、
再び浮上してくるね。

>>225
文字を打ったときの入力データを、
読み（音声）のメタデータとして残せたら、
確かに読み上げに関する問題は減少しそう。

FilemakerのWindows版は、
ふりがなかなんかの設定をしてやることで、
この入力データを取得してくれた
（Mac版は辞書を使用して、ソフトが読み仮名を用意してくれる）。

ただ、これって問題もあって、
人によっては、ものすごいぶつ切りの、
単漢字入力をするような人もいる。
僕は、これをすると、IMの学習が荒れるのでやらないんだけど、
やる人はやるよね。
こういう場合はどうなるのか、ちょっと考えたくない……

これはおそらく日本語という言語にこそ、
顕著な問題なんだろうね。
うまく、解決される日が来るといいなあ。

> date 要素

datetime属性というのはあるけど、date要素はないよね。
普通、データベースソフトには、
datetimeという形式が用意されてるけど、
HTMLにそれがないというのも、考えてみれば意外な感じがする。
最初は重要でないと判断されたのかな。

>>223
> 「目が見えない人でも、夢をみるのか？」

このスレッド、いいですね。
勉強になるというのもあるけど、なにより雰囲気がいい。
普通に向き合うという、ひとつの理想形だと思った。
気を張らず、普通が一番大切と再認識。
僕は、常日頃からそうありたいと思う。

>>225
僕は、有言実行なんかじゃないよ。
あれは、このスレッドのみんなの相違だったんだ。
僕が動いたんじゃなくて、みんなが動いたんだよ。
229 ：158 ：02/01/23 13:54 ID:KJDfgElm: >>223
2001.10.10 なら大丈夫かも……試した訳ではないので、確かなことは言えませんが。

>>224
「おこなう」は「行う」ですから、やはり「おこなって」は「行って」じゃないかと。
……と思ったら、「行なう」「行なって」は内閣告示でも許容されてるんですね。驚き。
http://www.tokyo-bay.ne.jp/~tsubota/linkhtml/okurignf.htm

#欲を言えば、前後の文脈―例えば、直前にある助詞とか―から解釈してくれるのが理想なんですけどね……。
「～を行った（おこなった）」「～へ行った（いった）」とか。難しいかな……。

>>225
> 僕が今、link要素を書くのは、
> 本当に一部UAのため、だけですよ。
> これじゃいかんような気も、ちょっとしてる。
いや、それを言ってしまったら、a要素のrel属性だって（今の時点では）殆ど無意味ですし、スタイルシートだって、
今の現状は99%がfor Visual User-Agentですから、Aural User-Agentにはまるで無意味ということに……。
<a rel="..."...の方が自然だと言うのは分かりますけれど、例えごく一部のUAのためだけだとしても、
そのUAを使っていらっしゃる方の利益になることならば、率先して出来る限りのことをするのが、
HTMLを書く者のしての努めだと思いますけど……。
link要素を解釈しないUAにとって大きな不都合になるとか言う訳でもありませんし（ファイルサイズは増加しますけど…）。
#実際、私は、先日初めてMozillaを入れた時、linkの便利さに驚きました。
#いつもはInternet Explorer 5.5 SP2を使っていますけど、MozillaやiCabが羨ましくなる時があります。

link要素に対して疑惑を感じていらっしゃるとのことですが、linkとaを併用するのではダメなんでしょうか？
#サイトマップのように、一つのHTML文書から多数のリンクを張るページでは難しいかもしれませんが……。
230 ：158 ：02/01/23 13:56 ID:KJDfgElm: >229の">>225"は">>227"の間違いです、申し訳ありません。
231 ：Name_Not_Found ：02/01/23 14:08 ID:wnPzs5ym: >>229
link に疑惑っていうのは、あくまで規格としての link の存在にであって、
現状では両方付けてますよー。

そういや、アクセシビリティを突き詰めてくと、
日本語のみしかコンテンツを提供しないってのは
全盲の人を阻害してるのと同じぐらい英語圏の人を阻害しててよくない
って考えもあるようです。
ややネタっていうかへりくつっぽいですが...

聾の方は外国の聾の人と手話によってわけへだてなく会話出来るって話を聞いて、
「言語」もアクセシビリティを阻害する要因になってるんかなーって思った次第でございます。

どこらへんで妥協するかって話かも。
232 ：158 ：02/01/23 14:34 ID:KJDfgElm: > スタイルシートだって、
> 今の現状は99%がfor Visual User-Agentですから、Aural User-Agentにはまるで無意味ということに……。
これは誤りでした、撤回致します。Aural UAには、Aural用のシートを書けばいいんですよね。
って、それが難しいんですけど……生勉強で下手なシートを書く位なら、Aural UAに任せて、UAの性能に頼った方が
betterなんじゃないかとネガティブなことを考えたり。

>>231
> link に疑惑っていうのは、あくまで規格としての link の存在にであって、
> 現状では両方付けてますよー。
あぁ、なるほどそうでしたか、これは失礼を致しました。
> 全盲の人を阻害してるのと同じぐらい英語圏の人を阻害しててよくない
うーん、私に語学力があれば、英語版やドイツ語版、フランス語版とかも提供したいんですけどね……。
日本語もろくに分かっていない私には到底無理です（泣）。
> 「言語」もアクセシビリティを阻害する要因になってるんかなーって思った次第でございます。
そうですね……赤ちゃんは、環境によって何語でも話せる可能性がありますけど、
私なんかは、日本語ですら悩んでいる状態ですから……。

何か、脱線しまくりの上に言ってる事が支離滅裂ですね。すみません。
233 ：Name_Not_Found ：02/01/23 18:44 ID:dxSXQ/tg: >>232
>生勉強で下手なシートを書く位なら、Aural UAに任せて、UAの性能に
>頼った方がbetterなんじゃないかとネガティブなことを考えたり。
これは私も思います。

というか、スタイルシート程度で果してバッチリな内容までもってけるんだろうとか。
IBM のホームページリーダ、試用してみたいですね。どんなふうになるんだああ。

英語圏の方には英語のコンテンツを用意するみたいに、
聾の方には聾の方向けのコンテンツを用意する、あたりが一番確実でしょうな。
現在は。

一度書いて何度も出版への道は遠い.....

accesskey なんですけど、これって HTML 用だけでなく、
一般のユーザインターフェースにも使えたら面白いかも。
というか、スタイルシートが一般のユーザインターフェースに適用できたら
面白そうですね。

細かいキーバインドとか配色とか、自分用のスタイルシートに詰め込んで
どのコンピュータでも自分の慣れた環境で操作出来るみたいな。

Mozilla の XUL みたいなのがもっとグローバルに普及すればいいのかなあ。
がんばれ Mozilla～
234 ：p ：02/01/24 05:01 ID:vbPF8JFH: ページ内全部を解析しなくてもナビゲーションが用意できるという意味でlink要素は非常に有用だと思います。
全部のa要素も解析してる（それだけじゃないけど）せいでMozの拡張機能でメニューの展開が非常に遅くなっている事を考えると、linkの解析だけで済めばどれほど楽かと思う・・

link要素は、人間が書くのにはわかりにくいし面倒なんですけど、
本来なら、Dreamweaverなどで丸ごと一つのサイトを管理するときに
プロジェクトに従って自動でlink要素を加える、というような使い方をされるべきだと思うです。
<a rel="...">はその補助として人間が適宜使う、みたいな。

ところでHPRって音声スタイルシートに対応してるんでしょうか。
プレスリリースとかでは触れられてないので、やはり非対応ということ？
235 ：Name_Not_Found ：02/01/24 20:02 ID:5yxxNFca: >>234
>linkの解析だけで済めば
例えばtableはtheadとtfootを使う事で新しいセルの書式を設定せずに
互換性を持たせながらコンピュータの為のメタ情報を用意している。

同じ様に、headかbodyの先頭にmetalinksとかのbodyと同じ内容の要素を
埋め込む様にすれば、その部分のaを読めばいい。
236 ：p ：02/01/24 23:20 ID:6DVwFpb5: >>235
>同じ様に、headかbodyの先頭にmetalinksとかのbodyと同じ内容の要素を
>埋め込む様にすれば、その部分のaを読めばいい。
それがlink要素の役割では？
237 ：235 ：02/01/25 08:13 ID:GMFSnYRY: >>236
……問題はlink要素の非互換性にあるものとばかり思っていたが。
238 ：p ：02/01/25 16:53 ID:UIrAX0+z: >>237
互換性というか、リンクタイプの応用についてのコンセンサスが取れていないという問題はaもlinkも同様だと思いますけど。
239 ：235 ：02/01/25 20:49 ID:8pCtEudW: Piroたんが>>234でフォーカスしていたのは
文書全体をパースしなければならないより
ヘッダのみに許されるlinkの方がマシだと言う問題であったと理解しているが、
それとリンクタイプの応用についてのコンセンサスと何の関係が？
240 ：p ：02/01/25 21:35 ID:yWFOeFnr: そうじゃなくて。
ここまでの話が「aにもrel/revがあるんだからlinkは不要」という風に読めたので、
それでは困ることもある、といいたかったのです。
241 ：1 ：02/01/25 21:56 ID:bEvCCuf2: 1です。ご無沙汰してました。

まずは近況から。
本日、職場のサイトに、accesskeyを「勝手に」設定したんだ。
まずナビゲーションアンカーにrel属性を設定、
その後、rel属性値に応じたaccesskey属性値を割り当てていった。
accesskeyの割り当てについては、
Piro氏の「N6 & Moz 用コンテキストメニュー拡張」に準拠。

しかし、あんなに大変だとは思わなかった。
accesskeyを設定するなら、ページが少ないうちがお勧め。

■音声ブラウザ
現在、ホームページ・リーダー体験版をインストール中。
ただ自分のWindows機はちょっと旧くて、
余裕で最低条件を満たしていない（Pentium 233MHz）。
ちゃんと動くか、すごく心配。

とりあえず、インストールを音声で案内してくれて感動。
画面を見てなくてもインストール状況がわかるのは、
正直、新鮮な感動だよ（かなり早口なのにもびっくりだ）。

試用期間中に、出来るだけのテストをしたいと思ってる。
音声スタイルシート、メディアタイプの対応。
他にも知りたいことがあったら、ここにどんどん書いてよ。
対応できるものから、試したいと思う。

ただ、自分一人では難しいこともあるかも知れない。
そんな時、みんなが支えてくれるなら、すごく嬉しいよ。

■音声ブラウザとアクセスキー
現在、プログラムの使用条件を聞いているよ。

ホームページ・リーダーの操作は、どうやらテンキーでできるみたい。
なのでもしかしたら、accesskey属性値として数字をわりあてるのは、
まずいかも知れない。
これは、とりあえず使ってみてから答えを出すよ。
242 ：1 ：02/01/25 21:58 ID:bEvCCuf2: ■言語
情報を公開するということを考えれば、
多言語で提供できることが望ましいのはいうまでもないよね。
でもコストの問題や、その言語地域を明らかにそのサイトが対象としないなど、
さまざまな状況が関わってくる問題だから、
なんでも多言語にする必要はないと思うよ。

世界規模に公開したいのなら、せめて英語版は用意すべきだろうけど、
明らかに対象が日本国内だけに限定されるのなら、
そのコストと労力を日本語版に振り向けるほうがずっとよいと思うよ。

なお僕の職場は、ネイティブがいるから英語自体に問題はないんだけど、
労力の問題から英語版がなかなか出来上がらない。
でも、いずれは英語版を充実させたく思ってる。
自分で出来る範囲のことを、出来る範囲で頑張ればいいんだ。
僕はそう思ってるよ。無理までする必要はないよ。

■AppleScript, AppleEvent
職場のSE（Macintoshユーザー）に聞いてみたんだけど、
残念ながら知らないということだった。
彼はプログラマでもあるので期待したんだけど、
MacIEをどうこうしようとしたことはなかったみたい。

ちょっと残念。取り急ぎ、報告まで。

■link要素の意義
link要素は、UAに引き渡すための情報として、
a要素と分離したほうが、ある意味スマートだと思う。
書くのは面倒なんだけどね。

文書中に大量に出現しうるa要素を解釈するとなると、
ソフトにものすごいかかる。
やはり、ページはさっと展開されるのが理想だと思うしね。
subback.htmlなんかを解釈することをかんがえると……ね。

ホームページ・リーダー起動中。ちょっといい感じ。
悪くないよ。
243 ：1 ：02/01/25 23:05 ID:bEvCCuf2: ■ホームページリーダー
意外と楽しくて、使いやすいと思った。
ヘッドフォンで聞きながら、別のことをできるから、
僕らが使ってもかなり便利なんじゃないだろうか？

今、このaccesskeyスレッドを、頭から読み上げてる。

ホームページリーダーでは、accesskeyが使えない模様。
もっと調べれば、使えるのかも知れないけどね。
それと、見出し間移動（概観、アウトラインの機能）が
あるかどうかも操作中。

現状で分かってることは、

○acronym, abbrはサポートしていない模様。
○2002.1.25と書くと、ピリオド以下が小数点扱いされる。
○英語は読むが、フランス語も英語読みされてへこむ
（うちのコンテンツで、一部フランス語を使ってるんだよ）。
○パン屑リストは、正直邪魔（display:noneか？）。
○「気も……」を「キモー」と勘違いした。文脈にもよるけど、
文章は省略せず、すべて書くべきだと思った。
○subback.htmlは、競馬中継の副音声みたい。このスレッドを探すのに、
かなりの時間がかかった。

とりあえず、こんな感じかな？
分かったことがあれば、その都度追加していくね。

（というか、ここは何スレッドなんだ……）
244 ：Name_Not_Found ：02/01/25 23:51 ID:R/cuPqli: >>243
なるほど、参考になります。
acronym と abbr ってどう読ませるのが正解なんだろ。
<acronym title="Hyper Text Markup Language">HTML</acronym>が...
「Hyper Text Markup Language、以後 HTML と呼ぶ、が...」
って感じ？で、同じ title と contents を持った acronym 要素は中身だけ読むみたいな。

つーか、私も試用版ダウンロードしてみよっと。
30M....ダイヤルアップユーザにはこたえるっす。
つーか、卒論...

つーことで sage
245 ：1 ：02/01/26 11:10 ID:z1/LJ/xU: 今、HPRヘルプのキー操作ガイドを読んでもらってます。
多すぎて、覚えられやしないよ。

>>244
僕のなかでacronym, abbrは、
それこそtitle属性値だけ読み上げられるはずだったんだけど。
だから、
<acronym title="Hyper Text Markup Language">HTML</acronym>が...
だったら、
「Hyper Text Markup Languageが...」
と読まれると思ってたんだ。

やたらと一般的でない省略語は使うべきでもないのかな。
もちろん、これは音声ブラウザに関する問題というよりも、
なにに関しても通じる問題だけどね。

とりあえず、現在までの試用でわかったことは、
普通にきちんと、出来るだけ正しく書くことが大切
ということが分かったよ。
省略しない、助詞も省かない。ややこしい字、語は使わない。
口語では、ちょっと難しいかも知れないね。雰囲気が出ないよ。

> つーか、卒論...

今、追い込み時期だよね。少しの脱線は論文にも役立つけど、
脱線しすぎると戻ってこれなくなるから、ほどほどにね。
僕の時は、中国哲学にはまったなあ
（テーマは欧米文化に関するものだったんだけどね）。

論文、頑張ってね！
246 ：136 ：02/01/26 17:24 ID:+taX4L5j: ＞やたらと一般的でない省略語は使うべきでもないのかな。
アクセシビリティガイドラインの中に専門的な言葉・・・云々
みたいなのがあったと思うけれど、改めて言葉の難しさというか
そういうのを感じますね

http://www.jwas.gr.jp/

ここには、アクセシビリティのチェックを出来るところがあるの
だけれど、全部で4つのレベルでチェックができます。
そのうちのBは、上記サイトが独自作った採点でアクセシビリティ
ガイドラインをさらに優しくした最低限必要な部分をチェックして
くれます。Bは、頑張ればすぐにでも達成できるのだけれど、Aに
なった途端、「専門的な言葉を使ってませんか？」とかっていわれ
るんです。まぁ機械的にチェックしているので完全なチェッカーと
いうより、目安的な使い方をすれば良いのだけれど。

HPRって3.0からJavaScriptにも対応するようになったのだけれど、
困ったことに、某ソフトで作成したDHTMLのプルダウンメニューに
含まれるアンカー（Script要素内に記述）まで読み上げちゃうんで
す。困った困った・・・。
247 ：1 ：02/01/26 19:27 ID:yGOnc1k4: >>246 (136氏)
このサイト、いいですね。わかりやすくまとめられてるし、
水族館サイトトップページを作っての説明も、すごくよくわかるよ。

でも、accesskeyはついてないみたい……　いや、いいんだけど……
ちょっと悲しいなあ。

難しい漢字や専門用語に関しては、僕はちょっと複雑です。
というのは、僕の職場は専門機関なので、
専門用語がばんばん飛び交うのは普通です。
漢字で書かれた専門用語を、
スクリーンリーダーは普通正しく読んでくれません。

盲でも専門家なら、専門用語を辞書登録してるだろうけど、
専門家以外も興味を持つジャンルなので、
その両者にとって使いやすく、わかりやすいものを
用意しないといけない。
ちょっと大変かも知れないけど、
未来の専門家を排除するなんてことは、
うちのサイトではやりたくない。
頑張らないといけないなあ。

今日、HPRで、麻雀関連サイトにいってみました。
立直は、「りつちょく」と読まれてしまいます。
こういうのは、カタカナで書くほうが良いんでしょうね。
> HPRって3.0からJavaScriptにも
プルダウンメニュー内のアンカーまで読まれますか。
それはちょっと困りますね。
display:noneが効かないという話ですから、
対処しようとすれば、Script書き換え、でしょうか。
それとも、speak:noneが使えるのかな？

ところで、HPR等、音声ブラウザに関わる話題は、
「ユーザビリティ専用スレ」
http://pc.2ch.net/test/read.cgi/hp/974404232/l50
で話したほうがいいかも知れないと思いはじめています。

これは、スレ違いだからというのではなくて、
話題を一箇所に集めたほうが、
双方にとって有益だと思うからです。
特に、今のDHTMLの話題なんか、
ここだけで終わらすのは惜しいんですよ。

僕も、accesskeyの1として、参加しています。
ということで、よろしければそのようにしませんか？
248 ：Name_Not_Found ：02/01/26 19:35 ID:Kj95GnhG: >>247
ユーザビリティスレは最初雰囲気悪かったんで
こっちにいろいろ書いてましたが、
最近の内容はどっちかというとユーザビリティ全般だし、
あっちのスレッドに移行するのもいいかもしれませんね。

ユーザビリティって言葉を聞くと脊髄反射で「んなもんしらね」
って言いたがる人種がいるから荒れたのかも。

ここが荒れなかったのはスレタイトルのおかげもあるかも。
249 ：Name_Not_Found ：02/01/26 19:38 ID:Kj95GnhG: しかし、
わざわざ考慮しなくちゃ確保出来無いユーザビリティってのも問題のような。
「んなもんしらね」な人でも、普通に書くだけでユーザビリィが確保出来るような
うまい方法ないもんかなあ。

「こうなってるとアクセシビリティが向上する」っていう法則があれば、
プログラム的に適用することが出来るんだろうけど...

XML 関連技術が我々を幸せにしてくれるんでしょうか。
250 ：1 ：02/01/26 20:56 ID:yGOnc1k4: >>248
ユーザビリティスレッドの雰囲気の悪さは、
当初僕も気にしていました。
そのため、本来なら向こうで展開すべきだろう、
accesskey、tabindexに関する質問を、
単発スレをたてるなといわれることを覚悟で、
新規に立ち上げたのでした。

当初は荒れていたユーザビリティスレッドですが、
音声ブラウザ関連になってから動きも盛んだし、
雰囲気も落ち着いていると思います。
なので、いくならあちらもありかなと思ったのです。

もちろん、こちらで展開してもオッケーですよ。
スレ違いはスレ違いだけど、
それが甚だしくないのなら、許容範囲であると思っています。

>>249
> 普通に書くだけでユーザビリィが確保出来るような
> うまい方法ないもんかなあ。

こういう方法やシステムが出来てくると、
本当はいちばんいいんだろうね。
でも、残念ながらこういう使いやすさ等に関しては、
link要素を解釈してaccesskeyを自動割り当て、
といったような方法は使えないだろうし。

■今日の僕の体験
ごく普通のテキストサイトでも、
a要素の内容として記号（■や●とか）だけが
使われてることもある。
残念ながら、HPRはこれを読んでくれないので、
アンカーが選択されてるのかどうか、判別つかないんだ。
仮にタブで選択したとしても、それがなにか分からない。

だから、やっぱり、現状では
アクセシビリティ、ユーザビリティは、
わざわざ考えていかなきゃならない問題なのでしょうね。
251 ：MOULIN ◆ROUGEr/U ：02/01/27 01:47 ID:Zy7nicP6: >>250
先日、IBMホームページリーダの1ヶ月トライアル版を使ってみました。
ページは親切に作っていたつもりだったのですが、撃沈しました。

皆が口を揃えてalt属性が無いことを指摘することがありますが、
alt="*"などと書いて、わざと読ませないようにした方が良い場合もある。
（それを知っててわざと読ませないようにすることと、知らずにそうしてしまうことは大違いですが。）

a要素の範囲も結構難しい。通常テキストは男性、リンクは女性と変えて読まれますが
すぐに次のテキストを読み上げるので、相当慣れないとページ移動がスムーズに出来ないかもしれない。
accesskey属性が埋め込まれていることを知らせる為に表示させている部分も、リーダに読ませれば「？」状態。

そしてコンテンツの配置によっては、ページを開くたびに延々長々とコンテンツを読み上げる。
tabindex属性にも通じる話ですね。

accesskey属性、tabindex属性、link要素、音声ブラウザ・・
どれか特化しただけの妙に偏ったこともできないな、という感想でした。
252 ：1 ：02/01/27 20:46 ID:OXPLnEMu: >>251 (MOULIN氏)
ほんのわずかなHPR体験からの意見という限定付きでだけど、
僕は、HPRに向けては、accesskeyも、tabindexも、
いらないと思う。
というのは、HPRは、これらを解釈しないからなんだけど。

こういうことに気を使うのだったら、
フォーム内容は、理想的なtab順の通りに、
要素を配置していくほうがずっと大切だし、
アンカーに関していうなら、
前後の文脈から切り離されても、
リンク先が分かるように、
内容となるテキストを工夫すべき、と思った。

■アンカーのこと
アンカーに関しては特に、
リンク抽出機能を機能を使ったとき、
リンク先がつかめなくなるものが結構多くて困った。
それと、うちは、
ア　カ　サ　タ　ナ...
の各文字をアンカーにしているページがあって、
HPRはこれを一瞬で読み進めてしまう。
やはり、アンカーテキストには
ある程度の長さがないといけないと思ったよ。

■accesskeyのこと
> accesskey属性が埋め込まれていることを知らせる為に表示させている部分も、リーダに読ませれば「？」状態。

これに関しては、僕は割り切って、CSSで対処しようと思ってる。
after疑似要素を使って、
a[accesskey]:after{content: "(" attr(accesskey) ")"}
というのを、つけてやりたい。

CSS2に対応しないUAでは表示されないけど、
逆にauralメディアに対しては優しいと思う。

いろいろと工夫できる部分はあるけど、
あちら立てればこちらが立たずというところは否めない。
だから、自分のサイトが対象とするユーザを考え、
最も中心となる層について考え、
次いで他の環境に不便にならないものを作っていく。
これが、僕の現在においての結論、かな。
253 ：Name_Not_Found ：02/01/27 21:49 ID:LE++zpMx: >>252
> それと、うちは、
> ア　カ　サ　タ　ナ...
> の各文字をアンカーにしているページがあって、
> HPRはこれを一瞬で読み進めてしまう。

用語集作ろうとしてたんだけど、これは使いづらそうだね。
「あ～お、か～こ」とかにするべきかな？
254 ：MOULIN ◆ROUGEr/U ：02/01/27 22:09 ID:Zy7nicP6: >>252
> あちら立てればこちらが立たずというところは否めない。
> だから、自分のサイトが対象とするユーザを考え、
> 最も中心となる層について考え、
> 次いで他の環境に不便にならないものを作っていく。

まったくもってその通りだと思います。
さりげなくニーズに合わせた機能を盛り込むことに、意識して頑張ってみます。

before/afterでの埋め込み方法も、一時は導入を考えましたが
WinIEがbefore/afterが無効のために、いまいち用意した達成感が無い。

>>253
> 用語集作ろうとしてたんだけど、これは使いづらそうだね。
> 「あ～お、か～こ」とかにするべきかな？

いや、対策はあるんですよ。

あ。　か。　さ。　た。　な。

という風に「。」をつければ、間を置いて読み上げてくれます。
そして、「。」を背景色と同じ色にしたり、span要素でマークアップして「。」だけをdisplay:none;にする。

このサイトが実際に使っています。a要素が続くリスト項目などのソースを見てください。
http://www.din.or.jp/~hiro-/barrierfree/index.html
255 ：1 ：02/01/28 02:24 ID:BzoUnjDk: >>253
>>254
> 「。」をつければ、間を置いて読み上げてくれます。

そういえば、そうでした。
「、。」といった、句読点で、
わずかながらポーズがかかるよね。

だとすれば、
ア　カ　サ　タ　ナ...
ではなくて、
ア、カ、サ、タ、ナ...
でも良い結果が得られそうだね。

でも、どうしようか考え中。
ア行，カ行，サ行，タ行，...
にしようかな。

ところで、！？などの感嘆符疑問符でも、
ポーズがかかってくれるとよいのに。
これも、素通りだよね。
「。」つけるかなあ...

> before/afterでの埋め込み方法も、一時は導入を考えましたが
> WinIEがbefore/afterが無効のために、いまいち用意した達成感が無い。

これは、確かにそうだよね。
でも、僕はいずれ時間が解決してくれると信じたい。
ある環境で、
「つぎのぺーじえぬ」というよく分からない文字が読まれて、
利用者が混乱する可能性があるのだったら、
accesskeyという知る人ぞ知る機能には、
ちょっと割を食ってもらってもいいかも知れないなどと考えるのは、
このスレッドの1としては、大問題だなあ……

これも、UAの実装と、そしてもしかしたら、
accesskey自動設定が解決してくれるかも知れない。
先のことかも知れないけど、いずれは実現してくれると嬉しいね。

P.S.
[N]extというような書き方も、
音声ブラウザにとっては大問題です。
結構わけ分からなくて弱ります。
256 ：Name_Not_Found ：02/01/28 02:50 ID:kvIA7cT1: しかし、デザインを重視しようと思うと、
ここで述べられた数々のテクニックは適用しずらいものが多いよね。

盲や聾の人たちに比べて、目が見えたり耳が聞こえたりする人が多い以上、
シェアを獲得するためにはそういった人達へのアピール
= かっこいいデザイン→アクセシビリティ軽視
ってなっちゃうのはしかたないような気がしないでもない。

小手先のテクニック駆使するぐらいだったら
別コンテンツ作った方があれこれ悩まなくていいかなと思った
UA の実装がすすんでから、CSS のこととかで悩めばいいし。
寒い寒い北国の夜。
257 ：Name_Not_Found ：02/01/28 03:46 ID:fUaKNdaK: >>255
cueやpauseプロパティは使えますか？

たぶん実装されてませんよね。。。

a{
pause:1500ms;
}

句点（。）だと視覚的、ないしは点字表示にすると問題ありげな予感。
# 点字の機器はまだ商品化はされてないようですが
258 ：Name_Not_Found ：02/01/28 03:54 ID:fUaKNdaK: >>256
ひたすらdisplay:noneかvisibility:hiddenでしょうか。
あるいは@mediaでscreen,print,aural,brailleでそれぞれ
スタイルシートを書き分ける方が、完全に別コンテンツを
作るよりは労力省けると思います

あるいはUAを判別して、XML+XSLTで書き出しでしょうか・・・？
259 ：Name_Not_Found ：02/01/28 04:33 ID:3x4Lip4z: >>258
>あるいはUAを判別して、XML+XSLTで書き出しでしょうか・・・？
これが一番現実的かなと思ってます。
XML の内容をがんがん抽象化していければ多言語化も容易だと思うし。

Cocoon 使って遊びたいのに、
自由に出来るサーバじゃ Java 実行環境実装されてないんだな。
欝だ....
260 ：Name_Not_Found ：02/01/29 16:56 ID:CseXpnHE: >>258
UAが判別できるのであれば、別にXSLTにこだわる必要はなのでは？
CGIでも、PHPでも簡単にできるし。
261 ：Name_Not_Found ：02/01/29 22:29 ID:3nQvp5ou: IE6 に音声読み上げ機能が付いたってのは本当なんですか？
何故か MS のサイトが見れなくて確認出来ない～
262 ：1 ：02/01/30 01:30 ID:3Pxy0jns: すっかり音声ブラウザ関連の話題にシフトしてしまったようなので、
accesskeyとtabindexに関しては、いったんしめくくってしまうね。

その前に、一度まとめておこう。

ユーザの便宜を図るためのaccesskeyやtabindexだが、
現実はさまざまな割り当て文字がサイトごとに氾濫していて、
どちらかといえば使いやすい状況じゃない。
だから、せめてその目安となるなにかが欲しい、というのが、
このスレッドの本来の趣旨だった。

この趣旨における一応の決着は、

■サイトオーナーによるaccesskey設定

完全な統一はもちろん不可能だが、
対象とするユーザ、環境に応じて、accesskeyは工夫すべき。
PCユーザを対象にするのなら英数字、
モバイルフォンユーザが対象なら数字が妥当など。

accesskeyを設定するのは、ホーム（トップ）やインデックス、
前後ページ等、ある程度恒常性のあるページに対するアンカーが
有用だろう。
このことから、link要素におけるlink typeが参考になると思われる。

フォームのsubmitとresetに関しては、
誤操作を防ぐ理由から、
accesskeyを設定しないことが望ましい。

CSS3では、CSSによるaccesskey設定が可能になるとのこと。
このことから、media typeを用い、
ユーザの閲覧環境に応じたaccesskey設定への期待が高まる。
各メディア用のスタイルシートを用意することで、
PC向けには英数字、モバイルフォン向けには数字を使った
accesskeyを用意できることになる。

accesskeyの機能を、UNIX Terminal or DOSエディタがするように、
画面に常に表示させると便利だろうというアイデアも出ている（>>117）。
263 ：1 ：02/01/30 01:30 ID:3Pxy0jns: ■UAの自動accesskey割り当てへの期待
accesskeyの設定が各サイトでまちまちなのが問題、
かつaccesskeyがlink typeをなぞるものであるのなら、
いっそrel="next"にUAが自動で、accesskey="N"と同様の
ナビゲーションを与えればいいのではないかというアイデアが出る（>>34）。

これが発展し、各ブラウザデベロッパー宛に、
link要素を解釈しそれにaccesskeyと同等のナビゲーションを、
自動で割り当てる機能を望むメールを送ることに決定した。

メールは、12月20日に送信された。
メールのテキストは、>>82
その日本語訳は、>>89

■有志による自動accesskey割り当て
上記のアイデアが、有志の手によって実現されはじめている。

WinIEにおいては、H&A氏による「ス切リボ」、
http://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/
Mozilla & N6においては、Piro氏による「N6 & Moz 用コンテキストメニュー拡張」、
http://www.cc-net.or.jp/~piro/works/_moz-extensions.html
MacIEにおいては、ありみかさとみ氏による「MacIE5 べんりセット」、
http://www.remus.dti.ne.jp/~a-satomi/bunsyorou/MacIE5_benriSet.html
および、
http://www.remus.dti.ne.jp/~a-satomi/nikki/2002/01c.html#d21n02
がそれにあたる。

これらを導入することで、
無拡張のUAに比べ、格段の使いやすさが実現される。
また、UAによるaccesskey自動割り当て機能が、
実に有効であるという証明でもあった。

各々の拡張は、おそらくこれからも開発が続けられ、
より便利、より有用なものになっていくと思う。
また、市井一般の自分で拡張ツールを作成するだけの
技術を持たないユーザにとって、
これらはまさに恩恵であり、暁光である。

この、なんら手に取って感ずる結果を生み出せなかった僕にかわり、
彼らが提供してくれたこれら拡張が、このスレッドをもり立ててくれた。
心からお礼を言いたい。

ありがとう。本当に感謝しています。
264 ：1 ：02/01/30 01:31 ID:3Pxy0jns: ■link要素に関する話題
link要素の話題も、主にlink typeを中心に、なされている。
link typeは、現在主に使われている単体指定だけではなく、
"next chapter"といった、複数指定も可能。
ただし、これが「次の章」なのか「次のページかつ章」なのかという、
コンセンサスがないという現状に触れられている。

これに関しては議論紛々でへはあったが、さすがに決着は得ていない。
なんらかの機関による、指針の提出に期待するところだろう。

■音声ブラウザに関する話題
HTMLを語る際、引き合いに出されることの多い音声ブラウザ。
その実際を知りたいという欲求から、音声ブラウザの試用がされている。
現在の中心はIBMホームページ・リーダー Windows版 V3.01（以下、HPR）。
http://www-6.ibm.com/jp/accessibility/soft/hpr.html

その一連の行動で分かったことを、
accesskeyに関するもののみあげるとすれば、

1. HPRでは、accesskeyを利用できない。
2. accesskeyの属性値を、Next (n)や、[N]extというふうに書き出すと、
　音声ブラウザの読み上げでは意味不明であり、混乱のもとになりかねない。

こういうものだった。

後者に関しては、CSSのafter疑似要素を利用し、
a[accesskey]:after{content: "(" attr(accesskey) ")"}
で対処可能かも知れない。
ただ、現状においてはこれが表示されない環境が多いだろう。
265 ：1 ：02/01/30 01:31 ID:3Pxy0jns: ■終わりに
以上、簡単にこのスレッドを振り返ってみました。
思えば、こんな口先ばっかりだった自分が、
ブラウザデベロッパーに宛てて提案のメールを送るという、
今までだったら考えられないような
積極的行動に出ることができました。

これもすべて、このスレッドに参加し、多くの有用な意見とアイデア、
そして僕に前に進むことの大切さ、意味を教えてくれた、
皆さんのおかげであると、心から実感しています。

皆さんがいてくれたおかげで、
僕は、ただ傍観するばかりで前を見ない後ろ向きな人間をやめ、
望む未来に向かってささやかではあるけれど、
一歩を踏み出す勇気を持つことができました。

このスレッドが始まって二ヶ月ちょっと。
正直つらかったこともあったし、
投げ出したいと思ったこともあったけど、
それでも頑張れたのは、
ひとえに僕を暖かく見守ってくれた、
皆さんのおかげです。

ありがとう。
266 ：Name_Not_Found ：02/01/30 01:44 ID:tc0RJuUH: １は英雄、ａｇｅ
こんな良スレは2度とないでしょう。
ありがとう。>>1
２ちゃんねる、マンセー!
267 ：Name_Not_Found ：02/01/30 02:04 ID:QZ4s7Jd+: 2chマンセーとは思わないけど、1さんには感謝。
268 ：Name_Not_Found ：02/01/30 02:28 ID:VHzX0pWb: accesskey から一歩踏み込んだ所まで考えさせくれたこのスレに、
そしてそれを立ててくれた >>1 氏、貴重な意見を投稿してくれたみんなに
正直、ありがとうといいたい。

....

で、これはエンディングなんですか？
スタッフロールでも流すの？
269 ：Name_Not_Found ：02/01/30 02:40 ID:Ud/d1S7d: ここまでのまとめ、でしょ。
270 ：Name_Not_Found ：02/01/30 02:55 ID:VHzX0pWb: >>269
いや、なんか
エンディングテーマでも流れてきそうな雰囲気だったもんでつい...
271 ：MOULIN ◆ROUGEr/U ：02/01/30 03:47 ID:O7nunkpC: >>1氏の行動は本当にすばらしい。

このｽﾚのおかげでaccesskeyやtabindexの勉強になった。
関連してlink要素の勉強にもなり、accesskey的な処理がlink要素にも適用できないものか？
という課題にも触れることができた。

さらに、音声ブラウザを体験したのも、このｽﾚがきっかけだった。
accesskey指定していることを知らせる文字列が、
音声ブラウザにとっては不思議な読み上げ状態になってしまうこと、
accesskeyと音声ブラウザのショートカットキーがかぶってしまうと、
音声ブラウザユーザのキー操作とかぶることも、最近知った。

>>1氏が締めくくるような投稿をされたので、一旦お礼を言っておきたい。本当にありがとう。
引き続き、accesskey属性やtabindex属性、link要素の使い方、音声ブラウザについて
共に考察できる場であることを願う。
　　　　　　　　　　　　　　　　　　　　　　　　　　　　　ムーラン・ルージュ

ちなみに↓のサイトに行きたいのだが行けない。
http://www.xinada.ne.jp/~handa/tech/CSS/SuKiBo/
272 ：Name_Not_Found ：02/01/30 04:09 ID:VHzX0pWb: >>271
私も行けません。サーバが死んでるのではないかと。

しかし、ブラウザ拡張ツール系の作者さんたちは打てば響くというか、
理屈にあった意見を実装で返してくれるので嬉しいですね。
陳謝。

そういや、
>>1 氏が最初に出したベンダー宛てのメールは返信があったのでしょうか...?
273 ：Name_Not_Found ：02/01/30 05:05 ID:Ud/d1S7d: >>272
>しかし、ブラウザ拡張ツール系の作者さんたちは打てば響くというか、
少なくとも自分の場合は単に暇だったあるいは現実逃避してる説が有力。笑。
274 ：Name_Not_Found ：02/01/30 05:47 ID:VHzX0pWb: >>273
その現実逃避のおかげで全国推定100万とんで6人の link 要素難民が救われてるわけで。
もう、ひらにひらにぃーって勢いです。よくわからん。
275 ：Name_Not_Found ：02/01/30 10:23 ID:fmPCqO46: >>262-265
途中から見てたものですが、本当お疲れさまです。
Strictとかユーザビリティーとか、言葉ばかり覚えて、
心のどこかで少し優越感に浸ってたんですが、
ここからまたさらに一つ上を考えてやっていかなければならないなと
思いました。
HDDを占拠中のエロ動画類を片づけて、
僕も音声ブラウザ入れてみようと思います。

[ 深夜でも快適なレンタルサーバ ]

新着レスの表示

掲示板に戻る全部次100 最新50

read.cgi ver5.29 (02/01/17)