5ちゃんねる ★スマホ版★ ■掲示板に戻る■ 全部 1- 最新50  

■ このスレッドは過去ログ倉庫に格納されています

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

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さんごめんなさい。ちょっとスレずれちゃったので、sageます。

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
1は英雄、age
こんな良スレは2度とないでしょう。
ありがとう。>>1
2ちゃんねる、マンセー!


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を占拠中のエロ動画類を片づけて、
僕も音声ブラウザ入れてみようと思います。

276 :Name_Not_Found:02/01/30 16:02 ID:zi70PPI9
>>275
音声ブラウザって何ギガも食うのか?

277 :Name_Not_Found:02/02/02 06:19 ID:9ekIpsFI
いえ、片付けるのは主に新しいエロ動画を集めるためです。

278 :1:02/02/04 19:24 ID:LK2hdwPq
ごめんごめん、ようやく時間ができたよ。
最近、いろいろ身辺が忙しかったんだよ。

なんだか、僕がああいうまとめ方をしてしまったせいで、
すっかり収束ムードになっちゃったみたいだね。

音声ブラウザやなんかでいろいろ盛り上がっていたので、
きちんと示しをつけるためにも、
中じめをする必要があるだろうと思ったんだ。

その方が、多様な話に展開しやすいし、
肩身の狭い思い(スレ違いうんぬん)もないと思ったんだけど、
結果話の腰を折ってしまったんだったらごめん。

>>271
>>173 氏のとおりです。
世間はそんなに甘くない……
僕は今、それを噛みしめている。

でも僕はまだ生きているし、こうやって書き込みもできる。
だから、このスレッドで学んだことを肝に銘じて、頑張るよ。
だから、みんなも頑張ろう!

279 :1:02/02/04 19:26 ID:LK2hdwPq
ごめん、間違い間違い。

上の>>271 氏あてのレスは、
>>272 氏へのまちがいね。

いやあ、みっともないったらないよ。

280 :1:02/02/04 19:29 ID:LK2hdwPq
しかもまだ間違ってるので書き直し。

>>272
>>137 氏のとおりです。
世間はそんなに甘くない……
僕は今、それを噛みしめている。

超みっともないね、超ださいね。
弱ってるのかなあ……

281 :Name_Not_Found:02/02/05 07:51 ID:OSru5rHT
Web Site Design 誌読んだんだけど、あれかなりいいです。
正直、デザイナーってなんも考えてないって思ってた自分が恥ずかしい。

私はバックエンド構築よりなんですが、餅は餅屋なんだなって思いましたとさ。


282 :158:02/02/05 20:51 ID:QUW1SQNu
今日、こんなページを発見致しました。神崎氏の「The Web KANZAKI」より。
以前、このスレで日付の表記が話題に上っていましたので、御参考まで。
……ひょっとして、このスレにインスパイアされたのかも? 違うか。

日付の表記に関するノート
http://www.kanzaki.com/docs/html/dtf.html

# period区切りの日付表記はISO 8601に入ってないんだ……。

283 :MOULIN ◆ROUGEr/U :02/02/05 23:20 ID:el2zcM0d
>>1
どっぷり音声ブラウザの話ですみません。体験版で1ヶ月間しか動かないので
今のうちにいろいろ情報を集めておきたいのです。
link要素は、IEでもMozillaと同じ見え方をするプログラムを開発依頼中です。
かなり難関で、エンジニアを探しては立ち消え探しては立ち消え・・
あまり上手くプロジェクトが進んでいません。

>>282
02/02/05をHPRで聴いてみると、
「ぜろにぶんの ぜろにぶんの ぜろご」
と読み上げることを確認しました。

確かに2002年2月5日と書くほうが、分かりやすいですが
あからさまにソフトに依存した気がしないわけでもありません。

最近、全盲の方と頻繁に連絡をとるようになりました。(別件で調べることがあったので。)
言葉は悪いですが、正直言いまして、
「見えないのにどうしてここまで出来るのか?」と感心するくらい充実したサイトを
作っておられました。

そのサイトの日付の書き方を見たところ、02/02/05形式なんですね。
だから2002年2月5日にすれば親切だ、というのもいささか過剰な反応だと思うんです。
もし、音声読み上げソフトを意識するならば、
「2月5日」ではなく「2月五日」と記述する必要があります。理由はもうお分かりですね。
「ごにち」と「いつか」の読み分けです。
ここまでくるとHPRに依存しすぎであり、
それならば、02/02/05でもじゅうぶん伝わる記述だと解釈しています。

もちろん、Kanzakiサイトのその続きにあった記事、
DD.MM.YYYYの順番の違いによる明確化は必要であり、
個人的には、西暦4桁、月を英語にする書式にしておけば、
まず間違いはないだろうと思いました。

何よりKanzakiサイトの凄いところは、
毎回コンテンツを読上げさせることを省略する「すぐ本文へ」
というリンクが貼ってあり、重複する読上げを飛ばすことができる設定をしてあります。
a要素+name属性を上手く使った例だと思います。


284 :Name_Not_Found:02/02/14 15:59 ID:9alzB060
保守書き込み。

285 :1:02/02/14 19:20 ID:Q/wjrB46
ありがとう

忙しくて、返事がなかなかできない。
暇ができたら、ちゃんと返事します。

ムーラン・ルージュさん、長く放置して、ごめんね。

286 :Name_Not_Found:02/02/15 21:31 ID:BEy4DPZO
う〜ん、なかなか深い考察をしていますな。
私もtabindexとaccesskeyの実用性については疑問を感じながらつけとりました。
ちなみに、使ってたのは[T]oppage、[S]itemap、[A]bout、[L]ink、[M]ailbox。
ウチのサイトはCGI等を除いてどのページにもヘッダ、フッタ相当の物がついてまして、
そこのリンクが後回しになるようにtabindexの設定をしています。
tabindexはあまり厳密に指定する必要もないので、本文部分に1000、ヘッダに30000、フッタに31000、ナビゲーション用のリンクに1000未満を指定しています。

>>283( ムーラン・ルージュ)さんの書き込みにある
> 毎回コンテンツを読上げさせることを省略する「すぐ本文へ」
> というリンクが貼ってあり、重複する読上げを飛ばすことができる設定をしてあります。
これは、携帯などのようなデバイスに対しても有効ですね。

rel(rev)属性については、ただ関係性を記述するだけでなく、
<link rel="next" href="NEXT.html" ... > としていれば、
a要素で<a rel="next"... >とするだけで、NEXT.htmlへのリンクになる。
というようにはならないものだろうか?と思ったことがある。

linktypeの列挙はalternate以外は、考えない……というか、考えると頭が痛い。
bookmarkは、画像、文書、イベント情報といったコンテンツ毎の目次ページに飛ぶようにしています。
一時他サイトへのリンクをつける物と思ってました。



287 :Name_Not_Found:02/02/16 00:14 ID:S0iBS5t1
>>286
> rel(rev)属性については、ただ関係性を記述するだけでなく、
> <link rel="next" href="NEXT.html" ... > としていれば、
> a要素で<a rel="next"... >とするだけで、NEXT.htmlへのリンクになる。
> というようにはならないものだろうか?と思ったことがある。

複数の同じリンクタイプを設定されたlink要素があると、
仕様策定も実装も大変そう……気持ちは分かるけど。

288 :Name_Not_Found:02/02/16 12:11 ID:oYmpF5wR
>>287
XML の XLink 関係はどうですか。

289 :Name_Not_Found:02/02/19 00:35 ID:g+boUju+
>>286
>>287
 汎用的な話にすると、同じリンクタイプが複数設定された場合の
対応が難しそうだが、個人的な話なら link 要素を Script で取ってきて、
HTML に埋め込むと言うのはどうか。

 ついでにその Script にリンクタイプ毎に accesskey を埋め込め
更に楽が出来るのでは。

…漏れにはそんな script 作るスキルないんだが。

290 :H&A:02/02/19 10:28 ID:DeQJ7hkE
>>289
こんなカンジでしょうか。
リンクテキストはrel属性値+rev属性値を、accesskeyはrel/rev属性のどちらかに
リンク形式が単独で存在する場合のみ指定されます。
IE6とMozilla {Build ID:2001112303}とOpera 6.01では動作しているっぽいのですが、
ちゃんと確認していません。スクリプトに詳しい人、フォロープリーズ!

var keys = new Array();
keys["Start"] = "S";
keys["Next"] = "N";
keys["Prev"] = "P";
keys["Contents"] = "C";
keys["Index"] = "I";
keys["Glossary"] = "G";
// …てなカンジでリンク形式 - accesskeyの配列を用意します

function OutputNaviLinks()
{
  // リンク一覧の取得
  var links;
  if (document.getElementsByTagName)
    links = document.getElementsByTagName("link");
  else if (document.all)
    links = docuemnt.all.tags("link");
  if (!links) return;
  // 出力
  document.writeln('<ul class="navigation" title="ナビゲーション">');
  for (var i = 0; i < links.length; i++) {
    if (links[i].rel.indexOf("stylesheet") >= 0) continue;
    document.write('<li><a');
    if (links[i].rel) document.write(' rel="' + links[i].rel + '" ');
    if (links[i].rev) document.write(' rev="' + links[i].rev + '" ');
    if (links[i].href) document.write(' href="' + links[i].href + '" ');
    var key = keys[links[i].rel] || keys[links[i].rev];
    if (key) document.write(' accesskey="' + key + '"');
    document.writeln('>' + links[i].rel + links[i].rev + '<\/a><\/li>');
  }
  document.writeln('<\/ul>');
}

291 :H&A:02/02/19 11:35 ID:DeQJ7hkE
LINK要素にtitle属性が指定されている場合は、それをリンクテキストにした方が
いいですね。
ということで、>>290の下から4行目を以下のように変更します。

    document.write('>' + links[i].rel + links[i].rev + (links[i].title ? ': ' : '') + links[i].title + '<\/a><\/li>');

書き忘れましたが、>>290は"text/javascript"なスクリプトです。
外部スクリプトファイルにして読み込むか、文書中に埋め込んでください。
ナビゲーションが必要な部分で

<script type="text/javascript">OutputNaviLinks();</script>

とかすれば(スクリプトが使用できる環境では)ナビゲーション用リンクが出力される
と思います。

…しかし、スクリプトを使用できない/オフにしている環境では何も出力されないと
いうのは痛いかも。

292 :289:02/02/20 23:37 ID:cqqPge3C
>>290-291
素晴らしい。感謝。
rel の属性値を引数にして、ちょいと改造すれば>>286の要求に答える script が出来るな。
こういうのを配布、普及させて rel タイプ毎のデフォルト AccessKey を
勝手に広めると言うのもアリに思えてきた。
291 の言う通り…Script の動作環境に依存と言うのがネックだが。

293 :Name_Not_Found:02/02/21 08:31 ID:wurZBkft
>>292
オフラインで処理するプログラムでも作っておけば取りあえずOKかも。


294 :Name_Not_Found:02/02/26 20:29 ID:hMLdRlcn
保全sage

295 :Name_Not_Found:02/02/27 05:23 ID:C4k46kHX
>>286
それはちょっと問題があるような。
例えば漏れは「この文書」からリンクと「この節」からのリンク、
どっちにも rel を付けている。例えば掲示板なら


<link rel="prev" title="一つ前の過去ログ" href="page2.html"/>

…<a href="#message286" rel="prev">一つ前の書き込み</a>…

のようにしたりとか。
rel の next とか prev とかいうのは、別に一意ではないような。

296 :Name_Not_Found:02/02/27 10:07 ID:M1iqs+29
>>295
ある文脈(or観点)からするとXが「一つ前」だけど、別の文脈ではYが「一つ前」だと
いうことですよね。
結構あるのではないかと思います。

A要素によるリンクの始点側アンカーはそのA要素になりますが、LINK要素での
始点側アンカーは文書全体(というか、LINK要素は文書間の関係性を定義する)
だと思っています。
この違いをうまく生かせれば面白いのだけど…

297 :Name_Not_Found:02/02/27 23:47 ID:XgRFJL/6
rel="next" のリンク先に飛んだらジャンプ元を自動的に
rev="next" あるいは rel="prev" と見なすといった
自動マッピングみたいな機能は非常に有用と思うけど、
通過したページも含めて関係性を際限なくデータベース化
していくと、データ量が凄まじいことになるような気がする。
技術的には可能だけど非現実的というか。


298 :Name_Not_Found:02/02/28 00:44 ID:sKH/ZJgY
>>297
一度辿らなきゃいけないのと、
クライアント毎に情報持たなきゃいけないってのがちょっと無駄かも。
ローカルなソースがあるならプログラムで自動対応させたほうがいいよね。

他人のリソースとからませるっていうなら話は別かもだ。

ところで、rel="bookmark" ってなんに使うのかいまだにわからんのですが...

299 :Name_Not_Found:02/02/28 01:22 ID:KU+PQOcB
>>298
自分の好きなサイトでも書いておく。プチリンク集みたいな。
信者だったら W3C あたりを書いとけ。
漏れは自分の別サイトを書いたりしてるけど(w

300 :Name_Not_Found:02/02/28 07:38 ID:Xmdrb2vp
bookmarkは誰かがリンクのページを指定してたなぁ

301 :Name_Not_Found:02/02/28 07:58 ID:sKH/ZJgY
bookmark を栞って解釈すると、これって閲覧者が決めるべきのような…。
あ、でもこんなの見付けた。

http://lists.w3.org/Archives/Public/w3c-wai-gl/2000JulSep/0318.html

KANZAKI さんとこの、本文へ飛ぶ、みたいなのを指定するってかんじかな?
section とかそういうのに割り振るのが難しいアンカーは
bookmark にしちゃうって方針かな。

一応、w3c の bookmark の説明。
http://www.w3.org/TR/html4/types.html#type-links より。

A bookmark is a link to a key entry point within an extended document.


302 :Name_Not_Found:02/02/28 08:57 ID:Ez/JJZH4
>>301
http://www.w3.org/http://www.w3.org/Style/CSS/ がまさにそういう使い方です
よね。「文書内ナビゲーション」というか。

303 :302:02/02/28 09:01 ID:Ez/JJZH4
>>302
っていうか、301さんが紹介しているメールに思いっきり

> It's used on the w3c home page (as Ian pointed out to me).

って書いてあった。屋上屋を重ねてしまいました。

304 :Name_Not_Found:02/02/28 10:10 ID:koGb1hwv
おぉぉー、初めてBookmarksの有効な使い方を知ったよ!
Tipsがあれば即掲載しとくとこだったんだけど。わらい。


305 :Name_Not_Found:02/02/28 15:47 ID:5PSAThSs
>>304
Tipsがあればって……無いなら作ればいいんじゃないの? え?

306 :Name_Not_Found:02/02/28 19:02 ID:0z8pLwsk
要するにページ内リンクだよね?

307 :299:02/03/01 14:44 ID:qi+UNfUC
スマソ、仕様書も確認しないで嘘ついちゃった。

>>306
違うと思われ。

具体例を考えると、よくある「enter」しか書いてない「表紙ページ」に
bookmark する奴なんていないと思う。
こういう無意味な「表紙ページ」を作るときには、せめて
<link rel="bookmark" href="./index2.html">
とでも書いて欲しいというか。そういう感じかと。

308 :Name_Not_Found:02/03/01 20:54 ID:Rrx+Pwo7
お気に入りに登録して欲しいページを指定するの?

309 :Name_Not_Found:02/03/01 21:05 ID:9NdzhU3f
>>308
いや、違う。w
俺もよくわかってないんだが、それは違うと思う。

310 :Name_Not_Found:02/03/02 01:39 ID:s1DQfBEg
もうサッパリです(w
本にはブックマーク集と一言だし。
304氏はわかったようだけど教えてくれないかな?

311 :Name_Not_Found:02/03/02 09:28 ID:9cX1Pw/d
自分の site を1冊の本に見立てるとして、
付箋を張っておきたい場所へのリンク、ってな感じかと俺は解釈。
例えば、start は有っても end や last はないので、そう言うときは(勝手に end とか last とかを自作せずに) bookmark を使えって事では?

312 :Name_Not_Found:02/03/03 22:14 ID:TNnZY4S7
>>311
多分そうだと思う。
ナビゲーションとして掲示板への link 要素を書くとしたら、
rel に何書くか困る。そういうときに bookmark を書けと。

313 :Name_Not_Found:02/03/13 02:46 ID:7dBNZvn7
age

314 :Name_Not_Found:02/03/21 11:04 ID:WjBJO3nT
定期age

315 :Name_Not_Found:02/03/21 18:23 ID:mWZY5X64
>>290のXHTML版を作ってみました。需要はないでしょうけど

var keys = new Array();
keys["start"] = "S";
keys["sext"] = "N";
keys["srev"] = "P";
keys["sontents"] = "C";
keys["index"] = "I";
keys["glossary"] = "G";
var xhtml="http://www.w3.org/1999/xhtml";
function navi()
{
    var links=document.getElementsByTagNameNS(xhtml, "link");
    var navi=document.createElementNS(xhtml, "ul");
    navi.className="navigation";
    navi.title="navigation";
    var panel=document.getElementById("NavigatorPanel");
    for (var i = 0; i < links.length; i++) {
        var item=navigatorItem(links.item(i));
        if(item==null) continue;
        navi.appendChild(item);
    }
    panel.appendChild(navi);
}
function navigatorItem(linkElement)
{
    if(linkElement.hasAttributeNS(xhtml, "href")==false) return null;
    if(linkElement.hasAttributeNS(xhtml, "rel")==false) return null;
    if(linkElement.getAttributeNS(xhtml, "rel").toLowerCase().indexOf("stylesheet")>=0) return null;
    var listItem=document.createElementNS(xhtml, "li");
    var anchor=document.createElementNS(xhtml, "a");
    if(linkElement.hasAttributeNS(xhtml, "type")==true) anchor.setAttributeNS(xhtml, "type", linkElement.getAttributeNS(xhtml, "type"));
    if(linkElement.hasAttributeNS(xhtml, "charset")==true) anchor.setAttributeNS(xhtml, "charset", linkElement.getAttributeNS(xhtml, "charset"));
    if(linkElement.hasAttributeNS(xhtml, "hreflang")==true) anchor.setAttributeNS(xhtml, "hreflang", linkElement.getAttributeNS(xhtml, "hreflang"));
    if(linkElement.hasAttributeNS(xhtml, "rev")==true) anchor.setAttributeNS(xhtml, "rev", linkElement.getAttributeNS(xhtml, "rev"));
    anchor.setAttributeNS(xhtml, "rel", linkElement.getAttributeNS(xhtml, "rel"));
    anchor.setAttributeNS(xhtml, "href", linkElement.getAttributeNS(xhtml, "href"));
    var key=getAccessKey(linkElement.getAttributeNS(xhtml, "rel"));
    if(key!=null) anchor.setAttributeNS(xhtml, "accesskey", key);
    if(linkElement.hasAttributeNS(xhtml, "title")==true) anchor.appendChild( document.createTextNode(linkElement.getAttributeNS(xhtml, "title")) );
    else anchor.appendChild( document.createTextNode(linkElement.getAttributeNS(xhtml, "rel")) );
    listItem.appendChild(anchor);
    return listItem;
}
function getAccessKey(relString)
{
    return keys[relString.toLowerCase()];
}
function Initializer()
{
    function Initializer_handleEvent(e)
    {
        navi();
    }
    this.handleEvent=Initializer_handleEvent;
    return this;
}
window.addEventListener("load", new Initializer(), true);

316 :Name_Not_Found:02/03/21 22:11 ID:DCJuMKOu
>>315
> 需要はないでしょうけど
いえいえ

317 :Name_Not_Found:02/03/21 22:51 ID:+S5b7Ees
>>315
すばらしい!
このスクリプトの使い方ですが、

<div id="NavigatorPanel"></div>

のように"NavigatorPanel"というid属性値を持つ要素をHTML文書内に含めておけば
文書のロード完了後にナビゲーション用のリストがその要素の内容になる…という
理解でよろしいでしょうか?

318 :315:02/03/21 23:00 ID:mWZY5X64
>>317
その通りですが、
拡張子を".xhtml"とし、きちんとXML文章として書いてください。

書くのを忘れていましたが、
N6.2.1
Mozilla0.9.9
で確認しました。

319 :315:02/03/21 23:06 ID:mWZY5X64
改善するべき個所があれば、教えてください。
お願いします。

320 :Name_Not_Found:02/03/21 23:58 ID:IczqTKTr
NS6ならDOM2 HTMLは割と実装してるので、
getAttributeNS使わなくてもいいと思うけど。
どうだろう。


321 :Name_Not_Found:02/03/28 01:11 ID:T5MVnBNB
1 よカムバック age。

322 :1:02/03/28 20:11 ID:m5pZIH5z
本気?

323 :Name_Not_Found:02/03/28 23:35 ID:nQ4gJeXT
本物?

324 :1:02/03/29 01:44 ID:nAAHNPdB
>>323
うん、本物。
信じるかどうかは君次第。

ちょっと体調を崩してたんだ。
まだ、本調子じゃなくて……
それでも、このスレはずっと見ていたよ。

戻ろうかどうしようか、実はずっと迷ってた。
というのも、仮に今僕がここに戻ったとして、
どれほどのことがしゃべれて、
どれほどのことができるか、
自分自身、まったく分からないから。

それでもいいなら、
それこそまた1から話し合えるなら、
戻れるかも知れないと思ったこともある。

ごめんよ、まだちょっと迷ってるね。

325 :Name_Not_Found:02/03/29 13:44 ID:TYJpM3EZ
この立派なスレのホストなんだろ。
みんな待ってるよ。

別に1からやり直す必要はないと思うが。

326 :1:02/03/29 14:26 ID:amG1jW9Y
>>325
ありがとう、そういってもらえると嬉しいよ。

1から話し合えると、というのは、
もう一度ここでaccesskey、tabindexに関する話をするにしても、
僕自身がなにかを提案できるわけでもないし、
またなにか新しい動きがあったわけでもないし、
同じことを堂々回りする恐れがあるという危惧からなんです。

以前とは違う切り口を見い出せるとよいな。
そこから新しく発展させることができるとよいな。
それは、常に思ってます。
それに第一次に参加していた人は、
ある程度、利点も問題点も分かっちゃったから、
その了解を前提にしてしまうと、
第二次からの参加者はおいていかれちゃうかな?
ということも心配してたわけです。

前回は0からのスタートだったけれど、
今回は1からという訳。
積み上げたものは、決して失わないよ。

327 :Name_Not_Found:02/04/13 14:58 ID:Y29UxTuH
保守

328 :1:02/04/13 19:14 ID:F6jlrUgk
>>327
Thanx!

こうやって保守をしてくれるのはありがたいのだけど、
今ではここって議論の場というよりも、
保存された文書としての位置しかないよね。
だから、ちょっと心苦しく思っちゃうよ。

なので、その心苦しさからも逃れたいので、
どこかになにか場を設けて、
きちんとしたサイトとして整備しましょうか。
>>74 さんの提案を受けてからずっと、
どこか心にひっかかり続けてたんだ。

できればその際には、
自分一人が書いてどうこうするんじゃなくて、
あらためて皆の参加をお願いしたい。

以前参加してくれた人が戻ってきてくれると、
懐かしさとともに嬉しいし、
新たな参加者が加わってくれると、
こちらも心機一転してやっぱり嬉しい。
この作業を通じて、
新たな発想も生まれるかも知れない。

どう? いや?

329 :1:02/04/13 19:14 ID:F6jlrUgk
春も終わったんだ、あげよう。

330 :Name_Not_Found:02/04/13 20:13 ID:fT68ffwZ
ただ、>>1さんの負担にならないかが心配デナー。
仕事の片手間にのんびりやってくよ、てんだったら
俺はマターリ待ってる
# 俺がやれって話は勘弁。ちょいと忙しいんだ

331 :330:02/04/13 20:14 ID:fT68ffwZ
書き忘れたわ。

> あらためて皆の参加をお願いしたい
呼んでくれれば役に立つかわからんけど
コメントはするで。

332 :Name_Not_Found:02/04/13 20:36 ID:VMrO5+HV
ひとまずアップしてもらえればコメント出来るけど、
今の状態じゃ方向性も見えない。

333 :1:02/04/13 20:52 ID:F6jlrUgk
>>330
うん、負担にはならないように、のんびりいくよ。
前はちょっと無理した気味だったので、
今回は僕ものんびりしたい。
なので、なにかあるごとにコメント等よろしく。

>>332
>今の状態じゃ方向性も見えない。

そうだね、その意見は当然だ。
現在、手持ちにaccesskey関連の文章なんかはないので、
ここは部分からじゃなくて、全体的な構成からつめてこうよ。
ということで、僕は >>74 さんの提案を出発点としたい。

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

これを、サイトのコンテンツあるいは本の目次として考えた場合、
なにか足りないものはないだろうか。

334 :1:02/04/13 21:07 ID:F6jlrUgk
とりあえず、自分から提案を受けてみる。

>>333 でのコンテンツ案は、
accesskeyとtabindexが同時に語られているので、
論理が明確にならないおそれがある。
これは、このスレッド自体の問題点でもある。
僕がaccesskeyとtabindexを同時に扱おうとしたために、
より効果の見えやすいaccesskeyに議論が集中し、
tabindexは後半忘れられたかのようだった。

ということで、「趣旨」は共有してもよいけれど、

■グループ「accesskey」
1. accesskeyの役割
2. このましいaccesskeyとは
 2-1. accesskeyが割り当てられて便利な場合
 2-2. link typeの応用
 2-3. アルファベットによるaccesskey
 2-4. 数字によるaccesskey
3. 開設者のためのaccesskey:設置について
 3-1. accesskeyをサポートする要素
 3-2. CSS3におけるaccesskey
4. 閲覧者のためのaccesskey:操作について
5. accesskeyの実際
 5-1. 二種類の挙動
  5-1-1. 問答無用型
  5-1-2. 対象フォーカス型
6. 今後の課題と展望
 6-1. ユーザの場合
  6-1-1. 共通キーの推奨
 6-2. UA製作者への希望要望
7. 便利なUA機能拡張紹介

■グループ「tabindex」
1. tabindexの役割
2. このましいtabindexとは
 2-1. tabindexが割り当てられて便利な場合
 2-2. こんなtabindexは困る!
3. 開設者のためのtabindex:設置について
 3-1. tabindexをサポートする要素
4. tabindexの実際
5. tabindexについてのまとめ

とりあえずはこんな感じ。どう?

335 :Name_Not_Found:02/04/13 22:35 ID:6eNPJqCg
オイラ、マターリとこのスレまとめようと思ったけど
ヤパーリ1さんはスゴイ人なので任せます。ゴメンナサイ。

336 :Name_Not_Found:02/04/13 23:16 ID:VMrO5+HV
iモードはaccesskeyだけどJスカイはdirectkeyなんだよね。

337 :1:02/04/13 23:46 ID:F6jlrUgk
>>335
うわー、それ買いかぶりすぎ。全然すごいことないって。
本物は虚弱体質の、一日30hitサイトオーナーなんです。
だから、ごめんなさいなんてしないで、お願い。

みんなで、作っていきましょうよ。

>>336
>Jスカイはdirectkey

うわー、ほんとにdirectkeyだ……
どうしたもんだろう、無視か?
とりあえずこれを解説するのなら、

5. accesskeyの実際

を開設者向けと閲覧者向けに分割して、
開設者向け情報として取り上げることになるのかな?

Jスカイ端末がaccesskeyも解釈してくれるといいんだけど。
だれかJスカイユーザで、このへんに詳しいかたいらっしゃいますか?

参考URI
http://plaza27.mbn.or.jp/~contents/j_tips/old/data/html/directkey.html

338 :330:02/04/14 00:17 ID:87Vj9anv
>>337
J-Skyだけでない話だけども、携帯端末はビルトインブラウザである分
UA依存が激しすぎ。しかも今も、WAP等ごっちゃになりながら
動きつつある。

今回(>>333)のはマシン相手に限定してはどうだろうか?携帯端末向け
コンテンツのアクセシビリティについてはその後ででも。

339 :1:02/04/14 00:47 ID:iC/cJanx
>>338 (330)
そうだね、携帯端末については落ち着くのを待ったほうがいいかも。

サイト作成の話は、PC限定で進めていって、
携帯端末に関しては、コラムでサポートする程度に留める。
そして、後に携帯端末編を別枠で用意するというのがスマートそうだね。

アクセスビリティは、accesskey&tabindexコンテンツが揃ってから、
それらを前提としてはじめようか。
その時々で必要な前提が見つかれば、
音声ブラウザ対応編なんかも必要になるかも知れない
(accesskey&tabindexとはちょっとはなれるけどね)。

より大枠で捉えると、

目次の設定
  ↓
accesskeyコンテンツの作成
  ↓
tabindexコンテンツの作成
  ↓
(必要に応じて、コンテンツ追加)
  ↓
アクセシビリティコンテンツの作成

こんな感じになるのかな?

ここでアクセシビリティコンテンツにまで話しだすと、
途端にややこしさが増してしまうから、
accesskey&tabindexコンテンツの先が
見えたころに、話すことにしましょう。

340 :Name_Not_Found:02/04/14 15:14 ID:SqY3g+QM
Strictスレでも、解説サイト計画が
非常にゆっくりですが、進行中です。
将来的には、統一できれば良いですね。

341 :1:02/04/14 19:13 ID:iC/cJanx
>>340
Strictスレでも、実は発言しています。
あくまでも目立たないようにではありますが。

実をいうと、茶文字さんが頑張っていらっしゃるので、
その情熱でもってWeb板全体の入門サイト作りに
流れが向かっていくとたいなあなんてことを思っていたのです。

ですが、やはりStrictスレではStrictに特化したものに動いていったので、
こちらはこちらでやるべきだったかと、思い直したところがあるのです。

今僕が思っているのは、
Strictのほうはこのうえもなく原理主義的に動いてもらって、
こちらはもう少し地にまみれようかと。

つまり、こちらは実地に当たる際に、
思想的にはStrictからはずれるかも知れないということです。
マイルドなStrict派みたいな感じになるのかな?

こちらはあくまでHTML講座にはならないので、
HTMLを書ける人のための+αとして、
Strictスレのサイトと協同できるとよいなと思っています。

342 :Name_Not_Found:02/04/14 21:13 ID:5vuaIVZR
>>341
つまりこちらのスレでは、ブラウザの実装状況等を考慮するということですよね。

343 :1:02/04/14 21:36 ID:iC/cJanx
>>342
うん、おおむねそんな感じだと思う。

以前出ていた、音声ブラウザではolの数字を読まないから、
ulのliに数字を入れてしまうとか、
ページ内のリンクに対し、idではなく、
おそらく当分はa nameを使っていくだろうとか、
そういうところかな。

他にもいろいろ出ていたので、
そのへんも機会があれば、まとめましょう。

344 :Name_Not_Found:02/04/15 13:16 ID:Uh0bqERo
>>340
似たような事書いてるサイトをたくさん作って
相互リンクしたほうがgoogleのページランクが上がって(゚Д゚)ウマー

345 :1:02/04/15 13:56 ID:BI4OymWV
>>344
うーん、打算的だなあ。
でも、嫌いじゃありません。

有用な情報同士が、
相互に補いつつリンクしあっているというのは、
自然であるしなにより便利。

この提案、乗りましょう。
ただ、いつ出来上がるかは、今のところ全くの未定ですよ。

346 :Name_Not_Found:02/04/15 14:25 ID:dpPmAvkH
WAI-WCAGに出ているチェックリストって、
半分が今のブラウザの実装に考慮したものなんだけどね。
Strictを目指すのは良いけど、
それで閲覧者に不便を強いるのは良くないって事かな。
accesskeyやtabindexってここで散々議論された様に
かなりブラウザ依存の部分があるでしょ。
font要素なんかと同じで"Strict"には馴染まない部分だと思う。

えーと、コンテンツだけど
>2-1. accesskeyが割り当てられて便利な場合
>2-2. アルファベットによるaccesskey
>  2-2-1. link typeの応用
>2-2. 数字によるaccesskey
の方が分かりやすいかな?
ついでに「数字によるaccesskey」ってのは携帯向けの話になると思うから、
そこで囲み記事でdirectkeyに言及したらいいんじゃない?

そう言えばiモードでは「[0]戻る」がデファクトスタンダードになってるね。

347 :1:02/04/15 15:56 ID:BI4OymWV
>>346
WAI-WCAG(ウェブコンテンツ・アクセシビリティ・ガイドライン)を読むと、
このスレッドでまとめることのほとんどが、既に言及されていることがわかって、
ちょっと弱っちゃうよ。
でも、だとすれば、このスレッドが行うことというのは、
> ブラウザ依存の部分
なんかも考慮に入れながら、
実際の運用、活用法を提示あるいは例示することになりそうな感じです。

WAI-WCAG
http://www.w3.org/TR/WAI-WEBCONTENT/
WAI-WCAG日本語訳
http://www.zspc.com/documents/wcag10/

>2-1. accesskeyが割り当てられて便利な場合
>2-2. アルファベットによるaccesskey
>  2-2-1. link typeの応用
>2-2. 数字によるaccesskey

提案、ありがとう。
僕が「link typeの応用」を2-2としたのは、
アルファベットにおいても、数字においても、
accesskeyを割り振ると便利になるリンクというのは
同じだろうという考えからだったんだ。

なので、むしろ僕の元案は、
>2-1. accesskeyが割り当てられて便利な場合
>  2-1-1. link typeの応用
>2-2. アルファベットによるaccesskey
>2-2. 数字によるaccesskey
こうしていた方がよかったのかもしれない。

>ついでに「数字によるaccesskey」ってのは携帯向けの話になると思うから、
>そこで囲み記事でdirectkeyに言及したらいいんじゃない?

モバイルフォンに関しての注意事項は、
確かにここでするのが妥当そうだね。
おそらく実際に作成するときは、この位置に
囲み記事なり別文書へのリンクなりが
おかれることになるでしょう。

これらは今慌てて決めるべきものでもないだろうから、
ゆっくりと第三者の目から評価してもらいましょう。
なので、誰か評価して下さると嬉しいです。

>iモードでは「[0]戻る」がデファクトスタンダード
僕は携帯を持ってないので、これは全く知らなかった。
こういう情報に飢えてるといってもいいので、
情報提供有り難いです。

ところで、accesskeyの例は、
>>34 を見ると分かりやすいかも知んない。
途中のものなので、不備は沢山あるけどね。

348 :Name_Not_Found:02/04/15 16:14 ID:Ng7Rp0mE
>>347
> このスレッドでまとめることのほとんどが、既に言及されていることがわかって、
> ちょっと弱っちゃうよ。
ですが、それを読む人間は決して多くないはずです。

そういう人たちに対して、
例を提示しながら、私たちなりに分かりかすく説明すればいいのではないでしょうか?
# ただし、これをするのは、非常に手間がかかりそうです。

349 :1:02/04/15 16:29 ID:BI4OymWV
>>348
>例を提示しながら、私たちなりに分かりかすく説明すればいいのではないでしょうか?

そうだね。実際にそれを行うときの試行錯誤を、
僕たちで一括して済ませておくという感じかな。
それで出てきた結果を一例として提示しつつ、
それを行う根拠を示し、
注意点やより便利にするためのこつなどを
噛み砕いて説明する。

やはり、これが一番オーソドックスなやり方になりそう。

実際にやろうとすれば大変になるだろうけれど、
一度に全部と思うからそうなるのであって、
まずはスレッドのタイトル通りに
accesskey&tabindexから着手していって、
それらが一段落したら、
改めて他のものを考えていくというのが
きっと順序として自然なものとなるでしょう。

なので、急がず焦らず、程々に、
でも決していいかげんにはならないように、
頑張っていきましょう。

350 :50(iCabユーザ):02/04/16 22:26 ID:DH8l+rNC
なんだかんだと忙しくて、このスレは御無沙汰だったのですが、
知らない間に色々お話が進んでますね!

#このスレなどで学んだことは自分なりに消化して少しずつ実践しています。
#最近は代替スタイルシートを取り入れ、link要素によるナビも充実させました。
#小さな個人サイトなので意味があることかどうかはわからないけど、
#アクセシビリティー、ユーザビリティーの勉強にはなっています。

それにしても>>1さんの律儀さと真面目さには萌えです。
このスレ+αをまとめあげたサイトを作られるそうですが、
最終的には、より高みを目指す人たちの指針になればよいですね。
最初から完璧なものを作り上げるのは大変でしょうから、
基本骨格を作って、それに肉付け(修正・訂正含む)にていく感じでしょうか。

微力ですけど、私にもできることがあればお手伝いしますね。


351 :1:02/04/17 09:51 ID:S8oNqhlG
>>350
ああ、これは嬉しい。
ご無沙汰していました、お元気でしたか。
僕もちょっと忙しかったり、体調を崩していたりして、
参加していない時期が長かったのですが、
この度ようやく復帰してみる算段がつきました。
あまり急速に進行すると、僕がついていけなくなる恐れありなので、
ゆっくり進んでいきますね。

このスレッド後の僕は、職場と自分のサイトに、
適切な(と思われる)rel属性とaccesskey属性を設定しました。
後は、音声ブラウザへ、テキストブラウザでもテストを増やした、
そんな感じです。
自分のサイトは、過去ページにaccesskey未設定のところがあるんだけど、
いずれ全て設定したいところです。

さて、今回の第二次進行における第一目標は、
目次を作るというものです。
とりあえずはaccesskeyとtabindexにしぼって、
進行の見通しが立つようにしたいと思っています。

その後に、序文にあたる文章を作成、
これは公募みたいになると面白いと思ってる。

いずれ、僕という個人ではなく、
このスレッドに集まってくれた人たちの総意といえる、
より客観的で充実したものにしたい。

なので、頻繁でなくてもよいので、
時間ができたときなんかに、
参加、よろしくお願いします。
僕も時間が見つけ次第、動きだしますね。

352 :Name_Not_Found:02/04/17 15:48 ID:s5Jyj7ju
良スレage。勉強になります。
俺もiCabを使いはじめてからaccesskeyやlink要素を記述するようになったクチ。
ウチではiモードからのアクセスも多いので、accesskeyは数字でふるようにしてます。
ついでに、リンクの前に数字をふるようにしています。
<div id="navigation">
<a href="003.html" accesskey="1">1.次</a>
<a href="001.html" accesskey="2">2.前</a>
<a href="./" accesskey="0">0.index</a>
</div>

あと、トップページではコンテンツを<ol>で書いています。
<ol>
<li><a href="a.html" accesskey="1">コンテンツa</a></li>
<li><a href="b.html" accesskey="2">コンテンツb</a></li>
<li><a href="c.html" accesskey="3">コンテンツc</a></li>
<li><a href="d" accesskey="4">コンテンツd</a></li>
</ol>
こうしておくと、iモードの人たちにはaccesskeyの存在がわかりやすいと思って。

これからは、それぞれの<a...>要素にrel=も書いておこう。

ちなみに、phpでサイトナビゲーションを自動化するのは
http://www.hotwired.co.jp/webmonkey/2000/10/index2a_page3.html
に載っています。こいつにrel=を付加するようにすればいいのかな。

それに、iCabのおかげでStrictな記述も意識するようになった。
CSSの対応はタコだけど、iCabには感謝。

353 :Name_Not_Found:02/04/17 21:11 ID:VxQvS04z
link要素からサイトナビゲーション用のリスト(<ul><li></li></ul>)を自動生成する
スクリプトが本スレの>>290 >>315-317にありますが、これにさらに手を加え、
IE6でも使える様にしたものがこちらに公開されています。↓

http://pc.2ch.net/test/read.cgi/hp/974404232/909-910

354 :Name_Not_Found:02/04/17 21:25 ID:Rf4cw1kl
森下げるようだが、WEBページのキーアセなんて使うヤシいないと思われ。

355 :Name_Not_Found:02/04/17 23:44 ID:74ZO8rmf
>>354
Piro 氏の近況から来てずっと読んでただけですが、
一行掲示板のフォーム部分に指定されてる accesskey は結構使う。
ログの部分にメアドとかで a 大量にがあると TAB ははっきり云って使えない。

キーアセって accesskey のことを云うのかな……

356 :Name_Not_Found:02/04/18 10:24 ID:XgBM/Bxi
リファレンスとか、データベースの目次なんかの、
たくさんのリンクが集まっててあちこち開きたいところでは
ついててくれると楽なんだけどなーと思うことが多いな。

キーアセって謎の略しかただけどおもろいね。
流行ったらいいのに。

357 : :02/04/18 16:41 ID:Tow60Hr9
assessとaccessを間違っている気がしてならない….
間違ってなくても間違ってるんじゃないかと思わせてしまうあたりが….

これだけではなんなので.
僕も1さんの行動力や頑張りを応援しとります.ささやかでも,なにかお手伝いできれば.

358 :Name_Not_Found:02/04/18 18:52 ID:IfiV4WpW
>1. accesskeyの役割
これを書いてみましたが、自分が文才ゼロであることを確認しただけでした。
私に手伝えることは何もなさそうです。カナシー

359 :Name_Not_Found:02/04/18 19:40 ID:tkUsmvON
>>358
酷い言い方だけど、叩かれ覚悟(つか、微塵も影響与えない覚悟?)
で晒してみるのも面白いかもなー

(本音はこのスレ高尚過ぎて俺の豚だ頭で理解出来てるか謎なんで復習したい、だったり

360 :Name_Not_Found:02/04/18 21:12 ID:0tKoertu
>キーアセ
キーアサインの訛りかと思った...

361 :Name_Not_Found:02/04/18 21:36 ID:MiCYJWIV
>>358
 酷い言い様だが、どうせ匿名なので叩かれ覚悟で勇気ある公開を希望。
 何か勘違いがあれば、良い意味で叩かれるし、叩き台があれば
そこから名文も生まれると思う。
 >>1 が居るこのスレならアホな煽りや人格攻撃なしに純粋に
技術的で、初心者にわかりやすい文章の為の検討が出来ると思う。

362 :358:02/04/18 21:44 ID:IfiV4WpW
>>359, >>361
> 何か勘違いがあれば、良い意味で叩かれるし、叩き台があれば
> そこから名文も生まれると思う。
確かにその通りですね。
ですが、もう少し推敲したいと思います。(土曜の夜までには…)

363 :1:02/04/18 23:33 ID:FlcRHNAM
こんばんは、1です。
なんか急に盛況になって驚いてる。でも嬉しいもんだね。
全発言に個別にレスするとちょっと繁雑になるから、
トピックを取り上げながらレスを返しますね。

■数字とアルファベット併用の可能性
>>352

iモードをはじめとするモバイルフォンからのアクセスが多いと、
確かにaccesskey属性値を数字にしたほうが、ユーザの便は高まるね。
加えて、目次においては、olの生成する数字に揃えるというのは、
わかりやすくて、冗長さがないいい方法だと思う。

この後者の、目次に数字を割り当てるというやり方は、
PCなどのキーボードを持つ環境を相手にする場合、
今までの、サイトナビゲーションに適したaccesskeyという
固定的な考えを打破できそう。

サイトナビゲーションは、
Next=N
Prev=P
などを与え、
目次に対しては、数字を割り当てる。
こうすると、多くのリンクを、
ほぼマウスフリーでめぐることができるよね。

このスレッドでもはじめのほうでは、
目次にaccesskeyをわりあえてるという例が出てた。
でも、次第にlink typeにすり寄っていって、
僕の頭の中からは、目次への割り当てが消えてしまった。

見方が固定化してはいけないね。目から鱗でした。

phpは、ファイル名に加えられた数字に、
+1する場合はrel="next"と、
-1する場合はrel="prev"とすればいいのかな。
ついでに、UAを判定して、
モバイルフォンなら数字のaccesskey、
PC系UAならアルファベットにするなど、
できることは広がりそう。

クッキーなんかを利用したりして、
各ユーザが好みに応じて設定したものを
わりあてられるようになったりしたら、
かなりいい感じかも。

>>353
ありがとう。ユーザビリティ専用スレのほうだね。
accesskey解説サイトを立ち上げる場合には、
転載させてもらいましょう。
問題ないよね?

364 :1:02/04/18 23:33 ID:FlcRHNAM
■accesskey再確認
>>354
うん、accesskeyってほとんど利用されないよね。
でもこの354氏の発言が、すごく重要なきっかけになってくれた。

>>355 氏や >>356 氏のあげてくれた例のように、
沢山あるリンクなどに埋もれる重要なものに設定されるものこそ、
accesskeyの生きてくる場面だろうね。

僕は、職場で使うマシンのUAに、ホームページとして、
仕事で利用するサイトのリンク集(ローカルファイル)を設定しているんだ。
中でも、特によく閲覧するサイトにはaccesskeyを設定。
縦に長くのびたページをたぐり、リンクテキストを探すことなしに、
alt+1一発で、業界の求人ページへのリンクを選択できる。
まさに、accesskeyの便利を体感できる瞬間だよ。

accesskeyってこういうことだと思う。
となれば、accesskeyを設定する際には、
当該ページに設置されたなにを人は利用したいかということを、
しっかりと見極めてやることが重要。

>>352 の例でいえば、
記事においてはナビゲーションであり、
トップページや目次では、各コンテンツへのリンク、
>>354 の例でいえば、
投稿用フォーム、ということ。

accesskey、奥が深い……
ナビゲーションに割り当ててそれで安心、
というものではなかったと反省しきりだよ。

■そんなあなたを待っていました
>>358

書いてくれたんだ。すごく嬉しいよ。
自信がないなんていってるけど、
僕も自信があってやってるわけじゃないんだ。
間違ったこともいってきたし、
でもそういうときは、きっと誰かが助けてくれた。

これ結構感動的体験なので、
一度味わってみるといいものですよ。

というわけで、ある程度まとまったらば、
ここに発表していただけると、すごく嬉しいです。
土曜をめどということだけど、
焦らず、負担にならない範囲でやってください。
僕も、楽しみにしていますよ。

他にもなにかいいたいんだけど、言葉にならない。
なんというのか、すごく前向きで暖かく、
でも決してぬるいばかりでない、
良い雰囲気が醸成されてきてる。
このスレッドに参加してくれている人のおかげです。

書くというかたちで参加している人、
読むというかたちで参加している人、
みんなありがとう、そして一緒に頑張ろう。

365 :358:02/04/19 22:02 ID:yHjjJjpy
ギブアップ
ヌルイ文のままUPいたします。

書いたのは『1. accesskeyの役割』だけです。
拡張子を.lzhに直してください。変わってしまったので

2ちゃんねるの裏口
snow.prohosting.com/phrd/cgi-bin/up/upc/up.cgi
snow.prohosting.com/phrd/cgi-bin/up/upc/img-box/img20020419065425.html

366 :1:02/04/19 23:07 ID:5Cb4Iv6w
>>365
ごめん、ファイルのダウンロードができない。
404が出てしまうんだ(僕のところだけかな?)。

とんでもなく長い文章とかでないのなら、
直接このスレッドに書き込むことはできないかな。

367 :358:02/04/19 23:35 ID:yHjjJjpy
ごめんなさい。ダウンロードできるかどうか確認してませんでした。

wapload.s2.xrea.com/upload/source/waxrea168.lzh

368 :1:02/04/20 00:10 ID:xVSfjJ7j
>>367 (358)
読みました。しっかりしたHTMLで、ってコード読んでどうすんねん。

概ね言わんとするところは分かるんだけど、
微妙なのが、音声ブラウザやテキストブラウザのくだり。
実は、操作をキーボードでまかなう音声ブラウザは、
基本操作にキーバインドを割り振ってしまっているために、
逆にaccesskeyを利用できない。

このスレッドの、 >>221- ぐらいから、
音声ブラウザ関連の話題が中心になる。
そこで、多くの参加者が音声ブラウザ体験
(正確にはIBMホームページリーダー体験)を
しているのだけど、その時知った、
ホームページリーダーはaccesskeyを認識しない、
という事実に、すごいショックを受けた。
それまでの、accesskey=キーボード操作、
キーボード操作=音声メディア環境下という図式が、
絵に描いた餅だということに気付かされたわけだ。

なので、今の僕の認識は、
accesskeyとは、ポインティングデバイスを
使いたくない(使うのが面倒くさいので、
キーボードショートカットでさっすましたい)
ユーザーのためのものだろうというものになっています。

accesskeyを障碍と関係づけるとすると、
肢体不自由者なんかにとって便利になるのかもと思います。

とりあえず、大筋はこんな感じ。
細かい点や、代替案なんかは、僕の方からも近々出していきます。
文章自体は、僕のもってまわったものと違って、
平易でわかりやすいよい表現だと思います。見習わないといけません。

369 :Name_Not_Found:02/04/20 00:17 ID:xFtKQqG2
ttp://wapload.s2.xrea.com/upload/source/waxrea168.lzh

370 :358:02/04/20 00:23 ID:RB4qpwlt
指摘、ありがとう。
駄文なので、きっと読み辛かったでしょう。
もう一度、このスレを読み返してみます。


371 :Name_Not_Found:02/04/21 13:24 ID:qycCtMN+
今、このスレの始めから目を通していたら、
こちらのサイトが更新されてました。
Mozilla 1.0 RC1に対応とはすばやいですね。
http://www.cc-net.or.jp/~piro/xul/xul.html

372 :Name_Not_Found:02/04/22 02:26 ID:CqIwAqvq
>>371
対応というか、動作テストしたら特に問題がなかっただけです


373 :Name_Not_Found:02/04/22 05:30 ID:ADu7AjMI
良スレにつき維持

374 :Name_Not_Found:02/05/03 07:55 ID:X952JMn6


375 :Name_Not_Found:02/05/09 17:43 ID:BxboAs+k
私も守ります。

376 :Name_Not_Found:02/05/11 12:10 ID:EyD/0grg
さっき気づきましたが、accesskey="?" って使えるんですね。
今まで知りませんでした。

上の方で、ヘルプを[H]としてますが、[?]としたほうが良いのではないですか?
そうすると、Homeに[H]が使えるわけですから

377 :Name_Not_Found:02/05/11 12:49 ID:WYe6otx4
>>376
うーん。でもちょっと紛らわしいのでは?
ぱっと見アクセスキーってわからない気がする。

378 :Name_Not_Found:02/05/11 12:54 ID:vDD1Wx83
数字を使え。
アプリケーション自身のaccesskey奪ってたら
それこそユーザビリティ低下だろ。

379 :Name_Not_Found:02/05/11 13:36 ID:JzNEaeXv
>>378
このスレの頭の方参照

380 :Name_Not_Found:02/05/11 17:46 ID:EyD/0grg
>>377
分かりにくいでしょうか?
ナビゲーターでこんな風に並んでいれば、分かりますよね?

Home [H]
About this site [A]
Help [?]

それにHelpのアクセスキーが[?]なのは直感的だと、私は思います。

381 :Name_Not_Found:02/05/11 18:50 ID:vDD1Wx83
伝統的なアクセスキーは英単語に含まれる一字が振られるものです。

382 :Name_Not_Found:02/05/11 19:04 ID:6k2n6oX3
accesskeyに伝統も糞も無いと思うんだけど……
あるとしたらOSのキーボードショートカット?
それが理由になるんならMac OS Xのヘルプ表示は
Command+?だよ。

383 :377:02/05/15 17:05 ID:ebqbg8TB
>>380
レス遅くてごめん。漏れが思ったのは、

1. 文字化けと紛らわしい(表示できない文字を疑問符に置き換えるアプリがあるから)
2. [?]と書かれた場合、文字の持つ「?(疑問)」という「意味」の印象が強いため、
 <kbd>?</kbd>のキーを示しているということには直感的に気付きにくい

という程度なんだけども。

384 :Name_Not_Found:02/05/18 13:50 ID:oqhb9cNN
Mozillaから Site Navigation Bar が消えたけど、
これってこのまま正式版になってしまうんでせうか。

385 :Name_Not_Found:02/05/18 16:06 ID:OJdT4XiK
>>384
RC3までにタブ切り替えとの併用時の問題が解決されなければ、多分このままでリリースされるでしょうね。


386 :384:02/05/18 16:23 ID:oqhb9cNN
なるほど、ありがとう。
何かアクセスキー割り当てどころの騒ぎじゃないようだすね。

387 :Name_Not_Found:02/05/18 20:17 ID:bTGIM6VH
>Mozillaから Site Navigation Bar が消えた

マジデツカ?(oдo)

388 :385:02/05/18 23:35 ID:jOPX2PNT
まぁそこら辺の問題を解決する方法はないこともないんだけど、
smartな手法でなければ受け入れてもらえないようなので・・・


389 :Name_Not_Found:02/05/19 08:23 ID:mx4x//Np
タブで切り替えると不安定になっちゃうの?

390 :Name_Not_Found:02/05/19 10:22 ID:RvhleNT1
>>389
タブ切り替え時に SiteNavBar の内容も一緒に切り替えられるのが理想なんだろうけど、
現状では最期に読み込んだタブの内容が引きずられるだけ。
(タブを切り替えても変わらない

で、漏れはセキュリティーホールより SiteNaviBar をとった(w

391 :1:02/05/19 14:49 ID:VZyx8Bz+
1です。ご無沙汰しておりました。

最初にお礼から。
僕がさぼって全然書かなかった間に、
スレッドを守ってくれていた人たち、
本当にありがとう。
早く戻ろう早く戻ろうと思ってはいたんだけど、
なかなかできなかった。
情けない1でごめんね。

http://pc.2ch.net/test/read.cgi/hp/1018719800/701-702

ありがとう、まだ本調子じゃないんだけど、復帰しようと気になれた。
ちょっと頑張るよ。

■rel="help" accesskey="?"について
>>376-383

Helpに対応するaccesskeyとして"?"を使うというのは、
意外といいアイデアだと僕は思った。
というのも、僕はMacintoshユーザー。
Helpが?だということに慣れている。
iCabのデフォルトアイコンも、Help=?だもんね。

けど、>>383 氏のいうところの
>1. 文字化けと紛らわしい(表示できない文字を疑問符に置き換えるアプリがあるから)
という意見は大きいなあ。

最近「おめでトン」というのがはやってるよね。
トンは、重さの単位トンの省略文字。もちろん、異種異存文字だ。
これが、Macintoshでみるとね、
「おめで?」になるんだ。これが最初なんだかよく分からなかった。

こういうのと、Helpページへのアンカー(?) というのが並存すると、
確かにややこしいかも知れない。もちろん、慣れの問題なんだけどね。

>伝統的なアクセスキーは英単語に含まれる一字が振られるものです。

うん、確かに今までのaccesskeyは単語中の一文字を使ったものが多かった。
けどここではそういう伝統や慣習というのを一端忘れて、
新たなアプローチも模索してみようよ。
もちろん過去の経験を蔑ろにしようといいたいわけじゃないよ。
それをふまえつつ、新たな可能性を見出したい。

■>Mozillaから Site Navigation Bar が消えた
>>384-390

なんと! 消えてしまったのですか……
じゃあ、現在デフォルトでlink要素によるナビゲーションを利用できるのは、
LynxとiCabだけですか?
Operaって、どうだったっけ? Site Navigation Barみたいのなかったっけ?

正直な話、これに関しては一歩後退という感が否めない。
accesskey自動割り当てが、正式実装される日は一体いつの日のことだろう……
問題の解決するのを、祈りながら待つしかないね。残念。

392 :1:02/05/19 15:05 ID:VZyx8Bz+
ちょっとスレ違いの話を。

accesskey関連サイトを作るとして、肝心のWebスペースはどうしよう。
僕の持っている使ってないスペースもあるけど、
これを使うと、正体がばれてみんなをがっかりさせる可能性が高い。
けれど、無料のWebスペースを利用するとしても、
広告の出てStrictにならないのを嫌がる人もいるよね(僕もそうだけど)。

もし広告が出たとしても、tabindexでそれをパスしてやれば、
サイトの利用に関する妨げにはなりにくいし、
サイトの趣旨のひとつであるtabindexの利点を示す機会にもなるんだけど。

どうしよう? なんかいい案ないですか?
このへんになると僕はからっきし駄目なので、
どなたか識者によるご助言を仰ぎたい。よろしく。

一応、無料スペーススレッドから、
広告なしの無料スペースをコピーしてきました。

結局どこの無料HPが一番なんですかね?-9-
http://pc.2ch.net/test/read.cgi/hp/1021776531/l50

【国内】CGI可 広告なし
http://www.nurs.or.jp/
http://free.webdos.net/     
http://www.freespace.jp/    
http://masakun.myhome.cx/~maki2323/masa/
http://www.gogp.co.jp/
http://www.nazosite.com/
http://www.koikoi-world.jp/
http://haruno.fam.cx/

【海外】CGI可 広告なし
http://www.portland.co.uk/
http://www.port5.com/
http://www.f2g.net/
http://www.united.net.kg/
http://www.l33t.ca/
http://www.marhost.com/
http://www.dk3.com/
http://www.digitalrice.com/

人に頼ってばかりと笑ってくだされ。

393 :330:02/05/19 15:30 ID:9k5N2xDv
>>392
ぶっちゃけ、無料でStrictって無理っぽいような。俺の知る限りでは。

落ちやすくても仕方ないから、せめて100円か200円くらいの、
ファイルを広告でいじられないサーバを探すのも手かと思った。


…でもこれだけの為に例え100円でも出すのはもったいないかもなー
だめぽ。

394 :Name_Not_Found:02/05/19 15:33 ID:9k5N2xDv
名前にクッキーが残ってて鬱

>>391
> じゃあ、現在デフォルトでlink要素によるナビゲーションを利用できるのは、
> LynxとiCabだけですか?
> Operaって、どうだったっけ? Site Navigation Barみたいのなかったっけ?

きちんと調べてないが、たぶんOperaにそんな機能はないです。
Win32(98SE) Opera6.01 1039



395 :1:02/05/19 15:36 ID:VZyx8Bz+
>>393
別に、月100円とか200円とかなら、払ってもいいですよん。
それなりのサービスを受けるには、やはりそれなりの対価を支払うのが普通だと、
僕は思っています。
ただこうやって有料のを借りたとき、
サイトを誰か別の人に委譲するときとかにややこしいかも知れないと、
そういうことを思ったのでした。

396 :1:02/05/19 15:40 ID:VZyx8Bz+
>>394
>たぶんOperaにそんな機能はないです。

それは残念です。じゃあ、僕の勘違いか。
ありがとう、確認してくれて。
link要素受難の日々は、まだしばらく続きそうだね。

>名前にクッキーが残ってて

実は、このスレッドの330を確認してしまいました。
まれにあることですし、気にせずいきましょう。
だが僕が間違えると、他スレの1を騙ることになる危険が……

397 :390:02/05/19 17:27 ID:RvhleNT1
>1 さんおかえりなちぃ
漏れは機種依存文字も全角英数もにちゃん以外ではとりあえず使わないな……
にちゃんですら使うべきではないのはわかってるんだけどね。

http://pc.2ch.net/test/read.cgi/software/1021176218/170
RC2 での SiteNaviBar 復活法らしいのですが、
前述の通り漏れは rc1 なので試してないっす。

クリエイター向けとか謳ってる u-hip は新規募集してないしねぇ……
誰か宅鯖(w

398 :Name_Not_Found:02/05/19 17:34 ID:9k5N2xDv
>>397
ん、そのスレも見てるっす。ただ残念なのは、おそらく
1.0.0には公式に復活しない>一般ユーザは使{わ|え}ない
ということで。

こうなればやはり鯖側なりクラ側で、link要素を解釈して
本文中に展開するスクリプトなり何なりしか対策のしようがないか。
UAの機能として組み込まれている方が遥かにイイ!のに…

>>397
> 漏れは機種依存文字も全角英数もにちゃん以外ではとりあえず使わないな……
> にちゃんですら使うべきではないのはわかってるんだけどね。
俺も胴衣していいかい?苦笑

399 :Name_Not_Found:02/05/19 17:49 ID:AkxoSt/z
面白いスレッドですね。

私のサイトでもアクセスキーを使っています。健常者のユーザビリティーより
障害者のアクセシビリティーの点から実験的に使っています。今は30点くら
いかもしれませんが、将来の糧になればOKです。

構造はこんな感じです。
1. すべてのページにメインメニューがあって、サイトの
 主カテゴリへのリンクが張ってある。
2. すべてのページにサブメニューがあって、カテゴリ内の
 各ページと主要なアンカーへのリンクが張ってある。
3. レイアウトは外部CSSで制御してある。CSSを切った場合、
 コンテンツは1, 2の後ろにくる。

この結果、読み上げブラウザを使うと、すべてのページでコンテンツを
読む前にメインメニュー、サブメニュー、そして広告 :-P を読まなければ
ならなりません。そこで、メインメニューの前に

4. メインメニューへのリンク
5. サブメニューへのリンク
6. コンテンツへのリンク

を置いて、それぞれにアクセスキーを割り当てました。割り当ては1, 2, 3。
この割り当てはアンカーで囲まれた透明なGIF画像のALTタグで説明して
あるので、読み上げブラウザでもわかります(と、願う)。

あとはメインメニューには各カテゴリー用のアクセスキーを当てています。
割り当ては title タグで説明してます。用語の英訳に対する頭文字を使って
いて、たとえば「掲示板(B)」ってな感じです。

今の課題は、この構造を初めて訪れた読み上げブラウザユーザーにも
わかるように説明することです。そもそも1日1ヒットないようなサイトです
からゆっくりやります。

アクセスキーについてはデファクト・スタンダードすらないので不用意な
使用は控えたほうがいいという意見があるのは知っています。が、どう
せ待っていてもお上が何かするわけじゃなし、混乱もネットの上では
ムーブメントの種なので、各人がアイデアを自分のページで使ってい
れば、そのうちいい方向に向かうと思ってます。

400 :399:02/05/19 17:59 ID:AkxoSt/z
>>395

ホスティングサービスについてひとつだけコメントです。

SSI機能のあるサーバーを選んでおいたほうがいいかもしれません。無理に使う必要はない
かもしれませんが、「全ページのメニュー変更」が一発で出来るのは重宝します。私は50
ページくらいコンテンツを作った時点でアクセスキーを導入しましたが、インクルードされる
メニューを変更しただけで全ページがアクセスキー対応になりました。



401 :Name_Not_Found:02/05/19 18:41 ID:VFnsnXdn
ありが㌧なら win でも mac でもその他でも見られると思うけど。
&#13095; ね。


402 :401:02/05/19 18:43 ID:VFnsnXdn
あー。えっと、>>401

>> 漏れは機種依存文字も全角英数もにちゃん以外ではとりあえず使わないな……
>> にちゃんですら使うべきではないのはわかってるんだけどね。
> 俺も胴衣していいかい?苦笑

に対してね。文字参照にすればまあ一応問題ないだろうってことで。
話が逸れちゃったけど。

403 :390:02/05/19 18:48 ID:RvhleNT1
>>401
ん、まぁ、㌧ が機種依存とされるのは SJIS の時だけやしね。
ところで、こーいうのってうにこーどおーぐのチャートいちいち見るの?

何か脱線に罪悪感が…(`Д`)

404 :Name_Not_Found:02/05/19 18:53 ID:cYLcEIWu
>>394
>きちんと調べてないが、たぶんOperaにそんな機能はないです。

Mac 版にはある (日本語表示できないけど)。古くは Mosaic とか。

405 :Name_Not_Found:02/05/19 20:03 ID:9k5N2xDv
>>404
有り難うございます。当方マクはまったく知らないので
いい加減なこと言ってしまいました。
# ただ、http://www.opera.com/docs/specs/
# > Opera has no particular support for link apart from rel="stylesheet",
# とあるんですが、どこかソースはありませんかね?

>>399
キタ━━━━━━(゚∀゚)━━━━━━ !!!

利用者の反応はどうでしょう?もしあれば聞かせていただきたい。
# ん、しかし1hotか・・・

406 :Name_Not_Found:02/05/19 20:08 ID:ecUlGlkT
読み上げといえばホムーペジリーダーだけど、
それってアクセスキー使えないんじゃなかったっけ?
数字は使えたとか?

407 :Name_Not_Found:02/05/19 20:29 ID:9k5N2xDv
>>406
>>252>>1氏が。

408 :Name_Not_Found:02/05/19 20:42 ID:ecUlGlkT
>>407
ども。
まるっきり使えないってことだよね?
>>399氏がアクセスキーを(視覚)障害者向けに、と言ってるから
その辺大丈夫なのだろうかと思って。

409 :Name_Not_Found:02/05/19 20:52 ID:9k5N2xDv
# >>408
# ひょっとして俺は>>399に釣られたのか?

>>401-402
アップ直前に一発変換。

410 :Name_Not_Found:02/05/19 21:17 ID:VFnsnXdn
>>403
↓これ使うとか
ttp://east.portland.ne.jp/%7Esigekazu/css/ascii.htm#textHTML

411 :399:02/05/19 22:18 ID:RnN5T8tg
>>409
あんまり丁寧だと浮くから口調変えるね。

釣ったわけじゃないけど説明不足だった。結果的に釣ったみたいでごめん。

ホームページリーダーはアクセスキーが使えないらしいってのは、俺も何かで
読んで知っていた。だから、アクセスキーは一種のおまけ。基本的には読み上げ
とエンターだけでナビゲートできるようにしてる。

で、将来ホームページリーダーがアクセスキーを使えるようになったらいいのにな、
と思ったわけよ。だってそうすればうざい広告をスキップできるし。そうなったとき、
視覚障害のある人でもページ内、ページ間を自由にナビゲートできるようにするには
どうすればいいのか、ちょっと実験的に組み込んでみたってのが実情。

ちなみにメインメニューへのジャンプは、ページトップへのジャンプなので自分自身も
便利に使っている。

412 :390:02/05/19 22:39 ID:RvhleNT1
>>410
トップページの HTML 4.01 文字実体参照 しか知らなかった……
さんくす。

413 :1:02/05/20 01:10 ID:wm99tOIo
こんばんは、1です。

>>399
実際の事例についてのいろいろ、ありがとう。勉強になります。

経験によるものを除き、基本的な同意が得られていない現状では、
accesskeyは確かに使いにくいものではあります。
でも、だからといって二の足を踏むのではなく、
いろいろな例、いろいろな方法を模索しながら試していき、
その結果をひとつの成果にまとめることができれば、
きっとよいものになると思う。
なので、このようなよい知恵、発想を紹介してくれることは、
このスレッドの1として、大きな喜びですよ。

すぐに結果が出るものではないでしょうが、
長い目でゆっくり方向を見極めていきましょう。

■Mozillaのこと
>>397-398
一応、Site Navigation Barの復活は可能ですか。
でもそういう作業を経ないと使えないというのは、残念ですね。
使えるようになったとしても、
気付いていない人にとってはないのと一緒という事実はあるけど、
それでも気付くことはあるんだから。

link要素に関しては、UAが活用してくれるのがもちろん一番いいんだけど、
そうでないなら提供側から工夫する意外にないでしょうね。
JavaScriptかSSIかPHPか、
とにかくこれらについて僕は詳しくないので、
できれば避けて通りたかったな。

でも、やるとなったら勉強しますよ。自分の力にもなります。

■SSIについて
>>400

SSIに関しては提供されていても、
拡張子がshtmlのものにのみ使用可ということが多いようですね。
でもこれを使って自動でナビゲーションメニューを作成できるようになれば、
メンテナンスの面で非常に便利なのは確か。
視野に入れておきたい機能ですね。

414 :1:02/05/20 01:10 ID:wm99tOIo
■機種異存文字と文字参照
>>397-398 >>401-403 >>409-410
確かに文字参照を使えば、㌧も大丈夫。iCabでも表示されてます。
ちょっと新鮮な感動を味わってるところだよ。

でもこれはこれで有効なんだけど、
UAによってはやっぱり?なんですよね。
僕はシングルクォーテーションを
「'」じゃなくて「’ (&#146;)」にする時があるんだけど、
環境によってはこれが?になる。
Lynxとかw3mが確かそうだったと思うんだけど、
結構これが気になることもあって、これらの使用に関してはしばしば迷う。

㌧もよしんば表示されたとして、
読み上げ環境においてどうかということを視野に入れると、
やっぱり「トン」と書いたほうがいいんだろうね。

いろいろな環境に配慮するということは自由度が減るということではあるけど、
その自由度が減ることで情報提供のすそ野が広がるのなら、
きっとその方がいいんだと僕は信じることにしているよ。

■OperaのSite Navigation Bar
>>394
>Mac 版にはある (日本語表示できないけど)。古くは Mosaic とか。

情報ありがとう。そうか、Mac版にはあったんだね。
以前Operaを使用したときに、Mac版もさわって、
それでその印象が残ってたんだと思う。
でも、なんでMac版だけなんだろう? なんか不思議だ。

■音声ブラウザとaccesskey
>>406-409 >>411

ホームページリーダーは、通常の閲覧に際しての操作のために
ほぼすべてのキーバインドを使ってしまっている。
だから、accesskeyに割り当てる余裕がないんですよ。
テンキーはといえば、ほら、マウスがわりになってるから。
だから、残念ながらHPRではaccesskeyは断念せざるを得ない。
もっと根本的なやり方で、対処していかないといけない。

でも、HPR以外にも音声ブラウザはあるんだから、
こういった試みが、音声ブラウザにとって無意味とは思えない。
HPRがたまたまサポートしなかっただけで、
他のでは使えて、実際役立ててる人もいるかも知れないしね。

機会があれば、HPR以外の音声ブラウザも試してみたい。
なかなかそういう機会を持てないのが歯がゆいよ。

415 :Name_Not_Found:02/05/20 16:05 ID:YGZWEbwD
>>383
さらに上回る遅いレスで、ごめんなさい。
> 1. 文字化けと紛らわしい(表示できない文字を疑問符に置き換えるアプリがあるから)
最初、「そこまで考える必要あるのか?」と思ったのですが、
>>391を見ると結構切実な問題なのですね。

>>414
Lynx(ver2.8.2 win32)の場合、不明な文字参照があると、
そのまま &#xxxx; のように表示します。
確かMozillaで、表示しようとする文字がフォントになかったときに"?"としていたような…

それと、Lynxではaccesskeyもtabindexも実装していないんですよね。
つらいなあ…

416 :Name_Not_Found:02/05/20 17:03 ID:H5fQFEom
ContextMenu-Extensionsの作者は見てるんだっけ
Mozillaでディスクキャッシュオフにしていると(memory cacheだけ)
デフォルトで全部のサイトをコメントアウト表示するとかのオプションが
ページを戻るの時にしか、適応できないでいました。

でも、これは仕様かな?

417 : ◆S0qIRC9I :02/05/20 23:13 ID:DlippjtB
>>416
ページを読み込んだときに自動でコメント可視化を実行するやつのことでしょうか?
調査しておきます。


418 :Name_Not_Found:02/05/21 13:58 ID:FbYZbo/f
http://pc.2ch.net/test/read.cgi/hp/1018719800/746
期待sage。両方見ている人ばかりなのは覚悟の上で。

419 :Name_Not_Found:02/05/21 15:34 ID:yAyM4NWr
harunoさんのところ、いけるんじゃなかろうか。ここの1さんなら。

420 :Name_Not_Found:02/05/21 19:14 ID:hhbXtrwe
harunoさんってなによ

421 :1:02/05/21 21:48 ID:xw9q0tIh
こんばんは、1です。

>>415
文字参照に出会ったとき、それを適切に扱えない環境、
それをどれだけ配慮するかは時と場合によると思うんだ。
例えば、アスキーアートなんかだったら、
文字参照(機種異存文字といいかえてもいい)を使うことは、
別におかしいことではないと思う。

例えば、
http://pc.2ch.net/test/read.cgi/hp/1018964826/508
が持ってる丸付き数字は、(10)と書き換えれば、
その伝えようとするところが伝わらなくなってしまう。

僕は、自分の伝えたいこととその対象が明確であるなら、
多少の逸脱(altのないimgなど)も許容されてよいと思う甘い人間なんだ。
大切なのは、自分の伝えようとすることが、
伝えたい相手にきちんと届くかというそれだけだとも思っている。

ただ僕らはその考えを、
不特定多数の様々な環境下にある人が訪れうるWWWに適用したい。
できるだけ多くの人に自分の中にあるなにかを伝えたいと思った時、
もっとも多くの環境で扱えるようなやり方を模索してるのが、
多分このスレッドだと思ってる。

だから、僕は
rel="help" accesskey="?"
については、本当によいアイデアだと思ったんだよ。
直感的だし、なにより記号がその意味を如実に表してる。
ただそれにややこしさを感じる人がいるなら、
慎重になったほうがいいかも。
僕の立場は、こういう曖昧なものです。

>Lynx(ver2.8.2 win32)の場合、不明な文字参照があると、
>そのまま &#xxxx; のように表示します。

Mac OS Xの日本語ターミナル上でw3mを動かした場合、
扱えない文字参照があると、?にされてしまいます。微妙です。
でも、w3mを使う人なら、
きちんとその?の示す意味を理解してくれると思うから、
正直僕はそれほど気を使っていない。
甘いね、甘甘だ。

ところで僕は、Lynxやw3mにaccesskeyは似合わないような気がする。
これって偏見かな?
現状においてaccesskeyやtabindexは、
視覚的UAを使うキーボード派のためのものなんだろうか?
これは、僕のなかによどんでいる、疑問みたいなものになってしまっています。

422 :1:02/05/21 21:48 ID:xw9q0tIh
>>418-420
Strictスレのその発言は、僕も密かに期待していた。
それで、accesskeyスレの1です、と出ていこうかとも思ったんだけど、
やっぱりそういうのっていかんと思って、
運用がスタートするのを待ちたいと思ってたところなんだ。
やっぱり、みんな思うところは一緒だね。

harunoさんは、googleで調べて分かりました。
ちょっときびしい人なのですか?
僕は、ものすごくのろのろとしか動かないやつなので、
ちょっと不安かも……
でも、一度チャレンジしてみようかとも思い始めてる。

Strictスレの746氏の試みも視野に入れながら、
harunoさんのサーバも考えてみようと思います。

情報、ありがとう!

423 :Name_Not_Found:02/05/22 00:03 ID:CEWbzrnk
>>422
むしろStrictスレの746氏がHARUNO氏だと思うと言ってみるテスト

424 :Name_Not_Found:02/05/23 04:44 ID:IKDr//Je
>>417
まだ治ってないな、現象はまだ以前と同じで
戻る(キャッシュされる)をおすとコメントアウトが表示されます

それとは関係なくてコメントアウトが表示するを押すと
正常に表示はされますけど、全部に機能させようとするとそうはいかない

425 :Name_Not_Found:02/05/23 11:54 ID:OZGLqEAl
Netscape7をいま入れたけど、<link rel=>がタブ表示されないよう。

426 :Name_Not_Found:02/05/23 11:57 ID:5uLibAL6
>>425
Mozilla1.0RC2 から諸事情で外されてるんだよ。

427 :425:02/05/23 12:01 ID:OZGLqEAl
>>426
あらら、さりとは知らず。
それぢゃ新しくした意味が無いなあ。
ともあれ、ご教示かたじけない。

428 :Name_Not_Found:02/05/23 18:08 ID:e49pnDzF
Donutとかのコンポーネントブラウザじゃ対応できないのかなぁ?
できたら、ム板の人や、作者タンにお願いすれば・・・・(w

429 :Name_Not_Found:02/05/23 21:03 ID:PQNAiYy8
>>425
ソフトウェア板の Netscape6.x スレッドからコピペ

それと、サイトナビゲーションバー復活に成功した。
・N7PR1 を Quick Launch も終了
・<N7PR1 のインストール先>\chrome\comm.jar をzip で解凍
・出来た content フォルダの content\navigator\linkToolbarOverlay.xul を mozilla 1.0RC2 の同じフォルダにある linkToolbarOverlay.xul で上書き
・content フォルダを zip で comm.jar という名前で圧縮
・<N7PR1 のインストール先>\chrome\overlayinfo\navigator\overlay.rdf に以下のように行を追加
...
<RDF:Seq about="chrome://navigator/content/navigator.xul">
<RDF:li>chrome://navigator/content/linkToolbarOverlay.xul</RDF:li> <- この行追加
<RDF:li>chrome://wallet/content/walletNavigatorOverlay.xul</RDF:li>
<RDF:li>chrome://aim/content/AimNavigatorOverlay.xul</RDF:li>
<RDF:li>chrome://messenger-ns/content/mailNavigatorOverlay.xul</RDF:li>
</RDF:Seq>
...

これでN7PR1再起動すればサイトナビゲーションバー復活!

430 :330:02/05/24 01:20 ID:d2XXXBBz
ググールが動いた
http://pcweb.mycom.co.jp/news/2002/05/22/16.html

431 :Name_Not_Found:02/05/24 01:32 ID:o3h+wNYo
google(・∀・)カコイイ!!

>>430のIDもっと(・∀・)カコイイ!!

432 :Name_Not_Found:02/05/24 08:36 ID:G/h2R3de
CookieとかJavaScript必須って何?

433 :Name_Not_Found:02/05/24 11:27 ID:S6q8CdCz
JavaScriptでアクセスキーを実現しているんですね。
(Cookieはオプション。あってもなくてもいい。)

キーバインドはこのようになってます。
http://labs.google.com/keys/index.html

434 :Name_Not_Found:02/05/24 14:44 ID:PPob1GPB
これって使ってる人居るんですか?
いくらパソコンに慣れてくるとショートカットキー主体になってくるとはいえ
リンクを押したりするのわざわざアクセスキーはこれだなって確認してから押さないと思います。
せいぜいtabキーですよね。
マウスあるのに使ってる人とか居るんですかね。

435 :Name_Not_Found:02/05/24 14:46 ID:Pn2c0xt8
>>434
とりあえずスレ全部読め

436 :Name_Not_Found:02/05/24 14:47 ID:mDeYbJGm
>>434
このスレ頭から全部読んでみてくれ。

437 :Name_Not_Found:02/05/24 15:57 ID:PPob1GPB
とりあえず読んできたよ。

438 :Name_Not_Found:02/05/24 16:03 ID:Pn2c0xt8
>>437
読んだらわかっただろ。

>これって使ってる人居るんですか?
いるんだよ。

439 :438:02/05/24 16:05 ID:Pn2c0xt8
とりあえず、そこまでわかった上でなんか質問があるならなんでもどうぞ。

440 :Name_Not_Found:02/05/24 16:45 ID:W9MdVh/j
こんなの付ける以前にフォームにアクセスキー付けて欲しい……
Tab だと始めの方にバナーがあって大変なんだよ……
すぐ後に文字入力するから、いちいちマウスも面倒だし……
と、まぁ、こんな需要もあったり。

とりあえずはユーザサイドで弄るか…、肝心のキーは何にしようか……

441 :Name_Not_Found:02/05/24 16:50 ID:Pn2c0xt8
>>440
そんなときのためのtabindexです。

アクセスキーはフォームにid振るとか。

442 :Name_Not_Found:02/05/24 17:07 ID:9CBQS4/1
わざわざJavaScript使わんでも、普通にaccesskey付けてくれりゃいいのに。

……ブラウザやOSのキーバインドと重なるから?
普通に考えれば、それ相応のキーバインド空間を設けるべきだと思うんだが。

443 :442:02/05/24 17:20 ID:9CBQS4/1
でもこれってよく考えたら
今のブラウザのフォーカスやアクションに関する実装が
ヘタレ過ぎだって証明でもあるな……

例えばフォーカスでボールが横っちょに出るの、
CSSなら本来div:focusとかで制御出来るのに、
現時点ではやっぱりJavaScriptを使わないとしょうがない。

444 :Name_Not_Found:02/05/24 18:46 ID:6py4XO3f
>>438
>>これって使ってる人居るんですか?
>いるんだよ。

ここまで論議するほど需要あるんですか?
少なくともネット初心者に対しての配慮でないのは確か。
中級者以上向けの配慮。
しかもその中でもaccesskey、tabindexにある程度知識のある人限定機能のようですが。
こんなの制作者の自己満足ですよ。

445 :Name_Not_Found:02/05/24 19:06 ID:1hglMY45
>>444
ほんとにそうかな?
なんていってみつつ、444に「キリ番getおめ」とかいってみたほうがいいのか考えるテスト。

446 :Name_Not_Found:02/05/24 19:16 ID:kVDPCVvW
別にこれがIEとかのUAだったらAccessKey(JAVAScript版も)なんて要らないけど
PocketPCとかPalmとかはどうなんですか?そういうモバイル系を持ってないので操作が
分らないんですけど…こういうのはあった方が便利なんでしょうか?>モバイラーさん
対象によってユーザビリティってのを変える必要があるように思えると言ってみる心理。

447 :1:02/05/24 20:08 ID:poha/0X9
はい、こんばんは、1です。
最近、ずいぶんと動きが大きくなってきたね。

■Netscape7関連
>>425-427 >>429
Netscape7(7というには驚いたけど)でlink要素未対応問題は、
本家Mozillaと同様に、ユーザサイドで復活させるという形で、
やり過ごすしかなさそうだね。
一歩後退感はあるけれど、同じやるんだったら、
これで決定版みたいなくらいにまで完成度を高めてからの方が、
むしろいいのかも知れない。と僕は思うことにしたよ。

■コンポーネントブラウザでの対応
>>428
コンポーネントブラウザでも、
やりようによってはlink要素に対応可能だと思うよ。
といっても僕は詳しくはないんだけど、
「ス切りボ」の拡張でIEがlink要素を利用できるようになるんだから、
多分、大丈夫だと思うんだ。
誰か、こういうのを作ってみようってかたが現れると嬉しいけど。
こういうときに、自分の無技術を嘆くのだよ。

■Googleとそのキーボード操作
>>430-433 >>440-443
うん、驚いた。結構軽快に動くんだわ、Windowsでは。
でも、MacIEじゃ、ちょっと使用感に不満が出ます。
加えて、
「Internet Explorer 5以上、Netscape 6以上のブラウザで利用でき」
というだけあって、iCabじゃ利用できなかった。
多くリリースされている各種UAに対応させるのは難しいんだろうけど、
できればUAを問わず利用できるようになればと、
無理な注文をしたくなったよ。

引用は、
http://pcweb.mycom.co.jp/news/2002/05/22/16.html

使いやすさという点では、数字でリンク先を選ぶ際に、
問答無用でジャンプしちゃうのはちょっといやだ。
画面外のものにヒットして、行き先がなんだかわらないうちに飛ばされる。
accesskeyに関しては、
既知のページに関しては問答無用ジャンプ型
未知のページをブラウズしたい場合は、フォーカスのみ型
の方が便利じゃないかと感じた。
ユーザが設定でその両者を選べるようになればいいのにね。

Googleでのキーボード操作は、JavaScriptによるものと、
accesskey&tabindexによるものを、
併用してくれるといいのにと思うよ。
これだと、IE5, N6以外でも利用できる可能性が出る。
IEであっても、問答無用ジャンプとフォーカスのみを選択できる。

Feedbackしてみようか? Discussでもいいけど。

>>376
Helpの割り当て、"?"ですよ!

448 :1:02/05/24 20:09 ID:poha/0X9
■環境ごとの配慮、モバイル編
>>446
>PocketPCとかPalmとかはどうなんですか?

PocketPCとかなら、一般的なPCと同様と考えてよいのでは?
むしろキーボードを持たずスタイラスペンでの操作を前提とするものは、
accesskey、tabindexはいらないんじゃないのかな?
今度Palmユーザの友人に聞いてみるよ。

対象に応じて配慮するというのは、常に関わってくる問題だね。
今まではPC、モバイルフォンくらいしか出てこなかったけど、
他にはどんな環境があるだろう?
なんかあるかな? 誰かなんか思いつかない?

449 :1:02/05/24 20:10 ID:poha/0X9
■accesskeyの意義
>>434-439 >>444-445
このスレッドにおいても、accesskey、tabindexの利用に関しては、
大いに疑問視されてきたんだよ。
自己満足、lint対策にすぎないなど、いろいろいわれてきてる。
でもaccesskey、tabindexがうまく割り当てられているサイトの閲覧は、
やはり快適で、便利なんだ。
じゃあ、なにがこれらの浸透を阻んでいるのかと考えたとき、
サイトごとにキー割り当てがまちまちで、
経験や学習にたよることのできない現状が原因しているんだろうと気付いたんだ。

この気付きが、すべての最初だった。
accesskeyの割り当てが、多くのサイトで共通するものとなったなら、
>リンクを押したりするのわざわざアクセスキーはこれだなって確認してから押さないと思います。
ということはなくなる。
キー割り当てのやり方が共有されると、利便性が一気に高まるということから、
サイトオーナーではなくUAがaccesskey的インターフェイスを備えることが望まれ、
このスレッドの参加者の総意として、各デベロッパに送付された。

そのメールに対する動きは全くないように見えるけど、
それならそれで、自分たちにできることをやっておきたい。
下手をすると「自己満足」に止まりかねないこれらを、
自己満足ではない、本当の便利なものとして活用できる状況を求めたい。
僕らのやってることっていったら、これくらいのもんだよ。

>少なくともネット初心者に対しての配慮でないのは確か。

たとえ初心者にとっては存在しないような機能だとしても、

>中級者以上向けの配慮。

彼らが中級者になったとき、便利と思うかも知れない。
それに、僕らはもうこの便利を知っちゃったんだ。
WWWをもっと便利に、快適に閲覧したい。
そのもうちょっとを考えているうちに自然と議論の輪が広がっただけで、
多分誰もこんなにまで話し合うことになるとは思わなかったんだと思うよ。
だって、言い出しっぺの僕からして思ってなかったんだもの。

逆に、ここまで議論が広がったというところに、
accesskey、tabindexに関する多くの思い、わだかまりがあったんだと思う。
でなきゃ、誰もこんなには考えなかったし、話さなかった。

というわけで、GoogleのKeyboard ShortcutsのDiscussのURIを紹介。
少なくともこんだけくらいの喜びの声があるんだから、
accesskeyに凝るのも決して無駄じゃないんだと思えたよ。

http://groups.google.com/groups?group=google.public.labs.keyboard-shortcuts

450 :1:02/05/24 20:19 ID:poha/0X9
>>449
>喜びの声
というのは、嘘大げさ紛らわしいだった。
せめて「反響」に言い換えたい。

これだけではなんだし、近況をちょっと。

サイト作成の方は、現在動きなしです。
以前作成した目次案 >>333-334 >>346-347 を保持したまま、
過去発言を一覧しやすいような索引を作成したい。
そういったツールが発言が出るたびに過去に押しやられるじゃなんだから、
Webスペースを押さえておきたいと思った。
これが先だってからの流れです。

序文に関しては、目次案及び索引ができたころに、
ぼちぼち書き始めようと思ってる。
もし、我こそはと思う人がいたら、どしどし書いてね。
よろしく!

451 :444:02/05/24 21:01 ID:6py4XO3f
1の情熱は大いに伝わったよ。
なんでも新しいことに挑戦するのには弊害が山ほどある。
今回の俺のようなわからずやも多いと思うけど頑張ってくれよ。
accesskeyの開拓者としてプロジェクトXに出てくれる日を待ち望んでるよ。

452 :1:02/05/24 21:37 ID:poha/0X9
応援、サンキュ。ありがと!
頑張ってみるよ。できたら、参加してくれると嬉しいよ。
話し合いには反対意見や苦言が、やっぱり必要なんだ。
あらためて根本を思いだすことができた、有意義だったよ。

453 :435:02/05/25 11:36 ID:alku/lDW
>>444
とりあえず君を初心者スレから誘導したのは俺だけど、
これからもたまにこのスレ覗いてくれや。

まあ、「どうしてこんなもん(accesskey)いるんだ?」って人間も
常にこのスレの議論に加わっていた方が独善的にならなくて
いいだろうと思ってな。

まあ、慣れるとまた新たな血が必要になるのだが(笑

454 :Name_Not_Found:02/05/25 12:07 ID:1qANbZdj
あってもよいではないか

455 :Name_Not_Found:02/05/25 13:29 ID:LXDWHmWv
googleツールバーによる拡張機能に
アクセスキー(Link relなど)をつけてください!
ってメールしてみようかなぁ、と思っているんだ。

技術的に不可能なのかも知れないんだけど。
#その辺よくわからないんだ。

456 :Name_Not_Found:02/05/25 14:45 ID:QmMLk1dP
>>455
悪いけど、何が言いたいの? googleツールバーってIE用だろ。
accesskeyによるキーバインドはもう既にIEで実装されてるよな。
linkやaのrelに勝手に何らかのキーバインドを付けろって事?

正直、linkやらaやらに指定されるrel使用の
コンセンサスが容易には得られないのに
(正直、Nextが二つあったらどうすんねんとか突っ込みどころが多過ぎ)
下手に「使い勝手」なんて考えるよりも
普通にアクセス出来るインターフェイスを実装するべきだと思うんだが。

例えば、リンクを抜き出すときにrel="bookmark"だけを抜き出すとか。
今W3Cが仕様書で文中に[XML]とか埋め込んでやっている
参考文献にrel="related"とかつけて、参考文献リストを抜き出すとか。

……リンクタイプだけでスレ立てるべきか?

457 :Name_Not_Found:02/05/25 17:48 ID:8nVHhFcB
>>456
> accesskeyによるキーバインドはもう既にIEで実装されてるよな。
うん。
> linkやaのrelに勝手に何らかのキーバインドを付けろって事?
>>455の言いたいのは多分そういうことだと思う。

> ……リンクタイプだけでスレ立てるべきか?
いまのところはここで話せばよいと思う。
まだ500はかけるしね。

458 :Name_Not_Found:02/05/27 15:39 ID:R45q9Ekc
>456
>457
>455はsite vavigation barみたいのをつけて欲しいと言っているんではないかと推測するが。


459 :Name_Not_Found:02/05/27 19:57 ID:oo4rg843
>>455まぁ、お前の言いたいことは
(1) linkやaのrelに勝手に何らかのキーバインドを付けろ
(2) site vavigation barみたいのをつけて欲しい
どっちよ?いや両方か?

まぁ別にわからなくてもどちらも実装してもらえれば最善だけど、


460 :Name_Not_Found:02/05/27 19:58 ID:oo4rg843
843getしてきたいな、このIDで(ワラ

461 :Name_Not_Found:02/05/28 22:22 ID:MoQ6Ee94
どっちにしてもGoogleツールバーの仕事じゃないし。

462 :Name_Not_Found:02/05/29 16:33 ID:hS2bK5D6
>>336-337
> JSkyはdirectkey
という話ですが、auもJ-PhoneもWAP 2.0に対応した携帯を出してますね。
DoCoMoもFomaをWAP 2.0に対応させるみたいなので、
すべて、accesskeyが使えるようになるといいですね。

# WAP 2.0では XHTML Mobile Profile というXHTML Basicの亜種を定義してます。
# XHTMLMP 1.0 DTD
# http://www.wapforum.org/what/technical.htm
#
# accesskey属性を持つ要素
# a, label, input, textarea

463 :Name_Not_Found:02/05/29 18:59 ID:cb4XJ52B
XHTML Mobile Profileに限らず、
なんでselect要素にはaccesskey属性はないんでしょう?
label使えばいいから? いずれにせよ、
フォームの部品でaccesskeyがないのはこれだけです
(isindexは除きますよ)。かわいそう。

464 :Name_Not_Found:02/05/29 19:29 ID:fHzJn05l
accesskeyの挙動の問題にも原因がありそうだが。
フォーカスをあてるだけならなんとかなるけど
いきなり発動しちゃうのではselectで何をすればいいのやら分からない。

465 :463:02/05/29 22:20 ID:nqRalSZL
そうですね。464さんの言う通りかも。
加えて、考えてみればselect要素で選べる項目は1つとは限らないから
現在の挙動だと全てをカバーしきれない気はしますね。
ありがとうございます。

466 :Name_Not_Found:02/05/29 22:22 ID:pYXSyysR
相変わらず君たちは無駄な時間を使ってるんですね。
考えるより先に「ホームページ忍者」。
これさえあれば全て自動処理だよ。

467 :1:02/05/30 00:01 ID:NoUOQhJ6
1です。無駄な時間を過ごしにきました。
このスレッドに参加される皆さんにお願いがあります。
できれば、メール欄にsageを入れていただきたいのです。

sageで書きましても、書き込みがあるかぎりdat送りにはなりません。
このスレッドに関わる事柄に興味を持っている人は、
深く沈んでいても、見つけてくれるものと期待しましょう。

本当は、こんなことは書きたくなかったんだが……

■select要素に関して
>>463-465

select要素にaccesskey属性があってもいいような気はするんだよね。
ポップアップメニューでも、キーボード操作できるアプリケーションは、
沢山ありますから。

この場合、前提として、問答無用型の挙動は駄目ということになるよね。
フォーカスをあてて、カーソルキー等で値を変更、Enterで確定が理想的。
複数項目選択の場合でも、このやり方なら、ある程度カバーできるかも。
accesskeyがなくても、tabで移動してフォーカスできるので、
実際この挙動の実現に関しては、不可能じゃないと思うんだ。

となると、accesskey属性がないのは、なんか別の理由もあるのかも。

余談だけれども、Java Scriptを使ったselect要素でのサイトナビゲーションには、
少々問題もある。
大抵は、select要素の値が確定した瞬間に、scriptが発動する。
つまり、カーソルキーでひとつ値をずらしただけで、発動するんだ。

これって結構厄介です。

468 :1:02/05/30 00:01 ID:NoUOQhJ6
■link要素及びlink type
>>456-457

link要素に関しては、過去にこのスレッドで話されていた経緯もあるので、
このスレッドで扱っても構わないと思いますよ。
とくに、異質なものにはならないでしょう。

もし必要なら、次スレを立てる際に名称を、
accesskeyってどうしてる? tabindexは? そしてlinkも
にするのもよいかも知れない。

>>455
この提案ってのは、googleツールバーに、
ス切りボみたいな機能を追加して欲しいということ、だよね。
link要素を解釈して、link typeに応じたキーボードナビゲーションを
提供して欲しいということだと、最近になって気付いた。

ごめん。もっと早く気付いて、返事してあげられたらよかった。
もし誤解してたら、重ね重ねごめんね。

でも現実的な話として、link typeに対するコンセンサスも、
accesskeyよりずっとましだとはいえ、
多少混乱しているのも事実なんだよね。
>>457 氏のいうところの、
>Nextが二つ
といったケース、また複数のlink typeを汲みあわせる場合など、
問題は沢山沢山あると思う。

数少ないlink要素をもとにナビゲーションを提供するUAの挙動に、
サイトオーナーがあわせているのが現状。
仕様に忠実であろうとすれば、破綻しかねないのは歯がゆいよね。

■携帯におけるdirectkey、accesskey
>>462
>すべて、accesskeyが使えるようになるといいですね。

うん、こういう状況が進むと、本当にうれしいよ。
かつてPCブラウザで見られた、独自拡張合戦は、
ひとつの情報をあらゆる環境で見るという点から見ても、不毛だった。
モバイルフォンにおいても、過去の愚が繰り返されるのは、
サイトオーナーも大変なら、ユーザもまた困ることだよ。

それが、こうして同じ文書を利用できるようになっていくのは、
本当に有意義なことだと思う。
モバイルフォンの変遷は、PCブラウザに対しより急進的と思うから、
数年のうちには、大半のモバイルフォンがaccesskeyに対応するようになるかも。
そうなるといいね。期待してみましょう。

469 :Name_Not_Found:02/05/31 02:28 ID:RlS9IA5k
NetFront というブラウザがありますが、
対応状況はどうなっているんでしょうか。
http://www.access.co.jp/remarkable/nf.html

470 :1:02/05/31 15:09 ID:0tIH1DlL
>>469

サイト内検索で、「accesskey」をキーにして検索してみたら、
三件ほど出てきたよ。
それによると、少なくともCompact NetFrontは、
accesskeyに対応してるみたい。

一応、その典拠は示しておくね。
>数字キーでアンカーを直接指定できる「ダイレクトキーアサイン機能」"accesskey"(HTML4.0 )
http://www.access.co.jp/products/conf_1.html

これをみる限り、NetFrontもaccesskeyに対応してると思っていいんじゃないかな?
link要素に関してはどうか、ちょっと分からないんだけど。

471 :Name_Not_Found:02/06/07 21:37 ID:yKLfil2n
age

472 :Name_Not_Found:02/06/11 00:14 ID:QQh9b8q0
>>469

その会社の「compact NetFront」はi-mode対応機種に対応している。
参考ソースとして、次のページを挙げておくよ。
「ACCESS,携帯向けブラウザ 「NetFront v3.0」でWAP2.0サポ ート」
http://www.zdnet.co.jp/mobile/news/0109/13/access.html

473 :Name_Not_Found:02/06/18 15:14 ID:gFBhuOqW
サイトはどーなったんでしょーか?

474 :1:02/06/18 22:35 ID:ggVr0MuT
>>473
ユーザビリティスレ、読みました。
頑張らねばならんと思いながらも、頑張れない昨今。
もう少し、もう少し待ってください。

475 :Name_Not_Found:02/06/19 03:07 ID:oaBMrsLJ
>>474
焦らなくてもいいって。
貴方がこのスレに書き込んだ分だけでも結構な量なんだし、
それを踏まえてまとまったカタチにするのは、チャチャッとは出来ないでしょ。
マターリと(・∀・)ガムバレ!

# と、今日初めてこのスレに来たので(遅)、何か書いてみる。
# いいスレだね。サイト出来たら、議論に参加させてもらうかも。


476 :Name_Not_Found:02/06/28 22:19 ID:???
保守sage

477 :1:02/06/29 19:04 ID:???
そろそろ、快復してきています。
近々、再開できたらいいと思っています。

まずは序文案を出し、サイト作成の前段階として、
サイトのアカウント(ディレクトリ名)を決めたい。
~accesskey/ とかだったら、話題がかぎられると思うし、
だったらどんなのがふさわしい(わかりやすい)かという、
そんな感じの話です。

478 :Name_Not_Found:02/06/30 02:49 ID:???
アクセシビリティあたりは?

479 :1:02/06/30 13:06 ID:???
>>478
可能な部分は関わりたいと思うけれども、全般はちょっと無理そう。
それに、アクセシビリティ概論的なサイトは沢山あるから、
個別のことがらを扱うサイトにしたほうが、有用であると思う。

という点から、どんなアカウントがよいかな?
サイト名でもいいですよ。

480 :463:02/06/30 14:01 ID:???
案)「Webサイトの歩き方〜キーボード編〜」

accesskeyやtabindexってキーボード使用(モバイル含む)が前提にあるので。
でも、ちょっとパクリっぽいかな?

481 :1:02/06/30 22:34 ID:???
>>480
序文案として、キーボード派のためのaccesskeyというアプローチを
提示しようとしていたから、その案は悪くないと思う。
ただ、そのサイトというのがaccesskey、tabindexを
中心とするもので済むならいいんだけど、
もしかしたら、スレッドの流れからしても
将来的に音声ブラウザへの対応にも触れる可能性が高い。

気にせずにいってもいいと思うんだけど、
やっぱり長期的展望というのも持っておきたいと思う。
そんなわけで、まだまだ悩みそうです。
なので、もっといろいろ案をください。

482 :Name_Not_Found:02/07/01 01:36 ID:???
ディレクトリ名については~accesskeyでいいんじゃないかな。
tabindexよりはaccesskeyの方が知名度あると思うし。

というより、ウェブやブラウザの操作って、新しくて複雑な概念(?)だから、
それらを的確にあらわそうとすると、どうしも単語じゃなくて文章になっちゃう気がする。
新しい言葉を創っちゃうなら別だけどさ。

適切だけど長すぎるディレクトリ名よりは、
意味が狭いかもしれないけど短くて分かりやすい方がいいと思うし。

483 :1:02/07/03 23:15 ID:???
>>482
>ディレクトリ名については~accesskeyでいいんじゃないかな。

じゃあ、accesskeyでいきますか。
扱う内容は、accesskey及びtabindexからはじめて、
ゆくゆくはlink要素や音声ブラウザ対応にも触れてみるということで。

>適切だけど長すぎるディレクトリ名よりは、
>意味が狭いかもしれないけど短くて分かりやすい方がいい

うん、この考え方っていうのは大事だと思う。
僕はついつい長く長く書いていくたちだから、短く分かりやすいには憧れる。
新しい言葉を作るのもなんか本末転倒っぽいから、
やはり~accesskeyが妥当そうですね。

484 :Name_Not_Found:02/07/04 23:03 ID:???
良スレですね
accesskeyに関心が沸きました

485 :1:02/07/05 01:01 ID:???
>>484
ありがとうございます。頑張ります。

486 :Name_Not_Found:02/07/08 23:06 ID:???
取り敢えず、
「accesskeyのはなし」
ぐらいの単純なサイトで十分だと思うが。
内容が膨らめばその内
「Webサイトブラッシュアップ作戦」
てな感じでもいいけど。

487 :Name_Not_Found:02/07/08 23:06 ID:???
age忘れ

488 :Name_Not_Found:02/07/08 23:35 ID:???
>>487
一応 >>467 を読んでくださいな。

489 :Name_Not_Found:02/07/15 16:33 ID:???


490 :移転時に死にそうになっていたので:02/07/16 20:52 ID:???
保守

491 :1:02/07/16 22:45 ID:???
なにやら弱りながら、皆さまの保守により生き存えております。
申し訳ない。某Webスペースサービスに申し込もうと思ったら、
現在受け付けてないとのこと。ショックが大きいです。

さて、出てきただけというのも申し訳ないので、少し方向性を定めたいと思います。
accesskeyスレでは、現在においてもサイト制作に向けての諸案を募集しております。
基本的な枠組みは、>>333-334 >>346-347 あたりを、
サイト立ち上げの流れは、>>339 >>351 あたりを参照していただきたい。
つまり、現在まだ草案を作ろうという状態からまったく動いてないのです。

どんな小さなアイデアでも歓迎です。中には光るものがあるかも知れない。
でも、一応は過去スレも読んでください。第一次のダイジェストは、
>>262-264 を参照ください。
サイトを作ろうという話は、>>333- くらいから具体性を帯びています。

では、皆さまの御参加をお待ちしております(他力本願だよね)。
僕は、目当てのWebスペースがサービス再開するのを待ちながら、
序文案を考えてみたく思っています。
では、少しずつでも動きたいと思いながら。

P.S. 夏の間は極力sage進行でお願いします。

492 :50(iCab):02/07/16 23:25 ID:???
このスレから足が遠のいてました。

>>491
なんか、このスレ、
内容が濃いので、すぐにはまとめあげられないですね。
特に私なんて、頭があまりよくないし。

時間がある時にもう一度読み直して、
(昔の議論を忘れつつある私…)
何かアイディアを思い付いたらまた書き込みします。
なんとか1さんに協力して、認知度を高めたいですから。

493 :463:02/07/16 23:30 ID:???
共通キーの推進、という観点が出てくる以上、
実際に(少なくとも我々が考えている)推奨されるキー割り振りを考えて規格化し、
この規格に名前を付ける必要があるのではないでしょうか。つまりガイドラインです。

1さんの作るこのサイトでaccesskeyやtabindexのガイドラインが出来る

これに同意する他のサイトが
「このサイトは<a href="***">○○(ガイドライン)</a>に準拠してaccesskey、並びに
tabindexを設定しています」という説明書きを入れる

閲覧者はより便利にWebを巡回出来る

こうになればいいなぁ。
1さんのサイト立ち上がりには期待してます。
また何か思いついたらカキコします。
今のところ応援しか出来ないので恐縮ですが、暑さに負けず頑張ってください。

494 :Name_Not_Found:02/07/19 04:56 ID:???
>>463
改めてガイドラインに名前をつける必要なんてないと思うけどなぁ。

現時点で重要なのはまずサイトを立ち上げて、
まずはすでにできている分で十分だから、
とにかく推奨するaccesskeyなどの設定案とその根拠となる考えを示すことだと思うよ。

そして、賛同してくれるサイトにそれに準拠した設定をしてもらい、
できればこのサイトの案に従ったということを宣言・宣伝してもらう。
そうやって少しずつ少しずつ広めていくだけじゃないかな。

他の設定パターンと区別しなくてはならなくなったら、勝手に判別できるように呼んでくれるだろうし、
まったく相手にされなかったら悲しいけど名前なんて必要ない。
なによりも理想は規格をつくることではなく、標準化することなんだから。
もしこの振り分けが当たり前になれば、誰も規格名なんて呼ばないし意識すらされないよ。
無謀かもしれないけど志ぐらいは高くもたなきゃね ←1さんに感化された(w

495 :1:02/07/20 22:15 ID:???
accesskeyコンテンツ序文案

タイトル:キーボード派のためのアクセスキー(仮)

■はじめに
 あなたにはお気に入りのサイトがあって、そこに通うようになってからもう随分経ち
ました。なのでサイトの隅々まで分かるようになっていて、見たいページがどこにある
のかなんて、すぐに分かってしまいます。
 あるいは、あなたは自分の仕事や趣味に必要な資料をまとめて、WWWに公開していま
す。こうしておくと同じ仕事、趣味の人たちの役にも立てるし、何より自分にとって便
利です。自宅、職場という場所を選ばずに、必要な資料をすぐに引きだすことができる
のです。
 あなたはサイトにアクセスしました。目的のページはすぐに見付かります。そういえ
ば、あのページにも必要な情報があったっけ。あなたはサイトを縦横に移動して、必要
な情報を集めていきます。マウスを片手に、目次へのハイパーリンクと必要な資料のハ
イパーリンクを次々クリックしながら。ですがこのところ、あなたにとってはこの作業
がわずらわしく感じられていました。情報探しがではありません。ページのどこかにあ
るハイパーリンクを見つけて、マウスポインタを動かしクリックする。この毎回毎回す
る同じことが、ちょっと面倒になっているのです。
 ああ、コピー&ペーストみたいにショートカットキーが使えたらいいのに…… でも
そんなの無理な話とあなたは思って、マウスをまたカチカチし始めました。
 けれど、それが可能なのです。インターネットのWebページをキーボード操作で便利
に利用するための手段はすでに用意されているのです。

■キーボード派のためのアクセスキー
 その便利な手段というのが、、これからお話するアクセスキーです。ハイパーリンク
や入力フォームに設定することによって、キーボード操作でそのリンクやフォームを選
択することができるようになります。わずらわしいマウスポインタを動かしてカチカチ
という作業から開放され、ショートカットキー操作で例えばトップページを、目次ペー
ジへのハイパーリンクを選択できるようになるのです。
 でも、そんな設定をする画面なんてどこにもないよ、あなたはそう思うかも知れませ
ん。そうなのです。この設定はWWWを閲覧する人ではなくて、Webページを作成する人が
行うのです。

■アクセスキーへの招待
 残念ながら、アクセスキーが用意されているサイトはあまり多くありません。また仮
に用意されていても、サイトAとサイトBでは、異なるキー操作が要求されるかも知れま
せん。あるソフトではControl+Cでできるコピーが別のソフトではControl+Kとかだった
ら、絶対不便ですよね。使うソフトごとにショートカットが違ってたら、どうにも使い
にくいではないですか。ですが、これは悲しいことなのですが、今のWebサイトにおけ
るアクセスキーの状況というのは、「ショートカットキーが使うソフトごとに違う」よ
うな状況なのです。
 わたしたちは、せめてこの「アクセスキーがサイトごとに違っている」状況だけでも
なんとかしたいと思って、このサイトを立ち上げました。わかりやすく使いやすいアク
セスキーの目安を紹介し、多くのキーボード派が満足できるWebサイトが増えてくれれ
ば嬉しいと、ささやかながら願っています。

■このサイトの構成


496 :1:02/07/20 22:22 ID:???
1です。accesskeyコンテンツ向けの序文案をようやく書き上げました。
これを叩き台として、よりよい序文を作っていきましょう。

全体的には、中級者以上を対象とした内容にしてあります。
マウス操作よりもキーボードショートカットを好む人向けといってもいいでしょう。
ですが、できるだけ専門用語っぽいものは避けたいとも思いました。
それでも分かりにくい部分、的を射てない部分があると思います。
そういう部分を、是非どしどし突っ込んでいってください。

■のついた文章は見出しと考えてください。
「」で囲まれたところは、em、strongでマークアップしたい部分です。
最後の「このサイトの構成」以下が書かれていないのは、
まだ実際の構成が決まっていないため、空けてあります。
送信ミスじゃないですよ。

みんなで、サイト立ち上げに向けて頑張りましょう。
また、これとは違う序文案を対案としても出してもらえると嬉しいです。
では、よろしく!

497 :1:02/07/20 22:42 ID:???
>>492 (50 (iCab))さん
僕も、ここ最近暇を見ては、このスレッドを読み直してたんだ。
結構初期にもいい議論があったりして、目から鱗でした。
それになんか懐かしくて、面白かった。

僕は >>77 でもいってるけど、
「僕が」サイトを立ち上げるというのは、
やっぱり不遜であると思ってます。
なので、可能なかぎり多くの人の力が必要です。
なので、どしどし参加、よろしく!
タイムリーに50 (iCab)さんは参加、反応していてくれてたし、
きっとこれからも頼れる仲間であると思ってる(重荷? だったらごめんね)。
なので、僕も頑張りますよ。

>>493-494
案の提出とその対案、ありがとう。
accesskeyの推奨割り当てを規格化するというのは、
ある意味僕にとっては盲点だった。
というのも、僕は「目安」になるものと思ってたので、
逆にそこまでしっかりしたものを制定する気じゃなかったんだ。
むしろ、494さんの考え方に近いといえる。

最終的な位置としては、accesskeyに迷った人に参照されるサイトになりたい。
例えば僕はHTML初心者には、
The Web Kanzakiの「30分間HTML入門」を紹介することにしている。
こういうスタンスのサイトになればいいなあと思ってるんだ
(不遜な物言いであることは、重々承知してますよ)。

だから、参照する人が多ければ多いほど、結果的に標準のものとなる。
494さんのいう「高い志」かな?
ある意味これこそが規格化も知れないけど、あえて名前をつけるのではなくて、
自由さを残したまま、みんなで参加して発展させられるような感じを残しましょう。

> 今のところ応援しか出来ないので恐縮ですが、暑さに負けず頑張ってください。
いえ、充分有用な発案でしたよ。それに応援、ありがとう。すごく嬉しかった。
できるだけ期待に沿えるよう、頑張るよ。

> 1さんに感化された
なんか面映ゆいけど、嬉しいよ。
このスレッドは、参加してくれる皆さんによって支えられているんだと、
心から思える瞬間です。
思えばずっとこうやってきたんだなって思う。

なので、これからも皆さん参加、よろしく!

498 :Name_Not_Found:02/07/20 22:51 ID:???
うん

499 :Name_Not_Found:02/07/21 00:56 ID:ASOvFUeo
いよいよ話が具体的になってきたんですね。
1さんの序文、とても分かりやすいと思います。

構成は、普通に考えるとアクセスキーの説明→現状の例など、このスレでの議論
→アクセスキーの割り当ての目安まとめ、って順序くらいが妥当かな?
アクセスキーが効果的に使われてるサイトなんかがあったら
例に挙げていけると分かりやすいかもしれないですよね。

>accesskeyに迷った人に参照されるサイトになりたい

実際、このスレには迷っている人たちが集まってきてた
わけですから、間口をもっと広げて行きたいというのは
正しい目標設定だと思います。
せっかくここまで話が膨らんだんだもの、がんばってくださいね。

500 :Name_Not_Found:02/07/21 05:05 ID:???
>>1サソ(;´Д`)ハァハァ
…んーと、冗談です。

Tab によるシーケンシャルなフォーカス(違うけど)移動と
比べると利便性が強調されるかも。とか思ったり。


501 :Name_Not_Found:02/07/21 08:35 ID:38fkx0iM
ふと思ったんだけど、accesskeyがもし全てフォーカスタイプだったら、
例えばMeta+"A"でaccesskey="A"の要素間を移動する
と言う手も考えられないか?
丁度MacIEのOption+Tabと同じ感覚で。

502 :Name_Not_Found:02/07/21 15:20 ID:???
>>501
NS6/7では、複数のリンクに同じaccesskeyがあった場合、最初のものに飛ばされてしまいます……


503 :1:02/07/21 19:02 ID:???
>>498
応援、ありがとう!

>>499
この後、サーバを探さなければなりませんが、
公開しようという気運は高まってきたと思っています。
ただ公開場所をどこにしようか、またまた迷い中。
一応半分は決めているのですが。気持ち半分は……

499さんの案を受けて、
以前に提案したアウトラインにおける1を充足させてみました。
accesskeyの概略と実際を最初にしっかり説明して、
どんなふうに便利かもアピールできればよさそうだよね。
ちょっと変更したアウトラインは、最後に載せておきます。

> 間口をもっと広げて行きたいというのは
> 正しい目標設定だと思います。

多くの人に参照され、多くの人の役に立てるといいなと思うよ。
こうやって賛同してくれる人が増えると、僕も頑張れそうに思う。
ありがとう、力づけられます。

>>500-501
> 例えばMeta+"A"でaccesskey="A"の要素間を移動する
> と言う手も考えられないか

501さんのいうところによると、
NS6/7では最初のものにヒットするみたいだけど、
IEだと同一accesskeyが付与された要素を順次移動するのですか。
もしそうだとすると、便利な使い道も出てきそうだね。

例えば、複数の言語版を用意してるときなんかにはどうだろう。
English / Français / Deutsch / Italiano / Español / 中文
とページ上にあったとしたら、すべてに同じaccesskeyを割り当てちゃう。
これだと、対象間移動するUAにはより便利になる。
そうでないUAにとっても、EnglishからTab移動してもらえばよいだけだから、
増して不便になるわけじゃない。

うん、使いようによってはより便利になりそうですね。
他にもよさそうな使い方を模索してみます。

504 :1:02/07/21 19:02 ID:???
■アウトライン更新しました■
1および6-2が変更されています。

■グループ「accesskey」
1. accesskeyについて
 1-1. accesskeyの役割
 1-2. accesskeyの現状
2. このましいaccesskeyとは
 2-1. accesskeyが割り当てられて便利な場合
  2-1-1. link typeの応用
 2-2. アルファベットによるaccesskey
 2-3. 数字によるaccesskey
3. 開設者のためのaccesskey:設置について
 3-1. accesskeyをサポートする要素
 3-2. CSS3におけるaccesskey
4. 閲覧者のためのaccesskey:操作について
5. accesskeyの実際
 5-1. 二種類の挙動
  5-1-1. 問答無用型
  5-1-2. 対象フォーカス型
6. 今後の課題と展望
 6-1. ユーザの場合
  6-1-1. 共通キーの推奨
 6-2. UA製作者への希望要望
  6-2-1. LINK要素を解釈しての自動accesskey割り当て
  6-2-2. 機能キーのカスタマイズ
  6-2-3. 挙動(問答無用 or 対象フォーカス)の選択
7. 便利なUA機能拡張紹介

6-2の内訳は、
> LINK要素を解釈しての自動accesskey割り当て
はいうまでもないことですが、

> 機能キーのカスタマイズ
は、Alt+KeyやKeyのみかとかを選べるようにして欲しいというもの、

> 挙動(問答無用 or 対象フォーカス)の選択
は、対象をフォーカスするだけと問答無用でヒットするかを
ユーザーの好みに応じて選べるようになるとありがたいというものです。
あるいは、Alt+Keyで対象フォーカス型、
Alt+Shift+Keyで問答無用型みたいに、
使い分けられるようになると便利さは増すのではなかろうかという提案です。

あと、対象をフォーカスしたときにtitle属性値をポップアップして欲しいなあ。
思うところは、忘れないうちに書いておくようにします。

505 :500:02/07/21 19:15 ID:???
>>503
> 501さんのいうところによると、
> NS6/7では最初のものにヒットするみたいだけど、
> IEだと同一accesskeyが付与された要素を順次移動するのですか。
> もしそうだとすると、便利な使い道も出てきそうだね。

アレ? 挙動が違う……
IE5.01SP2@Win2k では同一 accesskey 間を渡り歩きました。
始めて知ったけど、便利だなぁ……
で、問題は Mozilla1.0 (2002053012) ですが、
同一 accesskey があると最後のリンクを開いてしまいました。
下は試しに使ってみたソースです。レンダリングモードの違いかな……

----
<html>
<body>
<a href="" accesskey="A">◊</a>
<a href="" accesskey="B">◊</a>
<a href="" accesskey="A">◊</a>
<a href="" accesskey="B">◊</a>
<a href="" accesskey="A">◊</a>
</body>
</html>
----

506 :Name_Not_Found:02/07/21 20:06 ID:???
1さんトリップつけた方がよろしいかと存じます
名前の後に #好きな文字 です。
こんなことしってますね

507 :1:02/07/21 23:39 ID:???
>>500
ごめん、先のレスではとばしてしまってた。
わざとじゃないんだ。ごめんね。
Tabによる順次移動とaccesskeyの直接的な移動の違いと、
それぞれの便利さを表現できるといいかも知れないですね。
この両者の便利さの違いがわかれば、
accesskeyとtabindexの利点を引きだせるようになりそう。

accesskeyの利便性は、
たくさんの要素中に埋もれたものであっても、
一発でヒットできるところだろうから、わかりやすくていい。
この説明は、アウトライン 1-1で、かな?

>>505
検証ありがとう。
同一accesskeyを渡り歩くのは、Win IEだけみたいですね。
accesskeyの挙動に関しては、UA依存の部分があまりに多すぎて、
ひとまとめにして説明できないところが悩みだよ。
でも、こういう差異を吸収しながら、よりよいやり方を見付け出せたらいいよね。
今回の渡り歩き挙動に関しては、収穫でした。
僕の方でも、いろいろ試してみるね。

>>506
うん、トリップに関しては僕も考えたことがあったんだ。
でも偽の僕が現れたこともないし(一度現れたけど)、
むしろ僕を固定しないほうがいいように思ってた。
どうなんだろう。今後の動き次第では、つけるかも知れないけど、
今のところは1のみでいってみます。

508 :Name_Not_Found:02/07/25 00:56 ID:???
某MLで紹介されてたんだけど目指そうとしてるところは同じ・・・かのぅ。
ttp://www.tkylab.com/cl/1scroll/out/index.html

509 :名無しさん@お腹いっぱい。:02/07/25 04:20 ID:???
>>508
うわ、これめっちゃ使いやすい。
って普段 Unix 使ってるからかもしれんけど。

やっぱりアクセスキーはユーザが決めるのが自然だよねぇ…
さんざん既出だけど。Windows ユーザがこれを使いやすいと思うかどうか。

510 :1:02/07/25 20:16 ID:???
>>508-509
僕もさっそく試用してみたよ。

確かに使いやすいと思った。D/Fで上下スクロールできるというのは、
遠くのカーソルキーまで手を伸ばす必要がないので、ものすごく快適。
だって、Returnが面倒くさくて、Cont+Mを使ってるような僕ですから。

けれど、これってJavaScriptで実現されている機能だから、
残念なことにUAに依存するんだよね。愛用してるiCabでは反応しなかった。
もちろんaccesskeyもUAに依存する部分大なのは分かってるけど、
この先にはこういう機能やaccesskeyなんかが様々なUAで、
自然に使えるくらいに整備されると良いなと思ったんだ。
それくらい、上記のサイトの機能は、画期的だ。Googleに引き続くヒットだよ。

> やっぱりアクセスキーはユーザが決めるのが自然だよねぇ…

うん、僕もそう思うよ。CSS3が実現の暁には、
HTMLドキュメントにはrel属性を設定するようにして、
ユーザースタイルシートでaccesskeyを選べるようにもなりそうだけど、
現実的には夢物語にすぎない。
UAによるaccesskey自動割り当てもなかなか日の目を見ないアイディア。

だからこそ、ここで話したことを広く世間に知ってもらう意義がありそうだ。
うむ、サイト立ち上げ、頑張りましょう。

■進捗状況
サイトを立ち上げたいと思っているお目当てのWebスペースは、
現在申込をしていないので、もう少し時間がかかりそう。
なのでそれまでに、サイト構成案や序文、さらには導入部分への考察なんかも、
進められるとよいのではないかな。
なのでアイデア、要望など、引き続き募集ですよ。
皆さんのお力添えあっての、accesskeyスレッドです。

P.S.
発言はsageでよろしく。

511 :Name_Not_Found:02/07/25 23:04 ID:???
何をそんなにガクガクブルブルしてsageてんのかは知らんけど、
UAどころか半ばキーボードにも依存しているんだな。

512 : ◆R4.ALMK. :02/07/26 00:51 ID:???
>>511
ドボラック配列だとどーなるんだYO! とか?w

513 :名無しさん@お腹いっぱい。:02/07/26 04:43 ID:???
普通のキーボードと違う入力環境だったらどうするのとかでしょ。

なんちゅうか、インターフェースは UA だけで決める方がいいような…
UA は自分が動いてるシステムの設定に触れることが出来るんだから、
システム標準のキーバインドとか出来るだろうけど
文章でそれを制約しちゃうのは後々害悪になると思う。

JavaScript だと UA 依存とはいうけど、accesskey だって UA 依存だしね。
個人的には現在の accesskey にはそのまま消えて欲しいと思うので
あんまり啓蒙しないで欲しいとも思わなくもない。

ただ、このスレで議論(?)してた部分は結構参考になったんで
まとめていただけるのは嬉しいです。

514 :1:02/07/26 10:08 ID:???
>>511-513
>UAどころか半ばキーボードにも依存しているんだな。

うん、これは確かにそのとおりだね。
こういった事情も配慮されるようにならないと、
本当はいかんのだろうとは思う。
みながみなJISキーボードを使ってるわけでもないし、
いわゆるANSIやDovorakを愛用する人もいるわけだし。
だから、accesskeyなんかは一方的に決められるんじゃなくて、
ユーザーが自分に便利なようにカスタマイズできるように
ならんないといかんのだろうなあ。

>>513
>なんちゅうか、インターフェースは UA だけで決める方がいいような…

できれば、もう一度この辺を説明してもらえないかな。
というのも、もしかしたら取り違えてしまう可能性がありそう。
これはつまり、UAによるaccesskeyの自動割当が望まれるということですか?
こう考えると、
>文章でそれを制約しちゃうのは後々害悪になると思う。
へのつながりがちょっとわかりにくい。

申し訳ないんだけど、補足できるなら、よろしくお願いします。

それと、お願いばかりで申し訳ないんだけど、
>現在の accesskey にはそのまま消えて欲しい
という理由なんかを、具体的に書いてもらえればすごくありがたい。
というのも、このスレッドではaccesskeyについて、
不要と思う人がいても、まああっても困るものじゃないからつけとこう
といったような流れがあって、決定的な否定論が生まれなかった。
というか、僕を中心にそれらをつぶしてきたといってもいい。

だからあえて今、そのアンチテーゼを求めたいと思ってる。
よければ、もう少し具体的に書いていただきたい。
できれば、その先にあるaccesskeyの望ましい有り様が見えれば、
なおうれしいと思う。よろしく。

>まとめていただけるのは嬉しいです。

ありがとう。あまり強硬論みたいのにはしたくないので、
もしそういう傾向が見えたら、そのときにはブレーキをかけてほしい。
なんかお願いばかりだね。でも、そういう力が必要だと思うので、
重ね重ね、よろしくお願いします。

>>511
>何をそんなにガクガクブルブルしてsageてんのかは知らんけど、

いやはや、これは自分の不徳のいたすところで、
広告みたいのが入ってくるとそのたびへこんでしまうんだ。
だから下げときたいなというだけで、それほど含みはないんです。

515 :Name_Not_Found:02/07/27 08:02 ID:???
はっきり言ってCSSでのスタイル指定もインターフェイスの定義なんだがな。
多分UAのと被るから嫌だと>>513は言いたいんだろう。
予約された空間内で扱えれば問題ない。
例えば特定のキーアサインの後に続けて打ち込む
(Alt+kの直後にaccesskey)とか。

そうでなければHTML内でaccesskeyを固定するなと言う意味か。
スタイルシートで扱う方法はCSS3で策定中。しかも既出。
CSSのセレクタに引っ掛かかればいいから、
例えばSolarisのログインスプラッシュみたいに
多言語がズラッと並んでいる所で<p xml:lang="ja">だけを
ジャンプして行くって言うのも面白いかもしれない。

516 :Name_Not_Found:02/07/27 23:50 ID:???
accesskeyに限らず、アプリのショートカットキーていうのはWin/Macの
初心者にとってはグラディウスの無敵コマンドみたいな、
秘密の操作法に思えて便利なんだけどなかなかとっつきにくい。
1の理想は>>29みたいに「説明しなくてもaccesskeyをつかえる」ようにすることかもしれないけど、
>508をみてやっぱりaccesskeyを明示的に書いておくと便利だと思った。
「このサイトについて」みたいな別項にくどくどと説明するよりも

[Alt+I] :Index
[Alt+H]:Help
[Alt+T]:Top
[Alt+P]:Prev
[Alt+N]:Next

ってトップページの目立つとこに書いておけばaccesskeyを知らなかった人でも
気になって押してみたりするかもしれない。

あるいは、JavaScriptに詳しくないから出来るのか知らないけど、
[Alt]を押すとポップアップが出て

Index[I]
Help[H]
Top[T]
Prev[P]
Next[N]

というようなナビゲーションが出るとか。
スレの本題から外れるけど、こういうわかりやすくするためのアプローチも1のサイトに
盛り込んでみたらどうでしょうか。

517 :名無しさん@お腹いっぱい。:02/07/28 10:14 ID:???
>>516
あー、そのナビゲーションがポップアップするってのは
かなりいいと思う。

でも JavaScript でやるのはなぁ。冗長な気がする。
UA 側で実装するべき機能でしょう。
Mozilla だったら XUL で出来そう。
Piro さんあたりやってくれないかな。

518 :Name_Not_Found:02/07/28 11:59 ID:???
少しでも協力したいので、>>495の序文案を推敲してみたのですが、
このようにしてみたと文全体を提示すればいいですよね?

>>514
へこんでしまうという1さんのお気持ちも分かりますけど、
もっと多くの人の意見が必要だと思いますし、
accesskeyを広めるという趣旨からも、
もう少し人目につきやすいように多少は上げた方がいいのではないでしょうか?

徹底してsage進行では、
スレに集まっている人だけを対象にしているように思えてしまいますけれど……。

519 : ◆S0qIRC9I :02/07/28 23:12 ID:???
>>517
具体案としてまとめて頂ければ、そのうち取りかかれますが……

ContextMenu-ExtensionsのNavigationsと、その機能とをまとめて、
別パッケージにしても良いかも。


520 :Name_Not_Found:02/07/29 16:43 ID:???
>>519
Altでポップアップちゅーのはメニュー操作とかの場合にも
出て来るとうざいだろう。
いっその事>>515みたいに別のキーバインドに変えて欲しいんだが。
メニューバーのはしっこに「Accesskey(K)」なんてメニュー項目が
あってもいいかも知れん。

521 :名無しさん@お腹いっぱい。:02/07/30 08:05 ID:???
>>520
本来の accesskey の機能を殺して
メニューのアイテムとしてのショートカットにするわけですね。
なるほど。

そういや、>>508 でやってるようなスクロールみたいなのは
accesskey の管轄外なんだよね。

522 :Name_Not_Found:02/07/30 16:23 ID:???
>本来の accesskey の機能を殺して
なんて言われるとなんか悪い事みたいだな(w

単にUA操作のキーバインドと
全く同じレベルで扱われるのが疑問なだけだよ。
例えばMozillaがAlt+Shift+(キー)
な操作を他に受け付けないんであればそっちでもいい。
それと、ユーザーにどう言うキーバインドがあるかを明示する際に
メニューバーってインターフェイスは
メタファの適用が最も容易だろうと言う事。

523 :名無しさん@お腹いっぱい。:02/07/31 09:38 ID:???
>>522
自分でも書き込んでてなんかネガティブな表現だなって
思ってたよ > 殺す

キーバインドの空間は分けるべきだってアイデアは大賛成です。

accesskey が振られてなくても
a 要素の内容から規則的なショートカットを作成するなんてのは
出来ないかな。

頭文字からアルファベットを抽出してキーを押すごとに循環するとか。
でもこれはどんなリンクがあるかわかってないとだめではあるね。

524 :Name_Not_Found:02/07/31 21:39 ID:???
MacのFinderみたいにタイプした文字列を
その場で検索してリンクを選択してくれると便利かも。

……知らない人にはなんとも説明のしようがないんだけど。

525 : ◆R4.ALMK. :02/07/31 23:28 ID:???
前に誰かが言ってた気がするけど
MacIE5 も文字タイプすると、それを頭文字に持つリンクテキストに
フォーカスが移動するですね。そのあと tab で同種のアンカーを
次々に移動できるかとおもいきや、できないのだけど。

526 :名無しさん@お腹いっぱい。:02/08/01 09:18 ID:???
>>524
hoge って打つと、hogehoge、hogerarian、hogettemasu、
みたいにファイルを循環してサーチしてくれるみたいなかんじ?
一応 Win にもあるような。

というか、Emacs の isearch もとい migemo のローマ字検索機能を
UA にもつけてほしいと思う今日このごろです。
インクリメンタルサーチ機能の付いた UA って w3m 以外にあったっけ。

accesskey とはなんもかんけいないですね…。

527 :Name_Not_Found:02/08/01 14:43 ID:ScgcWc5n
>>525
そりゃユーザが同種の文字列を望むのか
単にその次のリンクを望むのかは判断出来ないからだろう。

……なぁUAユーザビリティスレ建てるか?

528 :Name_Not_Found:02/08/01 16:47 ID:???
すきっす。

529 :Name_Not_Found:02/08/07 21:08 ID:???
1タン(Щ゜Д゜)Щカモーン

530 :1:02/08/07 21:43 ID:???
>>529
了解! 明日書くよ。
ちょっと、自分の理想のWebについて考えてたんだ。

(´-`).。oO(とかいいながら、実は夏バテ中……)

531 :1:02/08/08 13:49 ID:???
お約束どおり、1です。この十日ばかりの動きをまとめましょう。

■UAのショートカットとaccesskeyがかぶる問題
>>515 >>520-523
確かにこれは、accesskeyを考える際に、
一番厄介な問題なんだよね。
これまで過去にも、タブーの組みあわせが紹介されたりしてきたけど、
本質的に、Alt+keyに複数の意味(UAのショートカットとaccesskey)が
生じてしまうというのは問題だわ。
でもUAの挙動に関しては、希望を出して働きかける以外にないからなあ。

以前にいっていて動きの見えないaccesskeyサイトでは、

 6-2-1. LINK要素を解釈しての自動accesskey割り当て
 6-2-2. 機能キーのカスタマイズ
 6-2-3. 挙動(問答無用 or 対象フォーカス)の選択

あたりで、現在のaccesskeyまわりの問題と、
その解決となるような代案を出したいと思っている。
ここで、今話しているようなところを膨らませられるとよいな。
で、また英語書くのか……
日本語サイトじゃ、大局にはなんもうったえんからね……

■accesskeyを見えるようにする工夫
>>516-517 >>520 >>522
Altでポップアップというのはわずらわしいところもあるし、
Winならともかく、他の環境ではうまくないかも知れない。
だけど、こうやってkey一覧を見えるようにするのは、
重要だと僕も思う。
>>117 のアイデアなんて如何?

UA自体の機能拡張もありかも知れないけど、
現状においてはUA側ではなくて、作成者側の工夫でいけると思う。
もちろん、UAがやってくれるに若くはないけどね。

■推敲
>>518
推敲してくれたんだって、ありがとう。
もうここで、どーんと貼り付け公開してください。
すごく嬉しいです。

532 :1:02/08/08 13:49 ID:???
■MacIE5の機能
>>524-527
僕はこの機能を知らなかったから、ちょっと目から鱗。
知らない機能というのが多くて、不勉強を恥じるばかり。
これをうまく使えば、MacIE5では、
問答無用型(accesskey)とフォーカスのみ型(この機能)を
使い分けられるかも知れない。便利かな?

■sageの件
>>518
これに関しては、ちょっと僕がナイーブになりすぎてた。
ここに書き込む個人個人がその判断によって、
上げる下げるを選ぶというのが当然のことだよね。
この、参加者ひとりひとりの意志を尊重することを、
不遜にも僕は忘れて、管理者を気取っていたのかも知れない。
うん、上げたい人は上げてください。下げたい人は下げてください。

■1の理想
>>516
実をいうと、僕にはなんの理想なんてのもなくて、
accesskeyを振ろうとしたときに、自分で考えるのが面倒なので、
人に考えてあわよくば決めてもらおうというのが
このスレッドの発端だったりする。わはは、最低だ。
目安を一番欲していたのは実は僕だったというわけ。
僕の、Webサイトの理想形は別のところにあったりする。

僕は、body内には本文以外のものは入れたくないんだ。
パン屑リストもナビゲーション用のアンカー群も、全部いらない。
パン屑は適切なURIがあればすむし、
ナビゲーションは、すべてlink要素で表現すればいい。
そういう人間なので、XHTML2.0(ドラフト)でのnlの出現はショックだったな。
スレ違いでした。

>>528
サンキュー!

533 :Name_Not_Found:02/08/09 15:34 ID:???
XHTML2はhref要素が凡用属性になりますね。
これでa要素はあまり必要で無くなって全ての要素に
accesskeyが。

534 :Name_Not_Found:02/08/09 15:52 ID:nu1l8IRD
1たん、お疲れさま。

>accesskeyを振ろうとしたときに、自分で考えるのが面倒なので、
>人に考えてあわよくば決めてもらおう

たぶんこのスレに来る人の多くはそーゆー他人様の意見を
あてにしてる人が多いと思われ。というか、自分がそうなだけだけど。
でもみんなの人任せ気分も、1たんのリードでいい話し合いに
変化してきたんじゃないかな。
いつかそれが多数の意見の統合に変わっていけばいいよね。

535 :Name_Not_Found:02/08/09 16:15 ID:???
解説する際に推賞キーバインドを挙げるよりも先に
UAのキーバインドと被るんでやめとけってのを
リストアップした方がよかねぇか?
そうすると良さげなキーはほとんど
無くなって行くような気もするけど。
>>7-10に加えて、Macとかの情報も欲しいね。

ところで、@とか*とかでもaccesskeyって効くんだろうか。
ついでに仕様的にそれはどうなんだろうか。

536 :1:02/08/09 20:47 ID:???
>>533
XHTML2.0でhref要素が汎用属性になったというのが、
accesskey属性の汎用化にもつながるのか。
これにはちょっと思いも及ばなかった。

そうなった場合、今以上にややこしさはますのだろうか?
でも少なくとも、
<hn id="n"><a href="#n">見出し</a></hn>
みたいなマークアップが
<hn id="n" href="#n">見出し</hn>
みたいに整理できてよいなあ、
と、全然accesskeyに関係ないことをいっておく。

>>535
> UAのキーバインドと被るんでやめとけってのを
> リストアップした方がよかねぇか?

これは、やっぱり必要だよね。
でも実際の話、かぶらないもののほうが少ないって気もするんだ。
Alt+Dみたいに、完全にバッティングしてしまう致命的ケースもあるけど、
残りのは、どこまで注意したらいいのか分からない。
Windowsユーザーって、Altを使ったショートカットってよく使うの?

Macintoshに関しては、こういうのは考えなくていいと思う。
MacintoshはショートカットにCommand、Option、Controlを使え、
Commandが最も一般的なもの、OptionはIME関連が割り振られていることが多い。
そいで、Controlは空いているんだな(使うソフトもあるよ、もちろん)。
だから基本的にバッティングしないんだ。
ダイアモンドカーソルに使ったり、accesskeyに使ったりできるんだよ。

> @とか*とかでもaccesskeyって効くんだろうか。

>>376 で、accesskey="?" を使えるという例が報告されてるので、
@も*も、おそらく問題なく使えるでしょう。
とはいえ、Shiftを同時押下しなければならないキーは、
環境によっては使えなくなる可能性を
了解しておかなければならないかも知れない。

というのも、もしaccesskeyのキーバインドを変更できるUAが出てきたら、
Alt+Shift とする人も出てくるかも知れない。
こうなったら、? とか * は使えなくなりそうだ。
anci排列を使ってる人だと、@もShift押下だしね。
よって、避けるほうが無難かなあ、と思う。

>>534
> いつかそれが多数の意見の統合に変わっていけばいいよね。

うん、これは僕も願うところだよ。
できるかぎり広汎な意見が反映された、
独りよがりではないものになるといいと思う。
このスレッドは人に恵まれていると思うので、
よりよい方向を目指せそうな気もするんだ。
うん、頑張ろう。

537 :Name_Not_Found:02/08/10 17:31 ID:???
自分参照リンクはそろそろ時代遅れだと思う今日この頃。

>でも実際の話、かぶらないもののほうが少ないって気もするんだ。
推奨キーバインドにはいくらかかぶっても許容できる範囲で済ますにしても
どのキーバインドがかぶるかをデータベース化しておくのは有意義な事だ。

>Macintoshに関しては、こういうのは考えなくていいと思う。
Mac OS Xでは標準のテキスト画面にCtrl+*のEmacs風キーバインドが
あったはずだけど、この辺はかぶらないのか?
って、あとでテストしてみる。
3/4がCarbonブラウザだからベンダが忘れているor知らないって線が濃いけど。


538 :537:02/08/17 22:42 ID:???
駄目デスタ。唯一CocoaネイティブなOmniWebすら忘れてる。
と言う訳でMacでキーバインドが重なる心配はありません。

539 :1:02/08/17 23:48 ID:???
>>537-538
検証ありがとう。
僕の環境はまだOS 9なので、このへんについてはほとんど知らない。
だから、すごく助かったよ。ありがとう。

けど、そういった機能がすっかり忘れられてるというのも、
ちょっと微妙なところですね。

キーバインドのまとめに関しては、
一度しっかりとしたものを作ってしまいましょう。
まだ必要はないと思うけれども、
その時(キーバインド関連のページを作るとき)が来たなら、
一気に洗い出しましょう。
それまでは、いろいろ出来そうなことやったほうがよさそうなこと含めて、
考えを練っていきましょう。

サイトの方は、目当てのWebサービスの募集再開待ち。
もうちょっと待ちましょう。焦っても仕方がない。

540 :Name_Not_Found:02/08/21 19:44 ID:???
保守

541 :age:02/08/26 23:28 ID:???
age

542 :Name_Not_Found:02/08/28 02:37 ID:???
保守ピタル

543 :Name_Not_Found:02/08/29 23:44 ID:???
┌―――――――――――――――――――┐
| 保 感 ヤ |
| ∧ ∧ アブナカッタゾゴルァ |
| (,,゚Д゚)____, 全 じ バ |
|● ___ .(つ__|| cっ || |
| 日∇ ̄\|\||._.FMV._.|| レ た イ |
| 2  ̄ \||二二=ニ|| |
|点  ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄ ̄| ス ら と |
└―――――――――――――――――――┘

544 :Name_Not_Found:02/08/29 23:45 ID:???
うおお!ズレまくり(ToT)

545 :1:02/08/31 12:13 ID:???
ちょっと長く沈黙しすぎてるね。
保守してくれていた皆さん、ありがとう。

沈黙にはそれなりの理由があって、
期待しているWebサービスが再開しないので、
大きな動きがとれないのであります。
そこが無料だから、というのを期待しているのではありません。
あるひとつのポリシーを持って、人の輪を築こうとしている、
そのサーバ管理者の心意気を僕は買っているのですが、
だからといって、このスレッドに参加してくれている人を、
長々と待たせ続けているのも申し訳ない。
別のWebサービスを考慮に入れる方向で、動いてみようと思います。
お勧めがあったら、よろしく。

サイト予定地が決まったら、現状のまとめをサイトに載せときたい。
さすがにちょっと訳分かんなくなってくるね……
仮置きをどこかにしようかな。

546 :Name_Not_Found:02/09/01 00:47 ID:???
がんばってちゃぶ台

547 :1:02/09/02 12:38 ID:???
フリートークネットワーク(http://free.ftn-jp.com/)というところが、
無料で広告なしのWebスペースを貸してくれるサービスをしているということなので、
申し込んでみました。
アカウントが八文字以内ということなので、a-keyで申し込んでいます。

受かればとりあえず、サイト序文を公開して、現在の進行状況のアナウンスを行います。
その後、このスレッドで行ってきたことのインデックスを作成しましょう。
そうでもしないと、途中からの参加者には全く把握できないこと請け合いです。

もしここが駄目だった場合のため、お勧めのところがあったら教えてください。
どうも僕はこういうのが不得手でいけない。
いや、今回もいろいろさがして、登録フォームに必要項目を全部書いて、
なのに受け付けられなかったりもしたんだ…… ちょっと疲れた……

548 :Name_Not_Found:02/09/02 13:24 ID:???
http://www.asn.ne.jp/
新規募集がもうすぐはじまるようです
がむばってちゃぶ台

549 :1:02/09/02 14:20 ID:???
>>548
見にいったら始まっていました。早速申し込みして、返事を待っています。
タイムリーなので嬉しい。よさそうなところを紹介してくれて、ありがとう。

550 :Name_Not_Found:02/09/02 15:10 ID:???
>>548
ええなぁ、そこ。
思わず応募したくなったw

551 :Name_Not_Found:02/09/03 21:15 ID:???
1さん 遂にアカウント取れたね

552 :1:02/09/03 23:14 ID:???
>>551
うん、念願のアカウントですよ。しかも、かなり理想的な環境です。
おしえてくれた >>548 さんにも、早速チェックしてくれた >>551 さんにも
ありがとうといいたい。
まだ具体的には序文しかできていない状況ですが、
徐々にでも明確なかたちを描けるよう、前向きに動けそうです。

お披露目はFTPできるようになって、トップページを入れてから、
と思ってたんだけど、ちょっとフライング気味でもいいよね。
トップページを作成したら、そこに最新のアウトライン案を載せて、
各項目に対応するトピックのインデックスを作成していく予定です。

553 :Name_Not_Found:02/09/04 15:16 ID:???
やっぱしStrictなページにするの?
個人的にはこういう事を話すサイトが不思議マークアップだと萎えるんだけど・・・

554 :Name_Not_Found:02/09/04 16:54 ID:???


555 :Name_Not_Found:02/09/04 16:59 ID:???
http://accesskey.aiiro.net/
おつかれ。

556 :1:02/09/04 19:34 ID:???
>>554-555
ありがとう。
とりあえず、決まっている部分だけを公開してみました。
決定部分が増えていくにしたがって、サイトは育っていきます。
CSSとかはもうちょっと先の話ですね。まず、中身から考えましょう。

序文は草案が出ているので、
accesskey関連のアウトライン案にしたがって、
関連発言を整理していきます(ちょっとずつね)。
その上で、各ページの草案を募り、練り上げていきましょう。

このスレッドのダイジェストも作るつもり。
だってaccesskeyやサイト制作に興味をもってこのスレッドを見ても、
流れは容易に掴めませんから。

とりあえず、焦ることなく。徐々にでも進んでいきましょう。

>>553
真のStrictにはなりえないかも知れないけれど、
4.01 Strictでいきたいと思っています。
とりあえず、不思議マークアップにするつもりはないので、
多分大丈夫です。
でも、lintでチェックだけはかんべんな。

557 :Name_Not_Found:02/09/04 20:58 ID:???
なるほど、100点か(w

558 :Name_Not_Found:02/09/04 20:59 ID:???
とりあえず、みんなで>>1さんのhttp://accesskey.aiiro.net/で使える
StyleSheetつくろうよ。

その間中議論しながら。

559 :1:02/09/04 22:15 ID:???
>>558
うん、とても嬉しい提案です。
スタイルシートは、代替スタイルシートも主眼に入れて
いただけると、ありがたいです。
基本的な要素が揃ったら、適当なclass付けをして、
スタイルシートを装備させていきましょう。
ス切りボの出番かも。

ただ、ひとつお願い。
> >>1さんのhttp://accesskey.aiiro.net/
ここは、「みんなの」ね。
name="author" も、
content="the accesskey's thread on the BBS 2ch"
にちゃんとなってます。
僕はただの代表者ですから。みんなの命を帯びているだけなんですから。

>>557

いや、今はシンプルだからいいんだけど、
いろいろ付け加えていくうちに1点2点と減点が始まるから。
My siteは95点なんです。

560 :Name_Not_Found:02/09/04 23:31 ID:???
ちょっと気になった所が。
ul要素使って内容に番号振るのならol要素を使ったほうがいいと思います。

561 :1:02/09/05 00:02 ID:???
>>560
これについてはちょっと迷ったんだけど、
あえてulでマークアップしました。
理由は、現状の音声ブラウザはolの数字を読まないというもの。
このスレッドのサイトでなかったら、多分olを使っていたと思う。

以前このことを、このスレッドで話しあったと思ったんだけど、
見付からなかった。多分Strictスレでこの
ulでマークアップして数字はテキストで用意
という話をしてたんだと思う。
さすがに見つけられなかった、ソースを提供できなくてすまない。

>>556 でいっていた、
> 真のStrictにはなりえないかも知れないけれど、
という、真のStrictになりえない所以が、
例えばこのul要素で番号はテキストです。
直にa nameとかも出てきますよ。

562 :1:02/09/05 00:22 ID:???
>>560
ソース発見。Strict-HTML スレッド 3.0の487がそれです。
http://pc.2ch.net/hp/kako/1013/10138/1013818251.html
list-style-type: noneにしてもよかったんだけど、
最もシンプルな方法を選びたいと思い、素の状態にしてしまいました。

563 :Name_Not_Found:02/09/05 00:38 ID:???
「このましい」に違和感が。
あと、段落頭空白字下げにも。
一番上の「2ちゃんねる生まれのWebサイト」というのは副題?

「みんなのサイト」てのは変な感じだな。あんたが文章にまとめてるんじゃないか。あんたのサイトだよ。

564 :Name_Not_Found:02/09/05 00:40 ID:???
「このましい」でも別にいいんですが他はちゃんと漢字使ってるのにそこだけ目立つよということ。

565 :Name_Not_Found:02/09/05 16:17 ID:???
>>563-564

>「みんなのサイト」てのは変な感じだな。あんたが文章にまとめてるんじゃないか。あんたのサイトだよ
Webサイトは1さんが個人で運営はしているけれど
内容は1さんが1人で考えたものではなく皆の意見を参考にして作った皆のサイトとするのが
1さんの意図じゃないだろうか ここは自分が口出しするところではないのかもしれないけれど。

みんなの文章を参考にして作った私のサイトです というのも違和感が残るし、どうだろうか

566 :Name_Not_Found:02/09/06 00:18 ID:???
まぁ、ある程度は1さんの裁量に任せればいいんじゃない?

567 :Name_Not_Found:02/09/06 00:30 ID:???
>>564
「好ましい」だと、読み上げブラウザが誤読しそうだからでは?
深読みだったらごめん。

568 :Name_Not_Found:02/09/06 13:08 ID:???
取り敢えず、丁寧語とタメ口が混じってるのがカコワルイと思いまふ

569 :Name_Not_Found:02/09/06 13:17 ID:???
>>568
誰の事?番号指名してぽ

570 :568:02/09/06 14:37 ID:???
>>569
スマソ
http://accesskey.aiiro.net/
↑の事っす。

571 :Name_Not_Found:02/09/06 19:47 ID:HhIxfe3O
http://accesskey.aiiro.net/
のサイトはこれから まとめサイト と呼ぶのはどうよ?
>>1さんの」って限定するのもいやみたいだし。

572 :1:02/09/06 19:54 ID:???
http://accesskey.aiiro.net/index.html に、
「サイト構築への手続き(2002-9-6)」

573 :1:02/09/06 19:55 ID:???
>>572 ?

http://accesskey.aiiro.net/index.html に、
「サイト構築への手続き(2002-9-6)」を追加しました。
サイト制作にあたってどのように進めていくかの、
基本的な流れを提示したつもりです。

>>563
段落頭空白字下げは違和感がありますか。
ないほうがいいだろうか?
「このましい」については、実は僕も違和感を感じたんだけど、
意味は通じるので、最終更新時点のままにしておいたんだ。
決して、>>567 という理由ではない、――
>>567 さん、深読みでした。ごめんね。

「みんなのサイト」については、
>>565 さんのおっしゃるのが理由の一つ。
もうひとつの理由として、
僕以外の人間も文章作成に参加してもらうつもりでいるから。
当初から、サイト制作に関してはこのつもりでした。

他力本願といえばそうなんだけど、
できるだけ多くの手の入った、バザール型のサイトにしたかったんだ。
名無しが集まって出来たということを、強調して大切にしたい。
その具体化したのが、
> 一番上の「2ちゃんねる生まれのWebサイト」
だと思ってください。

574 :1:02/09/06 19:56 ID:???
>>568
サイト冒頭の文体には、このスレッドの >>1 の雰囲気を残したかったので、
あえてああしたんだ。けど、あれはいずれ無くすものだし、
まあ気にしないでおいて。
一応言い添えておくと、僕は「だである」と「ですます」を併用して使うけど、
それぞれに機能の違い、意味合いを含めている。出来たら読み取って欲しい。

>>571
提案、Thanks!

575 :bloom:02/09/06 19:57 ID:qdhr/WxE

http://www.leverage.jp/bloom/start/

576 :1:02/09/06 20:11 ID:???
書き忘れた。

>>358 氏はまだこのスレッドをご覧だろうか。
よければあなたの書いてくれたものを、
草案1としてサイトに掲載したい。

あなたの一歩が、実際サイト制作の具体的な一歩でした。
大切に思って、きちんと手元においています。

577 :Name_Not_Found:02/09/06 20:27 ID:???
>>573
文法の話となるときりが無くなってしまうけど、全角空白字下げはいらないのでは?
text-indent の対応は問題ないし、 CSS に任せるのがいいと思います。
ttp://www.zspc.com/documents/css2/index.html#text

あともうひとつ、これも文法の話題なのであんまり拘っても、とは思いますが、
サイト構築の大枠の流れ、の流れ図は ol で列挙するだけでもいいのではないかな? と。
非視覚系 UA や表示域の狭い UA のことを想像してそう思ったので。

578 :1:02/09/06 20:53 ID:???
>>577
全角空白字下げは、多分インデント関連なんだろうなとは思ってました。
で、その意図がはっきりしたのですっぱり段落頭空白文字を削除しました。

大枠の流れはolを使おうとも思ったんだけど、
一応引用にとどめておこうと思ったのです。
意図は、元発言の空気をちょっと流入したいと思ったから。
引用元へのアンカーを作成しましたが、
あんまり意味がないようでしたら、olに変更します。

579 :Name_Not_Found:02/09/06 21:13 ID:???
CSS製作班は多いほうがいいね。代替StyleSheetとかいろいろあるし。

とりあえず、
body   {color:#000; background-color:#efe; }
p     {text-indent:1em; }
/* 藁 */

580 :Name_Not_Found:02/09/06 21:16 ID:???
blockqote     {
  background-color:silver;
  color:#000;
  margin:1em 3em;
  border:solid gray 1px;
}
/* CSSはひとつのタグは同じ行派だけど藁 */
/* 書式の間違いは許せよ、>>1&all */

581 :Name_Not_Found:02/09/06 21:30 ID:4d5MmJ0A
CSSはあまり使いすぎないほうがいいこともあるけどもね。

582 :Name_Not_Found:02/09/06 22:16 ID:???
>>580
タグっていうやつは素人。

583 :Name_Not_Found:02/09/06 22:19 ID:???
>>582

<p>タグはタグと言うよ。</p>

上のようなソースがあった場合、
・<p>を、「P要素の開始タグ」と呼ぶ。
・</p>を、「P要素の終了タグ」と呼ぶ。
・両方セットで、「P要素のタグ」と呼ぶ。
・全体(<p>タグはタグと言うよ。</p>)を、「P要素」と呼ぶ。
・タグにくくられた中身(タグはタグと言うよ。)を、「P要素の内容」と呼ぶ。

584 :Name_Not_Found:02/09/06 22:24 ID:???
>>583
CSSをpタグに適用するとは言わない。
CSSは要素に適用するもの。

585 :1:02/09/06 22:31 ID:???
>>582-584
悪いけど、スレ違いの議論は他所でやってくれんか。
タグ、要素うんぬんのいいたいことは分かるが、
ここではぜひ文意を汲んで欲しい。いいたいことは分かってたでしょ?
正直、揚げ足は勘弁してください。

CSSやなんかの、本題にかかわらない話に関しては、
サイトの方にBBSを設置する心積もりでいます。
もう少し文書が集まってきたら、動き出しましょう。
それまでは、こんなCSSを適応させたいぞ、という願望を、
めらめらと煮えたぎらせておいてください。僕も楽しみです。

586 :Name_Not_Found:02/09/06 22:51 ID:???
目次について
> 2. このましいaccesskeyとは
> 3. 開設者のためのaccesskey:設置について
> 4. 閲覧者のためのaccesskey:操作について

現時点での目次案は、上のようになってますが、
実際のUAでaccesskeyが押されたときの挙動が分からないと、
「どのようなaccesskeyが好ましいのか?」と語ることができないと思います。
ので、「閲覧者のためのaccesskey:操作について」は、
はじめの方に移動させて、

2. 閲覧者のためのaccesskey:操作について
3. このましいaccesskeyとは
4. 開設者のためのaccesskey:設置について

このようにした方がいいのではないでしょうか?

CSS3について
> 3-2. CSS3におけるaccesskey

現在のCSSの実装状況を考えると(まだCSS3はDraftですし)、
これは不要だと思ってみたり…

587 :1:02/09/06 23:23 ID:???
>>586
確かに、設置についてよりも操作についての項目が
先にくるほうが自然ですね。まず操作や実際例があって、
設置へと展開していったほうが、accesskeyを知らない人にも
優しいサイトになりそう。
ちょっと、設置者の視点に立ちすぎてたきらいがあったかも。

さて、

> 2. 閲覧者のためのaccesskey:操作について
> 3. このましいaccesskeyとは
> 4. 開設者のためのaccesskey:設置について

とするのはよいとして、「5. accesskeyの実際」については
どうでしょう。
これは「5」の場所のままでいいかな。

アウトラインを見直しているうちに、

2. 閲覧者のためのaccesskey:操作について
3. accesskeyの実際
4. このましいaccesskeyとは
5. 開設者のためのaccesskey:設置について

こんなふうにも思ったんだけど、どんなもんでしょう。
あるいは、「accesskeyの実際」は
「閲覧者のためのaccesskey:操作について」の
下位項目にするという考えがあってもよいかも知れない。
「accesskeyの実際」は、操作に関するものですから。

588 :1:02/09/06 23:23 ID:???
>>586

> 現在のCSSの実装状況を考えると(まだCSS3はDraftですし)、
> これは不要だと思ってみたり…

サイトの進捗状況によっては、
CSS3が現実的な技術になっていたりするかも知れないという
ちょっと恐ろしいことを思ったり思わなかったり……

この項目にとりかかる時点で対処しましょう。
その時に状況が整ってなかったら、
コラムとして挿入するにとどめるというのも手です。
将来的にはこうなるかも知れないよ、というくらいのニュアンスで。

589 :Name_Not_Found:02/09/06 23:27 ID:???
「みんなのサイト」って考え方はわかるんだがcopyrightやauthorが
"the accesskey's thread on the BBS 2ch"なのはどうかと思う。

「みんなで作っていく」というのはあくまで>>1の運営方針。
>>1がサイトを管理・運営しているというのを明確にするべき。

590 :Name_Not_Found:02/09/06 23:42 ID:???
>「accesskeyの実際」は、操作に関するものですから。
この項目にキーバインドのダブりの話も含めるなら
詳細情報として後にまわした方がいいと思うけど。

591 :1:02/09/07 00:14 ID:???
>>589
copyrightは"the accesskey's thread on the BBS 2ch"の方がいいと思うんだけど。
というのは、ここに皆が書き込んだものをあのサイトに載せるわけです。
その文章の著作権者というのは、あくまでその書き込んだ個人なのであって、
僕じゃないんですよ。だから、僕以外の文章を載せるつもりである以上、
copyrightはこのスレッドであるとしたい。

一応参考記事を
http://www.zdnet.co.jp/news/bursts/0204/15/13.html

どうだろう。
あのサイトが集合著作物となるだろうことを考えると、
著作権者としてはこのスレッド以外にはないと思うんだ。

これについては、たくさんの意見が欲しいです。
ちょっとスレ違いぎみな感じもして、あれだけど。

>>1がサイトを管理・運営しているというのを明確にするべき。

これに関してはうなずける部分も多い。なんらかのかたちで反映させましょう。
おそらくサイト作成への経緯を作るなかで、明確にさせるつもり。
authorとは別にdirectorみたいのはなかったっけ?
いい方法がないか、考えてみます。

592 :1:02/09/07 00:14 ID:???
>>590
>> 「accesskeyの実際」
> この項目にキーバインドのダブりの話も含めるなら
> 詳細情報として後にまわした方がいいと思うけど。

より詳しい情報を提供するのなら、操作と分離させた方が、
紛らわしくなく、かつ「6. 今後の課題と展望」へと繋げやすくなる。
そういう点であの位置に「実際」が来るのは自然なんだけど、
内容がちょっと少ないから。
もうちょっと膨らむなら、あの位置が妥当とみますか。

593 : :02/09/07 02:18 ID:???
>accesskey
そんなもん知らん。i-modeだけで十分

594 :Name_Not_Found:02/09/07 11:55 ID:???
>>593
無知を晒すのが流行ってるんですか?

595 :Name_Not_Found:02/09/07 17:34 ID:???
大抵の不思議HTML入門本には
「iモード専用拡張タグ」accesskey=数字
としか書いてありませぬ。

596 :Name_Not_Found:02/09/07 22:05 ID:???
マターリ語らう。

なんか人が少なくなってない?

597 :1:02/09/07 22:45 ID:???
>>596
まあ、ほら、僕がのろのろしてましたから、
そりゃ今まで支えてくれていた人も逃げるというものです。
時機を逸したね、正直なところ。
でも、遅くともきちんとやるべきことをやりたいとは、思ってますよ。

> マターリ語らう。

ありがとう。

598 :Name_Not_Found:02/09/07 22:55 ID:???
他力本願過ぎる

599 :Name_Not_Found:02/09/07 23:14 ID:???
禿げ胴意

600 :Name_Not_Found:02/09/07 23:26 ID:???
>>500以下の古いレスの話題でなんだけど、
仕様書を見回してもaccesskeyに同一の指定があった場合とかの話が全然無い。
今まで単に仕様を決めた人たちの落ち度だと思っていたんだけど、
むしろこれはMozillaとかの方が間違いのような気がして来た。

便宜的に付けられた「キーボードショートカット」なんて説明だとか、
iモードがボタン一つでリンク先に飛ぶとかいった先鞭を付けちゃったんで
そう言う先入観が広まってしまったのかも。
(逆にそれを見越してJSkyがdirectkeyを作ったんならそれはそれですごい事)

もし、仕様書を決めた人達がaccesskey同士が重なっても構わないような
ユーザーインターフェイスを前提としていたなら、
仕様書が重なりについて何も書かないのは当たり前だし、
そうすると実はIEの方がaccesskeyの実装としては正しいんじゃないのか?

601 :Name_Not_Found:02/09/07 23:40 ID:???
1さん常体と敬体混ぜないでよ
そんなに感情表してどうしたいというのか

602 :Name_Not_Found:02/09/08 09:50 ID:???
たまには呼び込みage

603 :Name_Not_Found:02/09/08 10:39 ID:???
>>1
単発質問スレは禁止です。

604 :Name_Not_Found:02/09/08 10:46 ID:???
マターリ語らう。

605 :Name_Not_Found:02/09/08 11:03 ID:???
IE6.0
ファイル(F)
編集(F)
お気に入り(A)
ツール(T)
ヘルプ(H)
URL欄(D)
Mozilla
File(F)
Edit(E)
View(V)
Go(G)
Bookmarks(B)
Tools(T)
Window(W)
Help(H)
Opera(日本語)
ファイル(F)
編集(E)
表示(V)
移動(N)
ブックマーク(B)
メール(M)
ニュース(S)
ウインドウ(W)
ヘルプ(H)
戻る(Z)
進む(X)
Windowsでおおまかに調べてこれだけ。Netscapeはインスコが面倒なのでやらなかったです。
残ってるキーは CIJKLOPQRUY と、数字ぽ

606 :605:02/09/08 11:34 ID:???
あと、他ブラウザのコンポーネントを使ったタブブラウザ
ファイル(F)など重複は避けます

Sleipnir
セキュリティ(C)
プロキシ(P)

BugBrowser
設定(P)
ごみ箱(R)

Donut,Donut Rapt,Donut R,,DonutP,Donut L,
なし

MDIBrowser
オプション(O)

MoonBrowser
なし

タブブラウザ多過ぎです。。。IJKLQUYと数字

607 :Name_Not_Found:02/09/08 14:45 ID:???
>>605-606
残りがIJKLQUYと数字か……
キーボードを限定すればIJKLを十字キーの様に扱えなくもないか?

608 :Name_Not_Found:02/09/08 15:06 ID:???
記号は駄目ですか?376あたりでhelp="?"の議論があったようだけど。

609 :Name_Not_Found:02/09/08 15:31 ID:???
Netscape,BlueBrowser,Ntex,TaBrowser,ぶら。,GLU,fub,Lunascape,Netcaptor
なし

Janus
Webリスト(L)

IJKQUYと数字
これだけ多くのブラウザのことを考えるとaccesskeyは絞られますね。。。
>>607
Lが消えますた わらい

610 :607:02/09/08 15:59 ID:???
>>609
なんの、それならUIJKで斜め十字だっ!(w
しかしここまで来るとコンテンツの名前やrelの頭文字のaccesskeyは
ほぼ無理だな。

>>608
記号は確かキーボードによってShift挿下とかの制限が多くて、
UAがキーバインドにShiftを使ったりするとダブってしまうから
避けた方がいい、てのが>>1タンの方針ぽい。

611 :Name_Not_Found:02/09/08 19:57 ID:???
> Lが消えますた わらい

なんか筒井康隆の『残像に口紅を』を思い出すなあ。
スレ違いスマソ。

612 :Name_Not_Found:02/09/08 20:41 ID:???
それほどブラウザがあると(&n)が多いからaccsesskeyに指定できる幅が制限されるな。

UAによってaccesskeyは [Alt]+accesskeyとか[Ctrl]+とかいろいろあるので
その辺も考慮してほしい。

613 :Name_Not_Found:02/09/08 20:41 ID:???
なんだそりゃ

614 :1:02/09/09 21:15 ID:???
>>600
仕様書では必要最低限しか説明されてないから、
もちろん言い切れないことの方が多いんだけれども、
同じaccesskeyが同一文書中で複数の要素にふられていた場合は、
Windows版IEのような挙動をすることが望ましいのは確かですね。
WindowsのUAの多くはフォーカスのみ型の挙動を示すけれど、
Macintoshのものはほとんどが問答無用ジャンプ型。

このあたりの挙動がまちまちなために、
Windows版IEの実装を活かすようなaccesskeyは、
正直設定しにくくなってしまう。
ちょっと、惜しいですね。

>>605-607 >>609 >>612
まとめてくれてありがとう。
「UA別デフォルトキーバインド一覧[資料]」として、
サイトの方にも公開しています。
http://accesskey.aiiro.net/defaultkeys.html

しかし、これだけ重複するキーがあると、
デフォルトキーバインドにぶつからないaccesskeyというのは、
かなりアクロバチックなものになってしまいそうな気が……

加えて、アウトラインをちょっとだけ変更しました。
こちらは、>>586 >>590 を反映させています。

615 :1:02/09/09 21:15 ID:???
>>608 >>610
記号に関しては、UAによってはキーバインドが繁雑になり、
また、もしこれを使えないUAが出てくればややこしいから、
使わないほうが無難かもな、と。
僕の考えるのはその程度のことです。

全部のUA、全部の記号について調べたわけじゃないから言い切れないけど、
おそらく大丈夫だとは思ってるんですよ。


直に余裕ができてきたら、
アウトライン1-1. 「accesskeyの役割」にとりかかってみます。
余裕のある人や我こそはと思う人は、是非参加お願いします。
それと、資料用の発言インデックスを作成したいんだけど、
これはもうちょっと待ってください。
もうちょっとすると余裕ができると思うから。

616 :Name_Not_Found:02/09/09 22:30 ID:???
>>605のOperaについてですが、Alt + Pで設定ダイアログが開きますので
(他のブラウザでも既にPは使われていますが)一応PもOperaではアウトかと思われます。

それとOperaをMDIモードで使用している時は、Alt + -(ハイフン)で
フォーカスを当てているMDIのウィンドウに対して「閉じる」「最大化」「最小化」などの
(通常のアプリケーションでAlt + Spaceとしたときと同じ)ドロップダウンリストが現れてくれます。
なので、記号については、MDIモードのOperaでは"-"(ハイフン)は予約されています。

以上はOpera 6.xx for Winについて当てはまる事です。
Linux版, Mac版のOperaについては多少異なる所が有るかも知れません。


617 :605:02/09/10 18:09 ID:???
1さん。揚げ足取って申し訳ない
使われていないキーの欄にLが入っていますが
Webリスト(L)に使われています。

末将ごとき若輩のまとめた私物なんぞをWebサイトに乗せていただけて光栄です。

618 :1:02/09/10 19:08 ID:???
>>616
ありがとう。資料にPと-(ハイフン)を追加しておきました。
僕はMacintoshユーザなので、このあたりの情報は非常に助かります。

>>617 (605)
いやいや、揚げ足じゃないよ。立派な指摘です。
助かりました、ありがとう。

しかし、上でさんざLが消えたとあって、しかも読んでたのに、
忘れてしまうとは不甲斐ない。人の話きかなあかん。
ちょっと反省です。

僕の方の予定は、次の三連休で過去ログを読んで、
ちょっとずつでもいいからまとめていきたい。
インデックスができたら、過去ログを読みやすくなるので、
話も多分しやすくなる。僕も続きを多分書きやすくなる。

619 :Name_Not_Found:02/09/11 01:25 ID:???
accesskeyの対応表(?)みたいなの見つけてきました。
http://www.inter-cool.net/~phantasm/wdzone/lab/htmlakey.html
いかがでしょ?ちと遅かった?

620 :1:02/09/11 20:18 ID:???
>>619
いや、遅いなんてことないですよ。
紹介してくださったサイト、わかりやすくてとてもよいです。
でも、読んであらためて思うaccesskeyに使える範囲の狭さ……
こういう状況下で、うまくaccesskeyをさばくのは、
ちょっと困難。
とりあえず、アイデアを絞ってみます。

621 :Name_Not_Found:02/09/12 03:08 ID:???
ふと思ったんですけど、大量にリンクが有るページってどうすれば良いんでしょ?
例えば、リンク集のページなんかだと、ヘタしたら100以上もある訳じゃないですか?
それにも全部アクセスキーをつけるのは無理ですよね…
タブインデックスで我慢するのかな?

で、
[P]rev・[N]ext・[I]ndex・[L]ink・[M]ailなど基幹となる要素にはアルファベットを
細かいリンクには数字を使う方向で行けば少しはなんとかなるかな?と思うんですが…
100個もリンクが有ったら無理ですけどね(^^;;
ガイシュツかな?(^^;;

622 :Name_Not_Found:02/09/12 10:47 ID:???
>>621
リンク集の個々のリンクにアクセスキーが振ってあっても
あまり利便性は増さないだろうと思います。
頻繁に使うリンクだからこそショートカットキーが便利、なのだと思うので。
快適なキーナビゲーションという面で言えば
普通にページ内リンクなどを利用して
ページ内を楽に移動できるようになっていれば、それでいいんじゃないでしょうか。

623 :Name_Not_Found:02/09/12 16:29 ID:???
Improving accessibility with accesskey in HTML forms and links
[http://www.cs.tut.fi/~jkorpela/forms/accesskey.html]
いくつかの例。

あと、携帯のサイトとかは 0 を「戻る」に割り当ててる例が多いみたいだ。
ブラウザのキーバインドと被るって問題を考えると、
テンキー(数字)ってのが一番現実的なのかもしれんと思う。
(こんな意見は前に出てた気がするけど)

624 :Name_Not_Found:02/09/12 17:18 ID:???
>>623
これを和訳するだけでも相当いい資料になりそうな……

625 :Name_Not_Found:02/09/13 19:47 ID:???
ちょっとしたことだけど、DonutRaptは
F E V A T W Hで IE6より VW が多いよ。

IE6は
F E V A T H で資料にはVが抜けていたような気が。

何れもWinXP環境です。

626 :Name_Not_Found:02/09/14 12:02 ID:2GOn57rl
◆このスレッドのまとめ
http://accesskey.aiiro.net/

◆現在このスレッドで行われていること
まとめサイト の製作 (>>1さん)
まとめサイト のCSS製作 (手の空いている人)
accesskeyの割り振りについて考える (ALL)

627 :Name_Not_Found:02/09/14 12:03 ID:2GOn57rl
書き込みの無いときの保守は 3 日に 1 回でokかな。

628 :Name_Not_Found:02/09/14 13:20 ID:???
>>626-627
そんなのは暗黙のうちにわかりきってる事
自治厨ウザイ 芯でくれ

629 :Name_Not_Found:02/09/14 14:45 ID:???
自治厨の使い方がちげえよ

630 :Name_Not_Found:02/09/14 14:59 ID:???
>>629
標準語使え

>書き込みの無いときの保守は 3 日に 1 回でokかな。
これが自治厨でなくてなんだよ

631 :Name_Not_Found:02/09/14 15:31 ID:???
>>1さん的には
「新規呼び込みも保守ageも適当な量だけしてください」
って感じなので別にいいと思われ。

632 :1:02/09/15 22:31 ID:???
http://accesskey.aiiro.net/ 、更新しました。

このスレッド初期のレスをトピックごとに分けたページを作りました。
続きは、明日に行います。

サイトアウトライン案に一項目追加しました。
「4-2. accesskeyを見えるようにする工夫」が追加項目です。

>>652 氏の指摘をうけ、
「UA別デフォルトキーバインド一覧[資料]」を更新しました。

トップページが繁雑になってきたので、
いくつかの項目を独立したページに移行しました。
それに伴い、ページをディレクトリごとにまとめています。

633 :1:02/09/15 22:31 ID:???
>>621-622

これにはいろいろな意見があって、
olで表示される数字をaccesskeyとして割り当てるという人もかつていました。
けど僕の考えは、>>622 氏の、
> 頻繁に使うリンクだからこそショートカットキーが便利、なのだと思う
に近いです。

ある程度固定的なサイト内ナビゲーションはaccesskeyで、
そうでないものはtabindexというように、
性質によって使い分けるのが便利そうかな、という感じです。

>>623-634
ありがとう、こういうまとまったものもあるんですね。
まだざっとしか見てないんだけど、
このスレッドで話し合っていたことのほとんどは網羅してる。
今度、時間を見つけてじっくり読んでみます。

翻訳は、余裕があればやりたいけど、それ以前にここのサイトかな。
並行して翻訳できればいいけど、意外と文章がたくさんだから、
読むとなると大変そう。将来的の予定、かな?

>>627-631
あまり暑くなっちゃいやですよ。
age、sage、保守に関しては、
それを必要と思ったときに必要と思った人が、
自由にしてくれていいと思うよ。
あんまりなにかに縛られるというのも変だし、
このあたりはゆったりと構えていきましょう。

634 :Name_Not_Found:02/09/16 22:58 ID:???
>>623訳してみてる。
長いし自分にはクローズの分からん所もあるけど、
出来たら>>1タンに送ってみる。

635 :1:02/09/16 23:08 ID:???
>>634
> 訳してみてる。
これは力強いお言葉、いたみいります。
送ってくれるということは、それまでに僕の方で、
メールアドレスを用意しておいたほうがいいのでしょうか。
必要ならば、サイトの方に公開できるアドレスを作成します。

それと、僕の方でも少しずつでも読みはじめてみますね。
得られるものは多そうです。英語の勉強にもなるし。

636 :Name_Not_Found:02/09/19 21:55 ID:???
できたらサイトだけでなく
このスレにも報告してね。

637 :Name_Not_Found:02/09/21 19:41 ID:???
>僕の一番愛しているレス
にワロタ

638 :Name_Not_Found:02/09/21 19:45 ID:???
>>630
ちげえよ脳障害

639 :Name_Not_Found:02/09/21 19:48 ID:???
あまり暑くなっちゃいやですよ。

640 : ◆/Re6aTC. :02/09/21 21:04 ID:???
css がないようなので、作ってみた。これではまだイクナイなので、
足すなり改造するなりしてくだちい。いらなかったら、放置してね。

http://webcafe.zive.net/~css/access.css

641 :Name_Not_Found:02/09/21 21:50 ID:???
>>640
イイ!んじゃない?
オレも代替作ってみようかなぁ。


642 :Name_Not_Found:02/09/21 22:28 ID:Zhrqhb/n
一度マウスが壊れてキーボードだけでやってたんですけど、
accesskeyは必要ないと思う。
かえって設定してるとブラウザのツールバーのショートカットキーが消されてちょいうざい。
だからtabindexだけ設定してます。

643 :Name_Not_Found:02/09/21 22:37 ID:???
>1さん、>642への反論よろしく。

644 :Name_Not_Found:02/09/21 22:51 ID:???
tabindex使うにしても今のブラウザってtab押すと
問答無用でページの一番上から順番にリンクへのフォーカスを移すから(・A・)イクナイ
tabキーを押した時は画面の一番上からフォーカスして欲しい。
手許にある電子辞書がそんな感じなんだけど。

645 :Name_Not_Found:02/09/21 22:54 ID:???
>>644
ふつうのアプリはそうだから正しい意見だと思うよ。

646 :Name_Not_Found:02/09/21 22:58 ID:???
たびんでっくすってなんですか?


647 :1ではないが:02/09/21 23:32 ID:???
>>642
マウスを直せ。

648 :1:02/09/21 23:32 ID:???
■スタイルシートのこと
>>640
スタイルシートを設定してみました。
なかなかわかりやすくなっていい感じでありますが、
ページ上下にあるナビゲーションには、
適当にclassを割り当てないとちょっと見難いね。
今度、適当に追加してみます。

>>641
よろしく。

ところで、前述のナビゲーション以外にも、
こんなところにはこんなclassやidをつけて欲しいというところがあったら、
いってください。
それで結果的に、機能別のclassが出来てきたら、
それはそれで有用なことだと思います。

■accesskeyのこと
>>642
うん、マウスが使えないでキーボードのみでブラウズとなると、
accesskeyは邪魔に感じるでしょうね。僕もそう感じると思います。
これはもうUAの仕様に関することだからどうもこうもないけど、
正直僕としては、恨むよ、こういう仕様にした人、って感じです。

サイトのアウトライン案に、
 6-2-2. 機能キーのカスタマイズ
というのを盛り込んでるけど、実際これらは問題と思ってます。
>>515 でもいわれているように、
UA制作者の方でなにか対策して欲しいところです。

>>643
ごめん、反論にならんかった。

649 :1:02/09/21 23:33 ID:???
■tabindexのこと
>>644
うん、この挙動に関しては、
tabindexのUA製作者への希望要望として、
サイトに盛り込みましょうか。
多分このあたりも、あまり注目されてなかったところだと思います。
気付かせてくれてありがとう。

>>646
僕もよく、思わず「たびんでっくす」って読んじゃうことあるよ。

■その他
>>639
そう、あまり暑くなっちゃいやですよ。
もう九月も終わりなのに、なんでこんなに暑いんでしょう。
しんどいです。ていうか、しくじったなあってずっと思ってました。

>>637
サンキュー!

650 :Name_Not_Found:02/09/22 00:14 ID:???
>>647
>>642の文をもう一度よく見ようね。

651 :Name_Not_Found:02/09/22 01:18 ID:EYr8YMf6
■ナビーゲーションのマークウプのこと
>>648
classやidより以前に、pでマークウプしているのが気になります。
おそらく今後コンテンツが増えるに従って、この部分に項目が増えていくのが
予想されるわけですから、リストとしてマーク付けしておくほうがいいんじゃないかと思うわけです。

<ul class="navi">
<li>ホーム</li>
</ul>

くらいを提案しておきます。


652 :Name_Not_Found:02/09/22 08:58 ID:???
>>651
同意。リストにはなっていないが(内容がひとつだから)、
CSSを作る上では便利。

ul.navi {display:inline;}

653 :Name_Not_Found:02/09/22 11:56 ID:kNLv90iC
>>1さん!
ちょっとダサいかもしれんけど、代替スタイルシート作ったので
うぷろだ お願いします。

654 :Name_Not_Found:02/09/22 12:17 ID:???
スタイルシートって大きなものじゃないからメールでいいんじゃないの?
>1さんのメールアドレス知らないけど。

655 :Name_Not_Found:02/09/22 12:41 ID:???
http://accesskey.aiiro.net/observations/points.html

>>n / >>nnは リストだと思う…。

これは別に問題ないのでおいておいて、

CSSどこにうぷしよう。
ちょっと探してくる。

656 :1:02/09/22 14:09 ID:???
ナビゲーションの項目は、やっぱリストでしょうか。
Strictに考えるとリストなんだろうなとは思ってたんですけど、
そうすると
ul.navi {display:inline;}
の効かない環境、CSSに対応しない環境では、
縦長になっちゃうんですよね(項目が増えた場合は特に)。
なので暫定的にpにしています。
なぜpかは追及しないでください、意味、意図、理由がないからです。
ちょっと考えさせてください。

メールアドレス作りました。
accesskey1@yahoo.co.jp

657 :Name_Not_Found:02/09/22 14:23 ID:???
マークアップは意味付けです
意味が無いなら書くな

658 :Name_Not_Found:02/09/22 15:01 ID:???
>>1はbodyには本文以外不要とか言ってる人だからねえ。
linkが提供されてればナビゲーションなんか無意味とか思ってるんじゃないの?

659 :Name_Not_Found:02/09/22 15:34 ID:???
>>657

>暫定的にpにしています。

660 :Name_Not_Found:02/09/22 15:39 ID:???
>>658
誰に話してるの?

661 :Name_Not_Found:02/09/22 15:58 ID:???
>>652
.navi li {display:inline;)


662 :Name_Not_Found:02/09/22 19:41 ID:???
p(段落) は頭に インデントをしても意味の通じるものにつけるべきじゃないか?

divとか「意味のない」要素があるんだから、さぁ。

663 :Name_Not_Found:02/09/22 20:42 ID:???
stricterには末節のブロック要素をdivにするのを嫌がる人がいるからね。
インライン要素とブロック要素を混在させるのが嫌って理由だと思うけど。

664 :309:02/09/26 01:41 ID:???
保守しまふ

665 :664:02/09/26 01:43 ID:???
すまんです。309ってのは何処かのクッキーだ(^^;;

666 :Age2ch:02/09/28 13:09 ID:???
保守


667 :Name_Not_Found:02/09/28 14:13 ID:???
訳していて出てきたんだけど、
このスレで話題になった事がないなと思ったので載せる。


>悪い事に、ブラウザの「標準の」Altキーアサインを定めるのは
>ユーザインターフェイスの言語に依存するため不可能です。
>例えば、IE 4.0のフィンランド語版ではAlt-Fは無効にされ
>代わりにAlt-T(フィンランド語で「ファイル」を表すTiedostoから)で
>ファイルメニューを開きます。


668 :Name_Not_Found:02/09/28 14:13 ID:???
>その上、アクセスキーアサインは他の技術と一緒になっても壊れます。
>例えば、もしIEをIBM Home Page Readerと一緒に使っていて
>且つ文書がaccesskey="l"の指定された要素を含んでいた場合、
>Alt-Lはアクセスキーとしてではなく
>Home Page Readerのコマンド("links reading mode")として働きます。
>キーボードキーアサインはまたOSレベルの設定にも頻繁に影響されます。
>この問題は詳細な文書Guidelines for Keyboard User Interface Designで
>解説されています。
>そしてWindowsプラットフォームの中でのバリエーションは
>World Wide Webの中でのバリエーションの一部に過ぎない事を
>覚えておく必要があります。

669 :Name_Not_Found:02/09/28 14:14 ID:???
Guidelines for Keyboard User Interface Design
ttp://msdn.microsoft.com/library/?url=/library/en-us/dnacc/html/ATG_KeyboardShortcuts.asp?frame=true

"links reading mode"って日本語版の呼び名を知らないんで誰か教えてクラハイ。

それにしても訳せば訳すほど「accesskeyイラネーヨ(欝凹↓」ってなる。
最初に「Alt+accesskeyで行ってみよう」なんて言い出した奴を
小一時間じゃ足りないから丸一日問いつめたい。

670 :634:02/09/28 14:16 ID:???
あっ、ワタクシ>>667-669=634だす

671 :1:02/09/28 22:10 ID:???
>>670 (634)
ありがとう。僕の方では時間がとれなくて、全然進んでない。
すごく助かります。

確かに上記の、さまざまなもの(言語や追加機能等)に対する
メタキーとしてAltが使われている問題というのは深刻です。
本当に、なんでaccesskeyのメタキーとしてAltを使おうと思ったんだろう。

"links reading mode"は「リンク読みモード」と読むようです。
-----引用始め
同じ行に複数のリンクがあり、現在のリンクを確認しにくいのですが。

タブキーでのリンク移動では現在のリンクを確認できませんが、リンク読み
モード Alt + L では現在のリンクを確認できます。モード切替がわずらわ
しい場合は、テンキー操作をお使いください。テンキーを使用するには、設
定メニューのキーボード設定で、「テンキーを使用する」チェックボックス
をチェックします。このチェックを入れた場合、テンキーがついていないノー
ト型パソコンではかならず外付けのテンキーを接続してください。
-----引用終わり
http://www-6.ibm.com/jp/accessibility/soft/hpr-faq004.html#p35

それと、読み上げソフトのキー操作をまとめたページも見つけました。
http://www.city.sanda.hyogo.jp/mansyon/no3/3-305/sr.html

しかし、フィンランド語はさすがに盲点でした。読めも書けもしません……
日本語ページだけならさほど問題にはなりにくいでしょうけど、
英語ページを作っている人にとっては、関わる可能性が多くなることでしょう。
またホームページリーダーについても…… 厳しいですねえ……

672 :1:02/09/28 22:12 ID:???
> "links reading mode"は「リンク読みモード」と読むようです。

読むようですじゃなくて、訳されているようですだよ……
駄目だなー。

673 :Name_Not_Found:02/09/29 10:05 ID:???
もう一度スタイルシートを送ってみる。

674 :Name_Not_Found:02/09/29 20:26 ID:???
Mac OS XのことえりはControl+数字で特定辞書を使った
確定後変換が出来るみたいでデフォルトでは1と2が使われている。
(1〜9をカスタマイズして割り当てられる)
IEではアクセスキーよりもそっちが優先されるみたい。
キー配列/インプットメソッドがUSとかの時は無問題。

ついでにMac OS Xブラウザのaccesskey対応状況を調べたら
IEとiCab以外全滅だった……MozillaもNetscape7も
てっきり対応しているもんだとばかり思ってたのに ⊃Д`)


なんか見つけたんで相互リンク。
http://rappeler.cside.to/Memo/aceskey.html

675 :Name_Not_Found:02/09/29 21:02 ID:???
手動挿入の広告なんかはTab押してもフォーカスがあわないようにしたいんだけど
IEはTabindex="0"としてもフォーカスがあっちゃうんだよね
Tabindex="999999999"位にしとけばフォーカスは合わないんだけど なんだか間抜け

676 :Name_Not_Found:02/09/29 22:49 ID:???
http://www.asahi-net.or.jp/~bd9y-ktu/html4rec_f/interact/forms.html#tabbing-navigation

この属性で、現在の文書でのタブ序列上の文書の位置を設定します。この値は、0から32767の間の数値でなければなりません。ブラウザなどの表示代行手段は、ゼロは無視すべきです。


677 :Name_Not_Found:02/09/30 16:29 ID:???
早速、代替スタイルシートつけられているね。
どんどん増えたらいいねぇ。

678 :Name_Not_Found:02/09/30 20:03 ID:???
>>555

679 :Name_Not_Found:02/09/30 21:17 ID:???
CSSでアクセスキーを右側に表示したらいいと思うんだけど。

mozillaのように。

680 :Name_Not_Found:02/09/30 21:20 ID:???
あと、しばらくは大丈夫だけども、一応ログを100単位でHTML化して
おいておいても良いかと。

681 :Name_Not_Found:02/10/01 16:15 ID:???
accesskeyについて試してみました。

win2k IE6 SP1
a                         対応(フォーカス)
area                     対応(フォーカス)
button                  対応(フォーカス)
input[type="text"]     対応
input[type="button"]    対応(フォーカス)
input[type="radio"]    対応(フォーカス)
input[type="submit"]    対応(フォーカス)
input[type="reset"]    対応(フォーカス)
label(for属性による明示的な関係)   対応
label(黙示的な関係)                  未対応
legend                    対応(この要素より後、最初にあるフォーム部品にフォーカス? それがラヂオボタンの場合、選択されたフォーム部品にフォーカス?)
textarea                   対応

682 :Name_Not_Found:02/10/02 15:28 ID:???
http://accesskey.aiiro.net/
たまに浮上。

683 :Name_Not_Found:02/10/03 19:14 ID:???
1さんBBSでも置いてけれ

684 : ◆ydoqYAnhhM :02/10/03 19:23 ID:???
8桁トリップキター!

685 : ◆SxCGIh1pXc :02/10/03 22:09 ID:???
10桁か…。でもコレって一バイト増えただけなんだよねw
いつからだろう?

大分前の計画だったんだけども

686 :Name_Not_Found:02/10/05 21:49 ID:???
なんだか、サイトの構成がよく分からんのだけど。
閲覧者向けのページと管理者(?)向けのページを
ちゃんと分けた方がいいんでないの?
資料なんかは現時点でも十分有用なんだし。

687 :1:02/10/07 00:51 ID:???
このところ忙しくって全然作業できない。
それが申し訳ないので、
>>680 氏の提案を受けて、過去ログをHTML化しました。
現在は600発言までをHTML化しています。
繋がらないリンクもありますが、将来的にデッドリンクは消えますので、
今は大目に見てください。

それと、>>681 氏の実験、
近々サイトの方に資料として出したいと思っています。
それと一緒に、accesskey実験用ページも作ろうと思っています。

>>686
構成の分かりにくさについては、申し訳ない。
トップページを閲覧者向けのに変えて、
制作用と分けようと思っています。

>>683
BBSは前向きに考えます。
借りているところの推奨のCGIがあるのですが、
残念ながら正しくHTMLを吐くものはないみたいで、
ちょっと二の足を踏んでいたのです。
可能なら、StrictなBBSが使えないか、
交渉してみようと思っています。

ごめんね。もうじき、忙しさから抜けると思うから。

688 :Name_Not_Found:02/10/07 02:00 ID:???
>>683
このスレの存在意義は…? ( ´Д⊂

689 :1:02/10/07 07:53 ID:???
>>688
多分、accesskey等の話題から離れた、
CSSとかサイト構成とかについて、
話すためのBBSだと思いますよ。

このスレでそれらを話そうとすると、
やっぱりちょっとスレ違いに思えるから、
安心して話せる場を欲したはるんだと思います。

690 :Name_Not_Found:02/10/07 19:56 ID:???
>>687
>可能なら、StrictなBBSが使えないか、
>交渉してみようと思っています。
StrictなBBSは http://say.vis.ne.jp/script/picobbs/とか。
W3C信者とか言われそうだけど 俺もStrict好きだぽ

691 :Name_Not_Found:02/10/09 19:22 ID:3TUxI84E
ほっしゅ

692 :Name_Not_Found:02/10/10 14:09 ID:???
まだ全部は読んでないけどこんな良スレがあったとは。今まさに歴史が作られようと
している。

693 :1:02/10/10 20:11 ID:???
>>692
> 今まさに歴史が作られようと
> している。

これは、言い過ぎです……

694 :Name_Not_Found:02/10/12 23:41 ID:???
今日は何の日〜毎日が記念日〜(の、使用上の注意のページ)
http://nannohi.jp/notice/

アクセスキー使ってるところをたまたま見つけました。
>↑目次(h) 使用上の注意(w) 情報の見方(u) リンク(l) 掲示板(g) 今日日日記(更新情報)(d)
なんですが、winのIE6という環境では(u)(l)(g)しか機能せず。

695 :Name_Not_Found:02/10/13 16:10 ID:???
>>694
機能するでしょ
全部使えたよ。環境同じ

696 :694:02/10/13 17:56 ID:???
すみません、IE6じゃなくてIEのエンジンを使ったDonutPでした。
でもIEで試しても(w)だけは機能せず。キーバインディング変更ソフト入れてるから
どこかでバッティングしてるのかな。

697 :Name_Not_Found:02/10/13 19:42 ID:???
>>696
Pは駄目だね。あとSleipnirも駄目(こっちは全滅
LunascapeとMDIは(d)だけ駄目。アドレスバーをフォーカスしてしまう。

逆にIEだと、(d)があるとアドレスバーをフォーカスできない。

タブブラウザはどれもキーバインド好きにいじれるから困りもんです

698 :Name_Not_Found:02/10/13 21:06 ID:???
donutRaptもですた。
IE自体では試していないからきづかんかったw

なるほどねぇ。

699 :Name_Not_Found:02/10/16 19:05 ID:???
たまにはhttp://accesskey.aiiro.net/

↓↓↓↓↓ 700get おめ ↓↓↓↓↓

700 :Name_Not_Found:02/10/17 00:41 ID:???
「みんなのサイト」にBBSが出来てるよ。

701 :1:02/10/19 01:41 ID:???
>>700
Thanx!

700氏のおっしゃる通り、
http://accesskey.aiiro.net/
にBBSを設置しました。
基本的には、accesskeyとかtabindexとかから外れて、
でもこの話題やサイトには関係しているぞというような話をするためのもの、
なんだと思っています。

最近動きを止めていることに関しては、申し訳ないです。
明日土日に、601-700を過去のスレッドとしてHTML化し、
サイトの整理を行えればよいなという感じでいます。
状況によっては先延ばしになるので、確約できないのも申し訳ないです。

>>694-698
IEのエンジンを使うタブブラウザにおいては、
accesskeyの利用が困難になるケースがあるのですね。
僕はMacintoshユーザで、しかもマイナーブラウザ(iCab)使いなので、
このへんの状況がよくわからない。
なので、このレポートはありがたいです。

ところでこういうのは、
やっぱりaccesskey設定側で配慮すべきなのかな?
もちろん僕は配慮すべきだと思ってるんだけど、
でもあまりに不自由になりすぎる環境というのは、
環境そのものが改善されるべきなんじゃないかとも思うことがあるのです。

以前に、いろいろな環境のデフォルトキーバインドを調べてもらいました。
で、それで分かったことといえば、かぶってないキーがほとんどないこと。
こういう状況下で、分かりやすく覚えやすいaccesskeyって
設定できるのだろうか? というのが僕のちょっとした疑問です。

702 :Name_Not_Found:02/10/19 01:57 ID:???
タブブラウザに関しては、作者をうまく言いくるめれば対応(IEと同じ挙動)は不可能では
ないと思う。
ブラウザ側でアクセスキーに使うモディファイヤキーを変更できればいいのだけど。
Alt+winとかならほぼ間違いなくかぶらないと思うけどな。

703 :Name_Not_Found:02/10/19 08:17 ID:???
winキーってMacはどうするの?

704 :Name_Not_Found:02/10/19 08:32 ID:???
>>703
>>702はたぶん例えで言ってるから
まぁ人それぞれで変えればいいんじゃない?

705 :702:02/10/19 08:51 ID:???
マックは元々衝突しないんじゃなかったっけ?

706 :Name_Not_Found:02/10/19 09:08 ID:???
わけがわからんよ 何が衝突しないのさ?

707 :Name_Not_Found:02/10/19 09:22 ID:???
アクセスキーのモディファイヤと、ブラウザのキーバインドが。
winの「Alt+ホニャララ」はかぶりまくってIJKQUY数字 しか残らない。


708 :Name_Not_Found:02/10/19 09:33 ID:???
>>707
がいしゅつ

709 :707:02/10/19 09:37 ID:???
>708
707は706への返信です。流れ読めよ。

710 :708じゃないけど:02/10/19 10:46 ID:???
>>709
流れからしたらどっちかっていうと
「Macではアクセスキーとその他の既定のキーバインドが衝突しない」
って書いてある方がわかりやすいんじゃないかな。
漏れも >>707 はただの呟きレスだと思ってた。

まあ取り敢えずまたーりしる。

711 :Name_Not_Found:02/10/20 04:50 ID:???
かなり初歩的な話題となってしまいますが、
テーブルで固めたフォームを作った時 tabindex を利用しました。
見た目重視で、画像なんかもたっぷり使ってあるテーブルです。
セルの連結を多用すると、タブでの移動が上から順番にならなかったので。
マークアップ言語をマークアップ以外のこと(見栄え)に利用しているくせに
tabindex の機能に救われたのは妙な感じです。

#このスレとても役立ちます。ただいま accesskey を既存サイトに組み込み中。

712 :Name_Not_Found:02/10/20 14:36 ID:???
気にして見てると案外Accesskey使ってるところもありますね。
http://www.interq.or.jp/jupiter/philsci/iw-html-01/sitemap.html
ここでは以下のキーが使われています
>IW front (U) | Prev page (J) | Next page (K) | Next section (L) | Map (M)

>キーの割り当て方は、実際に使っていただければ理由がはっきりすると思います。
>英語の頭文字に割り当てる方法は合理的じゃない(同じ頭文字の言葉が重複した
>場合に対処できない)し、使いづらい(日本人が英単語の頭文字を連想させられる
>いわれはないし、"previous" の意味を誰でも知っていると考えるのは傲慢です)
>ので、現行のようなゲーム風の割り当てとしています。

こんな感じでキーはまとまってた方がナビゲートは楽ですね。Qwerty以外の配列に
してる人には関係ないですが。

713 :Name_Not_Found:02/10/23 19:37 ID:7Rg1ObsE
ちょっと下がりすぎ

714 :Name_Not_Found:02/10/24 11:21 ID:???
今日、mozillaのType Ahead Findの機能を使ってみて
ビクーリしたよ。
あれがあればアクセスキーなんていらないじゃん。


715 :Name_Not_Found:02/10/24 15:35 ID:???
>>714
日本語のとこだと不便だけどね。

716 :Name_Not_Found:02/10/24 18:41 ID:???
でも、日本語のサイトだってナビ部分に限れば、
どうせ、

「掲示板(B)」

とか書くんだからそう不便でないんじゃないかな。


717 :Name_Not_Found:02/10/24 22:22 ID:???
CSSで制御することもあるから・・・

718 :Name_Not_Found:02/10/25 09:53 ID:???
>>717
それだとアクセシビリティ的にいかがなものかと。


719 :Name_Not_Found:02/10/25 19:45 ID:???
>>718
でもうちは contentで表示してるからなぁ…。
対応したUAは少ないけど。

なんか見た目を制御してるだけに見えるのです。
印刷したときにはアクセスキーなんて必要ないし。

720 :Name_Not_Found:02/10/25 21:32 ID:???
>>719
print用のcssで、アクセスキーの表示を消せばいいのでわ?


721 :Name_Not_Found:02/10/26 15:29 ID:???
>>720
screen,tvなどだけ表示にしています。

722 :Name_Not_Found:02/10/30 17:28 ID:???
age

723 :Name_Not_Found:02/10/30 17:45 ID:???
ごめん、ちょっと質問させて。
↓のサイトでは、IEでもリンク脇にアクセスキーが表示されるんだけど、
ソースにはキーを記述してないんだよ。これ、どうやってるの?
http://www5d.biglobe.ne.jp/~quia/

724 :Name_Not_Found:02/10/30 17:56 ID:???
>>723
スレ違い。DOMを使ってるの。

725 :Name_Not_Found:02/10/30 18:09 ID:???
>>724
関係ないが、お前、結構いい香具師だな(藁
そんなにスレ違いじゃない気もするが。

726 :Name_Not_Found:02/10/30 19:27 ID:???
でもJavaScriptをOFFにしていると
CSSが適用されないのはまずい.

JavaScriptで代替スタイルシートとか使ったり
アクセスキーを表示するのには、賛成だが.

727 :723:02/10/30 20:32 ID:???
>>724
ありがとう。DOMはよく知らないのでこれから調べてきます。

728 :Name_Not_Found:02/10/31 10:02 ID:???
>>726
>でもJavaScriptをOFFにしていると
>CSSが適用されないのはまずい.

そうか?
しょせんスタイルなんて付加要素だよ。おまけ。
逆にもしスタイルが適用されないとまずいのだとしたら
そんなHTMLを書くことに問題がある。

729 :Name_Not_Found:02/10/31 11:35 ID:???
>>728 そうだ。そうだ。


730 :Name_Not_Found:02/10/31 21:02 ID:???
でもJavaScriptOFFでもスタイルシートくらいゴルァ!
とも思うんだよな。

結局、信者的なw strictHTMLを賭けと。

731 :Name_Not_Found:02/10/31 21:11 ID:???
テキストブラウザで見たときに「まったく意味がわからない」サイトって
いや〜ん。

732 :Name_Not_Found:02/11/01 11:06 ID:???
まあ、それでちょっと寂しいって言うんなら noscript で link でも入れれれ

733 :Name_Not_Found:02/11/01 12:20 ID:???
>>732
DTD をいじらないと文法違反だが

734 :Name_Not_Found:02/11/06 18:43 ID:???
保守

735 :Name_Not_Found:02/11/09 11:31 ID:???


736 :Name_Not_Found:02/11/13 02:50 ID:???


737 :Name_Not_Found:02/11/13 12:33 ID:???
(´・ω・`)!?

738 :1:02/11/13 12:43 ID:???
ごめん、最近仕事およびその他身辺のことが、
ばかみたいに忙しくて、時間が取れません。
もうちょっと待ってくれといいながら、それが長くなり過ぎるのも悪いと思いながら、
もうちょっと待って下さい。

時間が取れたら、アウトラインの二つめの項目、
「2. 閲覧者のためのaccesskey:操作について」
に取りかかりたいと思っているのですが……

739 :Name_Not_Found:02/11/13 17:27 ID:???
>>1
がんがれ!

740 :Name_Not_Found:02/11/15 16:32 ID:???
Opera 7 β が link 要素に対応しましたね
NEXT : Shift+X
PREV : Shiuft+Z
などなど。
…今、手元にOpera7無いので違うかもしれないけどそんな感じだった

741 :Name_Not_Found:02/11/18 22:51 ID:???
ヽ(´∀`)ノ 

742 :Name_Not_Found:02/11/19 09:06 ID:???
Opera 7 beta for WIndowsについて。
・tabindexの対応は申し分ないようです。

・accesskeyはデフォルトのキーバインドでは
 Shift + Esc を押した後に[accesskey]となっています。
 Shift + Escを押すと一瞬だけ「アクセスキーモード」になり、
 そこでアクセスキーを選択する、と云う感じなので、
 この結果、Opera 7 betaでは「キーが衝突する」と事態は避けられる様です。

 Shift + Escはちょっと押しにくいですが、これは
 Opera 7ではキーバインドのカスタマイズができますので
 適宜カスタマイズすることで解消される事と思われます。

但し、acccesskeyのバグ(機能しない)に関しては、
accesskeyを割り当てる要素の種類が幾つかあります。
a要素に関しては、どんなaccesskeyでも機能しますが、
その場合単に「フォーカスがリンクに当たるだけ」ではなくて
そのリンク先へジャンプしてしまいます。

纏めた文書が
http://dai.pekori.to/opera/o7/
に在りますので、よろしければ参考になさってください。

743 :Name_Not_Found:02/11/19 18:25 ID:???
JavaScriptでマウスジェスチャーによるナビゲーションってどうよ。

↑でtop、↓でbottom、←でstart、→↓でスクロールとか。

744 :Name_Not_Found:02/11/19 18:32 ID:???
なんでスクロールまでジェスチャーするんだよ アフォ?
釣り?

745 :Name_Not_Found:02/11/19 20:16 ID:???
↑↑↓↓←→←→BA で UA 最強装備希望。

746 :Name_Not_Found:02/11/20 07:20 ID:???
>>745
ゲームのコマンドかよ(w

747 :Name_Not_Found:02/11/20 10:48 ID:???
→(溜め)←左弱クリック
多用すると嫌われるね。

とりあえず 1 さんにゆとりが出来るまで流しとこう。

748 :Name_Not_Found:02/11/20 23:54 ID:???
>>745
最近だと自爆コマンドになってるんだよなぁ、それ(w

749 :Name_Not_Found:02/11/21 16:49 ID:???
しかし、Mozilla のマウスジェスチャー拡張は
本気でそういう操作を要求してくるから笑える。

↓↑→↓でホームを開くとか
←↓→↓←でソース表示とか。
アルファベット書かせてるだけなんだけどね。


750 :749:02/11/21 16:52 ID:???
>>744
Mozilla だと
→↓↑でスクロールアップ
→↑↓でスクロールダウンらしい。
200px スクロールするらしいけど・・・


751 :Name_Not_Found:02/11/22 20:08 ID:???
Accesskeyは Text か StyleSheet か Script かどうだろう。

752 :Name_Not_Found:02/11/22 21:43 ID:???
>>751


753 :Name_Not_Found:02/11/22 22:14 ID:???
Accesskey は
ソースにそのまま書くべきか、
スタイルシートで実現すべきか、
それともスクリプトを使って実現すべきなのか。

ってことか?

754 :Name_Not_Found:02/11/22 22:19 ID:???
>>753


755 :Name_Not_Found:02/11/22 22:23 ID:???
理想はスタイルシートかなぁ。
もっといえば、キーコンフィグ XML 的なのが開発されて
link で読めるようにするとかがいいなぁ。
ベタにドキュメントに書くより
分離していろんな視点から設定出来るようにしてほすい。
ユーザスタイルシートみたいなね。


756 :751:02/11/23 10:09 ID:???
>>753
そういう感じで。

(1) <a href="chapter2.html" accesskey="n" >Chapter2 <kbd>N</kbd></a>
(2) <a href="chapter2.html" accesskey="n">Chapter2</a> で
     CSSの a:after { content:ほげ } で表示
(3) <a href="chapter2.html" accesskey="n">Chapter2</a> で
     JavaScriptを利用して表示

のどれがイイんだろう、と。

757 :Name_Not_Found:02/11/23 10:15 ID:???
(2) がいいなと思ったんだけど
html と css で記述が別れるから
書換えのとき注意しなきゃいけないかもですね。
それ以前に after 擬似要素 IE で使えないってのもあるケド・・・

変に Strict であることに拘らないなら (1) でいいのでは。
(3) だと見れない UA もあるだろうし。


758 :751:02/11/23 10:46 ID:???
>>756に補足すると(念のため)
(2)および(3)は
accesskey属性の値をとってくる、と言うことです。
常にcontent:"N"などとするわけではない。

>>757
JavaScriptとCSSだとOFFになっていれば、役目が果たせないからねぇ。

759 :Name_Not_Found:02/11/23 22:38 ID:???
cssオフでも便利さが享受できるよう
htmlに直書きがいいと思う。
PDAとか、携帯とかまともにcssを理解しないUAでこそ
アクセスキーが威力を発揮する場面も多いと思うが。


760 :Name_Not_Found:02/11/23 23:20 ID:???
>>759
あの手の物と他の一般的な UA に同じソース食わせるのは
現実的じゃないような。

むしろ、ああいうのこそはやいこと CSS 読むようになってほしい。
メディアタイプで分けていろいろ display: none したーい。
でも全部ダウンロードするだろうから見た目よりお金かかって
評判悪くなる罠。

あと、携帯とか PDA だと
普通のキーボード付き端末と同じ accesskey でいいかどうか疑問。
やっぱ css 読んで media type で分けるのが理想。

761 :751:02/11/23 23:40 ID:???
過去レス読んでみたらチョト既出ぽい。スマソ。

>>205アクセスキーをリンクの右にCSSで表示する案について
>>252■accesskeyのこと
>>264■音声ブラウザに関する話題
>>290-291 link要素(Next,Prevなど)にaccesskeyをつけるScriptの話題
>>716以降数レス
で、折れ。

ループ気味。
#漏れがあったらスマソ

762 :Name_Not_Found:02/11/23 23:48 ID:???
過去スレ読んで、あらためて >>1 タンの好感度UP

>>761
まあ、いいんじゃない?
時間がたってから考えかたが変るってこともあるだろうし。
少なくとも accesskey は実装に左右されまくりだし。
規格としてもわりと早いうちにもっと強力な何かで置き換わりそうな気がするし。


763 :Name_Not_Found:02/11/24 09:59 ID:???
芋はaccesskeyをつけると自動的に
リンクの左に
[1]とかが出るんだよね?

それとも機種依存とか何かなの?

764 :AXS奇異 ◆F1Ocw6kog2 :02/11/24 12:21 ID:wOXPQW2U
>>763
出る。ついでにJスカも出る。がいしゅつかもしれんがiCabもでる。
携帯端末とのメディアミックス謎を考慮するならアクセスキィは
ローマ数字にしておきなさいってこった。

すべてがいしゅつかもしれんけど。

個人的な意見としては、アクセスキーを付けるということは使用頻度の
高いサイトナビなどのアンカー(など)だと思うからなので、
そいつをOLリストとして上から順に1,2,3...と設定するといいかも
しれない。こうすれば非CSS状況下でもさほど問題はなかろう。
若干携帯ブラウザではしつこくなるけども。

そして、実際にそうした作りのサイトの管理人の俺の意見としては
そのナビゲーションで嬉しい思いをしました、という読者様からの
お便りはまだ一通ももらってはいない。

ところで思ったのだが、『アクセスキー』なる異名を持つ癖に
該当アクセスキーを押しただけではジャンプしない(ものが多い)という
最近のヘタレUAが出回ってるというこの気狂いじみた現状は異常極まりない。

controlやaltキーとの組み合わせでだれがアクセスキーなぞ使うものか。
せいぜいMac ie5でのposition:fixed配置でマウスではジャンプできぬアンカーなどに
一部役立つだけだ。

と思います。


765 :Name_Not_Found:02/11/24 12:29 ID:???
> ところで思ったのだが、『アクセスキー』なる異名を持つ癖に
> 該当アクセスキーを押しただけではジャンプしない(ものが多い)という
> 最近のヘタレUAが出回ってるというこの気狂いじみた現状は異常極まりない。

最近のブラウザが フォーカスを当てるだけなのは、
直接移動すると困るからです。

もしも、ブラクラにアクセスキーFが当てられていて、
IEで[Alt]+[F]などとしたら悲惨なことになるわけ。

766 :Name_Not_Found:02/11/24 12:30 ID:???
ゴメソ、
accesskey="F"なら
[Alt]+[F]でフォーカスを当てるんじゃなくて
[F]でフォーカスを当てろ

という話だったのね、早計スマソ

767 :764:02/11/24 12:30 ID:wOXPQW2U
>>765
言われてみればもっともだ。撤回する。

768 :764:02/11/24 12:32 ID:???
いや、>>766の意見であった。
俺もその意見に賛同するよ。単発キーでフォーカス、いいね。

769 :1:02/11/24 15:38 ID:???
閲覧者のためのaccesskey:操作について

タイトル:未定

■アクセスキーを使おう(仮)
それでは、アクセスキーを使ってみましょう。
アクセスキーを使うには、そのページにアクセスキーを設定されている要素
がないといけません。例えば、ハイパーリンクや文字入力のためのフォーム、
ボタンにアクセスキーが設定されていると、マウスの助けを借りずに、キー
ボードでそれらを利用できるのです。
では、アクセスキーを利用する方法をまとめてみましょう。

■アクセスキーの利用
アクセスキーを利用する方法はブラウザによって違っていて、おおまかに三
種類に分けることができます。

 1. アクセスキーの文字だけをタイプする方法
 2. 特殊キーを押しながら、アクセスキー文字をタイプする方法
 3. 事前にアクセスキーモードに入ってから、アクセスキー文字をタイプ
する方法

おそらくは皆さんが多く利用されているだろう、マイクロソフト社の
Internet Explorerやネットスケープ社のNetscapeは、二番の「特殊キーを
押しながら、アクセスキー文字をタイプする」ことでアクセスキーを利用す
ることができます。
ですが、同じインターネットエクスプローラでも、WindowsではAltキーで、
MacintoshではControlキーを使うなど、環境によって少しずつやり方が違い
ます。それを以下にまとめてみました。

770 :1:02/11/24 15:39 ID:???
・1. アクセスキーの文字だけをタイプする方法のブラウザ
  iCab (Macintosh)

・2. 特殊キーを押しながら、アクセスキー文字をタイプする方法のブラウザ
  Altキーを押しながらアクセスキー文字をタイプするもの
    Internet Explorer (Windows)
    Netscape 6/7 (Windows)
    Opera 6以前 (Windows)
  Controlキーを押しながらアクセスキー文字をタイプするもの
    Internet Explorer (Macintosh)
    Netscape 6/7 (Macintosh)
    Opera 6以前 (Macintosh)

・3. 事前にアクセスキーモードに入ってから、アクセスキー文字をタイプ
する方法のブラウザ
  Opera 7

一番の方法、「アクセスキーの文字だけをタイプする」というのは、非常に
簡単です。アクセスキーに設定されている文字をタイプするだけで、アクセ
スキーを利用することができます。
三番の方法、「事前にアクセスキーモードに入る」必要があるものは、少し
ややこしい感じもありますが、やり方自体はさほど難しいものではありませ
ん。ShiftキーとEscキーを一緒に押した後に、アクセスキー文字をタイプす
る。これでアクセスキーを利用できます。

771 :1:02/11/24 15:39 ID:???
■アクセスキーの働き方
アクセスキーの働き方にもそれぞれ違いがあり、これは二種類に分けること
ができます。

 1. 選択するだけのもの
 2. クリックまでしてしまうもの

Windowsのブラウザの多くは、一番の「選択するだけ」で止まってしまいま
す。その要素を利用したいときは、あわせてEnterキーを押す必要があるの
で、面倒に感じるかも知れません。
Macintoshのブラウザの多くは、二番の「クリックまでして」しまうのがほ
とんどです。Enterを押さなくても即座に利用できるのは便利ですが、どこ
にリンクしているか、そのボタンがどういう効果があるのかを考える前に機
能が働いてしまうので、場合によっては――間違ってせっかく書いた掲示板
の書き込みを消しちゃった! など――困ったことになるかも知れません。

■まとめ
上記のように、アクセスキーを使うといいましても、ブラウザごとにちょっ
とした違い、くせのようなものがあります。ですが、どの方法もそれほど難
しいものではないので、ご自分の愛用されているブラウザの操作を覚えて、
いろいろ試してみてください。使い慣れると、いちいちマウスを動かさなく
て済むようになりますので、サイト内の移動がきっと楽になることでしょう。

772 :1:02/11/24 15:43 ID:???
お待たせしました。
ようやっとちょっと余裕ができたので、
「2. 閲覧者のためのaccesskey:操作について」
を書いてみました。

ですが、あくまでもこれは草稿でありますので、
叩き台として、皆でよりよいものに練り上げましょう。
特に、アクセスキーの発動、効果の分類や、
それぞれの例示の誤り、漏れなどがありましたら、
どしどし修正案を出してください。

また、対案となる別稿を提出できる方がいらっしゃったら、
それを提示していただけると、無上の喜びです。

773 :1:02/11/24 16:12 ID:???
まとめてレス。レスしきれないところもあるけど、
それはごめん。でも全部読んでます。

■CSSとかいろいろ
accesskeyの理想は、rel属性値に基づきCSSで設定、
表示もCSSまかせなんでしょうけど、
現実からいえばこれは無理。
携帯端末ユーザも主眼に入れるなら数字で、
PCユーザのみを対象にするならアルファベットも使って、
できるだけ広範囲のユーザを拾えるようにするしかないんでしょうね。

CSSでの表示ということをいえば、例えば、
<a href="*.html" accesskey="?">link text <span class="accesskey">[?]</span></a>
というのを、span.accesskey {display: none;}にするという
アイデア(>>720 氏)が、ちょっと目から鱗でした。
media="print", "aural"で非表示にするという用途が期待できます。

でも本当は、
a[accesskey]:after{content: "(" attr(accesskey) ")"}
が使えるようになるか、
完全にCSSでaccesskeyの制御をできるようになるのが
ベストなんですけどね。
将来に期待しましょう。次のような例もあります。

774 :1:02/11/24 16:13 ID:???
■Opera 7 β、link要素に対応!
Operaが動いてくれましたか。すごく嬉しいですね。
昨年十二月のメールが原因としても、そうでないとしても、
ある意味このスレッドにおける悲願が実現の運びになったわけです。
報われた感じだなあ。あとは、この動きが広がるだけです。

加えて、アクセスキーモード導入。あたかもこのスレッドを
読んでくださってるようではないですか。
カスタマイズ可能という点に関しても、すごく嬉しいですね。

>>742 氏のまとめてくださった文書も、
大変にわかりやすくてありがたいです。
将来的には、アクセスキーサイトにもこういったまとめと、
accesskey & tabindex等テストページを作りたいと思います。

775 :1:02/11/24 16:13 ID:???
■フォーカスオンリーと問答無用ヒット:二つの挙動
完全に安心できるサイトでは、問答無用ヒットが便利なんですよね。
でも、なんかの弾みでフォームがリセットされたりすることを考えると、
フォーカスだけの時点で止まってくれた方が安心です。
なので、僕はこれはユーザの方で使い分けられると嬉しいと思うんです。

例えば、
> [Alt]+[F]でフォーカスを当てるんじゃなくて
> [F]でフォーカスを当てろ

という話を発展させる形で、
Fだけならフォーカスオンリー、ヒットはしない。
Alt+Fでは問答無用ヒット型に変化。
みたいに働いて欲しい。

理想形は、Opera 7 βのようにモードを使って、
1. Shift+Esc:アクセスキーモードに移行、
2. Fのみで対象フォーカス、Shift+Fで問答無用ヒット、
こんなふうになって欲しいかな。

フォトアルバムみたいなのをみるときは、
問答無用ヒット型が便利なのですよ。
だから使い分けられるようになって欲しい。
加えて、フォーカスしたときには、
title属性値を表示してもらえるようになれば最高です。

■その他
>>747
ザンギでは近寄ることもできません……

776 :1:02/11/24 16:36 ID:???
伴い、サイト、http://accesskey.aiiro.net/
の方も更新しました。
草案の公開というだけの小更新ですが、
掲示板で見るより見やすいかも知れません、
それほどでもないかも知れません。

ところで、上記草案の鍵括弧を取り払って、
emにしてるんだけど、鍵括弧は残したほうがいいかな?
また、kbd要素なんていりますでしょうか?
あのHTMLではだめーっ、という意見ありましたら、
それもどしどし修正案を出してください。

777 :Name_Not_Found:02/11/24 18:03 ID:???
1さんよ
更新とか音沙汰ないのはわかるがaccesskeyの研究のために作られたサイトの
BBSで何故あんたの身の上話とアドバイスされにゃならんのだ?
あんな書き込みは期待してないよ

778 :1:02/11/24 18:07 ID:???
>>777
申し訳ない、あまりに煮詰まってしまっていたもんで、
なんだかよく分からなくなってるんだ、最近。
今後気をつけます。というか、日記書き込みは嫌われるよね。

779 :Name_Not_Found:02/11/24 18:56 ID:???
>>1さんへ
>>770の文中で「Opera6(Win)はアクセスキー対応している」との旨が記されていますが
これは誤りです。Opera6はaccesskey, tabindexともに対応していません。
対応したのはOpera7になってからです。
参考:http://www.opera.com/docs/specs/#html の"Other Issues"のところ

また、Mac版Opera6については分からないのですが、
Opera Softwareの公式文書を見る限りは、恐らくaccesskey, tabindexともに
サポートしていないと思われますので、今一度確認をお願いします。
(生憎僕はMacを試せる環境にないので確認できません)


780 :Name_Not_Found:02/11/24 21:25 ID:???
> 2. Fのみで対象フォーカス、Shift+Fで問答無用ヒット、
[Shift]+keyは (例えとして出ているとしても) だめだろ。
このスレでも出てきてたはずだけど
accesskey="?"にしたら/なのか?なのか判別できない。

かといって、現在のように
Alt だと ツールバーの(&x)が利用できないし
ctrlだと ショートカットキー(コピーなど)が使えない。

#もうこのスレも1年なのかぁ。
#当時から読んでたけど、なんかOpera7β、うれしいね。
# M$IE.NETになったらHTML4.01 CSS XMLにも完全対応してほしい。

781 :1:02/11/24 21:25 ID:???
>>779
ご指摘ありがとうございます。
http://accesskey.aiiro.net/drafts/usage_akey1.html
を一部修正しました。
Macintosh版の調査は、少し待ってください。

ところで、Opera 6 for LinuxはShift+accesskeyとのことなんですが、
だれか使ってみたことのあるという方、
もしくは詳しくご存じの方いらっしゃいませんでしょうか?

参考サイト
http://www.pugx3.com/bfi/html/help/accesskey.html

782 :Name_Not_Found:02/11/24 21:27 ID:???
あと、キーだけ直接だけだと
文書を読んでるときについ押してしまったときとか困るし。

いろいろ問題があるね。

783 :Name_Not_Found:02/11/24 21:31 ID:???
向こうの掲示板みたけど。
>>1さん、がんば!!
accesskeyサイトのほうはマターリしてください。

#やっぱ仕事が減るとつらいのはわかるわ。

784 :Name_Not_Found:02/11/24 21:36 ID:???
オレ mozilla 使ってんですけど

785 :Name_Not_Found:02/11/24 21:51 ID:???
Opera 6 Macはざっと試したけど対応していなさそう。

786 :1:02/11/24 21:52 ID:???
>>780
> [Shift]+keyは (例えとして出ているとしても) だめだろ。

そうだ、本当だ、駄目ですよ。酷い例を示してしまいました。

 ・アクセスキーフォーカスオンリーモード
 ・アクセスキーフォーカス&ヒットモード

の二つを作って、それぞれの発動キーバインドを変えればいいんだ。
キーバインドに関しては、今は考えなくてもいいですよね。

ところで、Shiftをメタキーにするのは問題というからには、
Opera 6 for LinuxのShift+accesskeyというのも、
違うかも知れないですね。
残念ながらうちのLinuxはGUIがまともに動かない低スペック機に
インストールされてるので、さすがに試せそうにありません。
未確認ということで、この情報に関してはdel要素を適応しておこうと思います。

>>782
そうです。何度か、BBSの書き込みを、
送信する前に誤って消したことがあります……
力作だったりするとショックが大きいので、
僕はResetにはaccesskeyを設定したくありません。

>>784
> オレ mozilla 使ってんですけど

九時過ぎの更新でMozilla、追加しました。
Mozillaが書いてないのは駄目だよ、ということですよね。

787 :1:02/11/24 21:55 ID:???
>>785
ありがとう。del要素のtitle属性変更して、
Opera 6 for Macを正式にリストから削除します。

>>783
ありがとう。頑張ります。
でも、このサイトの方もいいかげんにはしたくない。
ちょっとずつでも動きたいので、どうか暖かく見守ってやってください。

#でも、ああいう書き込みは、さすがにもうやめますね。
#戒めのために削除はしませんが、妙に感傷的でこっぱずかしい……

788 :784:02/11/24 22:25 ID:???
>>786 あんがと

789 :1:02/11/24 23:16 ID:???
>>788
いえ、こちらこそありがとう。
ご要望答えることができたのも嬉しいです。

790 :Name_Not_Found:02/11/24 23:38 ID:???
>>785
大丈夫だ。誰も使ってない。

791 :Name_Not_Found:02/11/25 08:30 ID:???
最近 >>1 さんが頑張ってるから
このスレに元気が戻ってきたなぁ。

792 :1:02/11/25 08:54 ID:???
Opera 6 for Macintosh、試してみました。
accesskey、使えますよ。
Shift+accesskeyです……
どなたか、Opera 6 for Windowsで
Shift+accesskeyを試してみて下さい。

793 :Name_Not_Found:02/11/25 09:18 ID:???
>>792
Opera 6.05 for Windows では使えません。

794 :1:02/11/25 09:26 ID:???
Opera 6.0β2続報
link要素は、

home
index
contents
search
glossary
help
next
prev
first
last
up
copyright
author

に対応。厳密にこのlinktypeのみを解する模様。
rel="start"やrel="end"は無視されている。
link要素のキーボード操作はできないみたい。

CSSに関しては、
a[accesskey]:after{content: "(" attr(accesskey) ")"}
を理解した。

accesskeyがShift+aceesskeyで動くというのは、
理解として不十分だった。
"?"や"!"、大文字アルファベットなど、
Shiftを必要とする文字がaccesskey属性値になってはじめて使えるようだ。
>>742 氏の作ってくれたテストページは、accesskey属性値が小文字アルファベットだから、
それらは働かなかった。しかし、"?"や"!"、"("、")"は働く。
どうやら、そういうことみたいです。ちょっと妙ですね。

795 :1:02/11/25 09:28 ID:???
>>793
確認、ありがとうございます。
多分、Macintosh版やLinux版のみの機能なのでしょう。
Windows版は先発するから、装備されなかったのかもしれませんね。

796 :793:02/11/25 09:57 ID:???
>>794
Navigationメニューに
Site navigationというのがあって
そこに、
Home Ctrl+Shift+Space
Search Ctrl+Shift+F
等があるから、
将来ではlink要素のキーボード操作は
サポートされる可能性があると思います。

797 :Name_Not_Found:02/11/25 16:48 ID:???
>>794
ひょっとして大文字だったらShift+keyで行けたって事?

しかしそれは入力モードにかなり依存している気もするけど。

798 :1:02/11/25 23:20 ID:???
本日のOpera 6 for Macintoshの調査の結果を、
サイト(http://accesskey.aiiro.net/)に反映させました。
たいそうなことじゃないんで、申し訳ないのですが……

>>796 (793)
Opera 7でのlink要素のキーボード操作は、
大いに期待できますね。
この流れからすると、Mac版やLinux版等にも、
同様の機能がサポートされることでしょう。

本当に嬉しいです。
IE、Mozillaが追随してくれるといいなあ。

>>797
> ひょっとして大文字だったらShift+keyで行けたって事?

そのとおりです。ただ指摘されてるように、
ちょいと難ありなんですよね。
すべてのAccesskeyが大文字という保証はないし、
現時点のやり方では(Shift+key)、
機能しないケースが多いでしょう。

でも、多分Opera 7リリースの暁には、
解決する問題だと思います。
気長に待ちたいと思います。

799 :Name_Not_Found:02/11/26 01:17 ID:???
>>794
ガイシュツかもしれませんが、アドレスバーにあるユーザースタイルシートボタンの横に▼印のボタンが付いています。
UserModeのときにこのボタンを押すとプリセットの代替スタイルシートの一覧が表示され、ここからAccessibility layoutを選択すると、リンクに設定されているアクセスキーを表示したりリンクが設定されている画像を強調表示したりします。
一応ブラウザ側でもこの機能を意識しているということでご報告。

800 :800:02/11/26 18:58 ID:???
800get !!

801 :Name_Not_Found:02/11/26 19:06 ID:???
>>799
はじめて知ったよ、thanx。

802 :Name_Not_Found:02/12/03 06:39 ID:???
そろそろ保守

803 :Name_Not_Found:02/12/04 19:39 ID:???
がんばれ

804 :Name_Not_Found:02/12/05 19:03 ID:???
age

805 :Name_Not_Found:02/12/11 17:05 ID:dSrlri/1
ageる時期かな

806 :Name_Not_Found:02/12/12 01:13 ID:qAhA49si
Opera 7 betaでのaccesskeyの実装状況 & テスト

http://dai.pekori.to/opera/o7/accesskey1.html

ってのを見つけたのでご報告します。
漏れ自身はN7.01使ってるんだけども一応。

807 :Name_Not_Found:02/12/12 22:03 ID:???
Amayaってどうなんだろう。
ver7まで出てるのに一度も使ったことが無いから分からん。

808 :Name_Not_Found:02/12/14 14:24 ID:???
使えばいいじゃn
ただなんだし

809 :Name_Not_Found:02/12/14 15:05 ID:???
たまには。http://accesskey.aiiro.net/

810 :Name_Not_Found:02/12/14 19:36 ID:???
むしろこのスレの意見を集約した
Link要素&Accesskey&Tabindexの標準ブラウザ「Ayaya」
を作ってしまったらどうか。

811 :Name_Not_Found:02/12/14 19:51 ID:???
IEコンポーネントに勝てるやつな、どうせなら。
        ↓
多くのタブブラウザなどに搭載
        ↓
XHTMLにも対応してるので信者も安心
        ↓
       ウマーーーーーーー

812 :Name_Not_Found:02/12/19 15:56 ID:???
呼び込みあげ。

813 :Name_Not_Found:02/12/21 12:48 ID:???
age

814 :Name_Not_Found:02/12/22 22:47 ID:0pPwUnwg
もう一年あげ

815 :Name_Not_Found:02/12/24 22:35 ID:???
hosyu

816 :Name_Not_Found:02/12/27 09:31 ID:???
あげ

817 :1:02/12/31 20:28 ID:???
標準ブラウザ、ayaya、作りますか?
僕には無理ですが、出来れば面白いかも。

# というか、ayayaって誰か、やっとわかりました。

818 :Name_Not_Found:02/12/31 21:02 ID:???
作れるの?

819 :Name_Not_Found:02/12/31 21:45 ID:???
本当に今度こそ2003年と同時に1000を迎えるスレ
http://choco.2ch.net/test/read.cgi/aasaloon/1041335418/
  |         |  |
  |         |  |_____
  |         |  | ̄ ̄ ̄ /|
  |         |  |   / /|
  |        /\ |  /|/|/|  ドッドッドッドッドッド!!
  |      /  / |// / /|
  |   /  / |_|/|/|/|/|     (´⌒(´⌒`)⌒`)
  |  /  /  |文|/ // /  (´⌒(´祭だ!!祭だ!!`)⌒`)
  |/  /.  _.| ̄|/|/|/    (´⌒(´∧ ∧⌒`)`)`)⌒`)
/|\/  / /  |/ /     (´⌒(´(,゚Д゚ )つ `)`)
/|    / /  /ヽ  (´⌒(´⌒  (´⌒( つ |〕 /⌒`)⌒`)
  |   | ̄|  | |ヽ/|  遅れるな!!   ( |  (⌒)`)⌒`)
  |   |  |/| |__|/.   ∧__∧ ⌒`)ド し'⌒^ミ `)⌒`)ォ
  |   |/|  |/  (´⌒(´( ´∀` )つ  ド  ∧__∧⌒`)
  |   |  |/    (´⌒(´( つ/] /    ォと( ・∀・ ) 突撃――!!
  |   |/        ( |  (⌒)`)  ォ ヽ[|⊂[] )`)
  |  /         (´ ´し'⌒^ミ `)`)ォ (⌒)  |
  |/                     .   ̄ (_)`)`)

820 :Name_Not_Found:03/01/01 13:39 ID:???
ブラウザは難しいよね。

つーか、音声ブラウザを作ったら、すごく売れそう。CSS完全対応なら…。

821 :Name_Not_Found:03/01/01 22:37 ID:???
有料じゃ誰も使わんな

822 :Name_Not_Found:03/01/03 17:58 ID:???
>>821 有料でも>>820みたいにしっかりしたものなら売れる。

823 :Name_Not_Found:03/01/03 18:39 ID:???
官庁や図書館、盲小学校なんかに複数ライセンス形式でまとめ売りすりゃあ
採算性のある商品だと思うぞ。

特にこの場合独自規格ではなく「公開された仕様に基づいた」と言うのも
売り文句として効果あると思うし。

824 :Name_Not_Found:03/01/04 21:44 ID:???
個人じゃブラウザなんてとんでも だけどな。

825 :Name_Not_Found:03/01/04 22:03 ID:vWE1QJ+L
半島の組織票に詰め寄られてます
http://live.2ch.net/test/read.cgi/festival/1039531056/926
CNNのアンケート
合衆国は北朝鮮と不可侵条約を締結するべきか?
Noに投票してください!

投票所:http://asia.cnn.com/
祭り会場:http://news2.2ch.net/test/read.cgi/liveplus/1041638621/

急募
    
     97氏のような天才プログラマー。

誰か御願いだ! NOに入れるツール、スクリプトを作ってくれ。

QUICK VOTEから投票できます。
クッキーを判定してるみたいです。
しかしTIMEみたいに、画像の番号まではやってません。

求む!英雄!

WE WANT YOU!

826 :Name_Not_Found:03/01/04 23:47 ID:???
スレ違い>>825

827 :質問:03/01/06 03:58 ID:???
rel属性って、a要素についてたらlink要素には必要ないですか?

828 :Name_Not_Found:03/01/06 05:27 ID:???
>>827
その a がなければ link にも rel を書く、っていう状況であれば
a の有無に関わらず link にも rel を書くべきかと。

でも、別に rel は無理して付ける必要はないと思うよ。
どっちかって言うと title は必ず書いて欲しいけど。
<link rel="hoge" href="hoge"/> みたいなやつを結構見掛けるんだけど、
これって <a href="hoge" rel="hoge"></a> ってのと大差ない。
<link title="hoge" href="hoge"/> なら特に問題ないんだけどね。

829 :Name_Not_Found:03/01/06 19:51 ID:???
rev="Made"やらrel="Index"やらにtitle付けられても
あんまり有用ではない気もするんだが。

830 :Name_Not_Found:03/01/06 20:05 ID:???
ス切リボ大活躍の予感。

831 :Name_Not_Found:03/01/06 22:03 ID:???
>>829
MozillaやIEもいろんな個人が機能拡張してlink要素に対応しているし、
その他UAやユーザーサイドのscriptによるので、なんともいえないのでは。
少なくとも書いといて損をすると言うことはほぼないだろうし。

仮にメジャーブラウザの初期状態しか相手にしないというならIEが
link非対応って事でlink自体があまり有用ではな(ry

832 :1:03/01/12 14:27 ID:???
ちょっと代替スタイルシートを作ってみました。

accesskey一覧をページ下のセンターに
置けばよかったかもと思いながら、
今後リスト内容が増えていけば、
やはりページ右にあったほうがいいのではと、
未だ迷っています。

一度、見てみてください。
http://accesskey.aiiro.net/
です。

833 :Name_Not_Found:03/01/12 23:26 ID:???
画像を使っているんですか。
JavaScriptあたりでaccesskey属性を拾えれば楽なんだけどなぁ。

乙。

834 :Name_Not_Found:03/01/13 11:47 ID:???
>>833
IE5やMozillaあたりなら拾えると思うけど?

835 :Name_Not_Found:03/01/14 08:06 ID:???

岡田克彦ファンクラブからのご案内です。ご高承のとおり、岡田克彦氏の卒業した早稲田大学政治経済学部
と、ひろゆきの卒業した中央大学文学部は比較にならないほど差があります。中央大学文学部のような
ヘボい大学に共通しているのは、文化水準が低いという事です。18歳から22歳をヘボい大学で過ごすという
ことは、感受性において致命傷と言えます。2ちゃんねらーの大半は岡田克彦氏に比べて、著しい低学歴で
頭が悪いだけでなく、感受性も愚鈍で腐っているという、取り返しのつかない状態なのです。
せめて、http://www.geocities.co.jp/MusicHall-Horn/1091/で、岡田氏の作品に触れましょう。


836 :1:03/01/21 00:03 ID:???
http://accesskey.aiiro.net/

accesskey一覧の画像が、mozillaではうまく表示できなかったのを、
ちょっと修正してみました。
じき余裕ができたら、文章も書いて行こうと思います。

よい提案、アイディア等あったら、よろしく。

837 :山崎渉:03/01/23 03:02 ID:???
(^^)

838 :Name_Not_Found:03/01/25 17:35 ID:1FjHs6gE
あげ

839 :Name_Not_Found:03/01/26 15:07 ID:???
正直言って何が変わったのかわからない…

840 :Name_Not_Found:03/01/26 17:02 ID:???
>>836
乙!

841 :Name_Not_Found:03/01/26 19:26 ID:???
>>839
Gecko エンジンのUAでStylesheetsの切り替えをしていると解る。

430 KB
■ このスレッドは過去ログ倉庫に格納されています

      .,,,jgg醴醴醴醴蠶g;;.、.'::゙':''.'ミ.(.(.(.(.(,(iji.iii,ii浴朋器謳醴醴醴醴醴醴醴醴醴醴雛|Ibi、
.:,,jag醴醴醴醴醴醴醴醴醴gg_ . `.' (.(.(.(IIII||瓰蘊槻醴醴醴醴醴醴醴醴醴醴醴雛部}l゚(' .
!}}|讃嬲醴醴醴醴醴醴醴醴醴魎g,,.    ``:゚ヌ惚謳醴醴醴醴醴醴醴醴醴醴靈雛部ケ''`
.'.^'゚(}照讃嬲醴醴醴醴醴醴醴醴醴籃j,.,,,,,g繪醴醴醴醴醴醴醴醴醴醴靈雛嫋笏i゚'.'
    '‘('゚(}}}}|讃讃讃雛讚嬲醴醴醴醴醴醴醴醴醴醴醴醴醴醴醴靈嬲韜抓l゚(゙'゜
        .゙'.''゚(}郊}}}}照孤讃讃雛雛醴嬲嬲嬲嬲醴嬲嬲嬲嬲雛讃部郊?゚(^`


こいつも来年死刑だな      **********************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************************-ト=/test/read.cgi/hp/1006224399/">★スマホ版★
掲示板に戻る 全部 前100 次100 最新50

read.cgi ver 05.04.00 2017/10/04 Walang Kapalit ★
FOX ★ DSO(Dynamic Shared Object)