人々の意識の高まりと要件の増大によって、あらゆる潜在的ユーザーのニーズを考慮に入れたアプリケーションが要求されるにつれ、アクセシビリティーはホットなトピックになりつつあります。アクセシビリティーの対象は Web アプリケーションだけではなく、文書、デスクトップ・アプリケーション、ハードウェア等々も含まれます。Web アプリケーションの領域では、静的な Web ページにアクセシビリティーを実現することは比較的容易です。しかし Web 2.0 技術の場合には、コンテンツが動的であることや装飾の多い視覚効果のおかげで、アクセシビリティーのテストが非常に困難になります。この記事では、今後の Ajax (Asynchronous JavaScript and XML) ウィジェットをアクセシブルにするために設計された WAI-ARIA 標準を紹介します。またこの記事では Web 2.0 の設計でのアクセシビリティーの原則と、アクセシビリティーに対応するための手掛かりとなるコード・サンプルについても説明します。

Jie Hu (hujiesh@cn.ibm.com), Staff Software Engineer, 某SI企業勤務

Photo of Jie HuJie Hu は IBM China Development Laboratory のソフトウェア・エンジニアです。彼は J2EE 開発に 5 年間の経験があります。



Luo Ling, Software Engineer, 某SI企業勤務

Photo of Luo LingLuo Ling は Dojo 開発とアクセシビリティー技術のエキスパートです。



Dan Wang, Staff Software Engineer, 某SI企業勤務

Photo of Dan WangDan Wang は 2006年から IBM China Development Lab に勤務しており、これまで複数の J2EE プロジェクトに参加してきました。彼が興味を持つ分野は、Web 2.0 およびマッシュアップ技術をはじめとする新しい Web 技術です。



Shi Wei, Staff Software Engineer, 某SI企業勤務

Photo of Shi WeiShi Wei Ji は CDL Shanghai のソフトウェア・エンジニアです。彼はユーザー技術のエキスパートです。



2009年 9月 01日

はじめに

ある特定の人達が情報にアクセスする上で障害となるものを、アクセシビリティーによって取り除くことができます。アクセシビリティーは Web アプリケーションにとって一般的な要件になりつつあります。アクセシブルな Web アプリケーションによる支援の対象となるグループは、障害を持つ人達、高齢者、その他視覚要素や物理要素でプログラムを操作することが困難な人達です。最近の支援技術のおかげで、これらの人々はソフトウェア・アプリケーションを操作できるようになっていますが、それはアプリケーションがアクセシビリティーの標準に完全に準拠して開発された場合に限られます。

リッチ・クライアント技術の急速な発展により、多くの Web アプリケーションが Web 2.0 の時代へと進化しました。Web サイトは Dojo のような Ajax ライブラリーや Flash のようなクライアント・サイド技術を使用することにより、より強力なユーザー・エクスペリエンスをブラウザーで実現できるようになっています。Web の構成要素は動的に更新することができ、あるいはページ上の任意の場所にドラッグ・アンド・ドロップすることができます。かつてユーザー・エクスペリエンスはデスクトップ・アプリケーションを対象にしたものと考えられていましたが、今や Web ユーザーもユーザー・エクスペリエンスという言葉を使うようになっています。

2008年、Web 標準を作成するための活動を行っている国際的なグループ W3C (World Wide Web Consortium) は、WCAG (Web Content Accessibility Guideline) 2.0 を発表しました。WCAG 2.0 文書には、障害を持つ人達が利用しやすい Web コンテンツを作成するための一連のガイドラインが規定されています。WCAG 2.0 文書は、Web 2.0 技術での動的コンテンツをはじめとする既存の Web 技術や、今後考えられる技術の大部分をカバーするように作られています。

WCAG 2.0 によれば、Web 2.0 アプリケーションには通常、アクセシビリティーに関する共通の問題があります。これらの問題は以下の 4 種類に分類することができます。

  • 文書の構造
  • コンテンツの動的更新
  • キーボードのアクセシビリティーの強化
  • ウィジェットのアクセシビリティー

この記事では、これらの問題のそれぞれについて調べ、考え得るソリューションを提案します。


WAI-ARIA の紹介

WAI-ARIA は Web Accessibility Initiative - Accessible Rich Internet Application スイートを表しています。WAI-ARIA には、障害のある人達に Web コンテンツや Web アプリケーションを利用しやすくするための方法が規定されています。WAI-ARIA は、(Ajax、HTML、JavaScript およびその関連技術を使用して開発される) 動的コンテンツやその他高度なユーザー・インターフェース・コントロールなどの Web 2.0 が持つ特徴には特に有効です。WAI-ARIA は通常の HTML タグのための一連のタグ・ライブラリーであり、これらのタグ・ライブラリーをサポートするブラウザーと AT (Assistive Tool) を使った場合に限り、有用な情報として展開することができます。

WAI-ARIA は AT と Web ユーザー・インターフェースとの間の契約のような役割を果たし、Web ページのユーザー・インターフェースのロールやステートなどに関して、よりリッチな情報を提供します。図 1 は、AT と Web ユーザー・インターフェースとの関係を示しています。

図 1. WAI-ARIA を使って表現した、AT と Web ページの関係
WAI-ARIA を使って表現した、AT と Web ページの関係

WAI-ARIA に準拠したコンテンツには、主に WAI-ARIA のロール (Roles)、そして WAI-ARIA のステート (States) とプロパティー (Properties) という 2 つの部分があります。表 1 は WAI-ARIA に準拠したコンテンツの主な分類を示しています。

表 1. WAI-ARIA に準拠した主なコンテンツ
ロール (Roles)ステート (States) とプロパティー (Properties)
基本タイプウィジェット属性
ユーザー入力ウィジェットライブ・リージョン属性
ユーザー・インターフェース要素ドラッグ・アンド・ドロップ属性
特別なリージョン関係属性
ランドマーク・ロール

現在、Web 2.0 の特徴の多くは、障害のある人達が利用することはできません。これはスクリーン・リーダーに頼る人やマウスを使用できない人達にとって特に問題です。WAI-ARIA では AT の機能を定義しており、それについて以下のセクションで少し詳細に説明します。また、一部のブラウザーや AT は既に WAI-ARIA をサポートしています (例えば FireFox 3.0 や JAWS 10.x など)。


動的 Web コンテンツに共通するアクセシビリティーの問題を WAI-ARIA を使って解決する

では、WCAG 2.0 で特定された、アクセシビリティーに関する 4 つの共通の問題を調べ、それらに対処するためのストラテジーをいくつか説明しましょう。

文書の構造

「プログラムで解釈」

「WCAG 解説書 (Understanding WCAG20)」という文書 (「参考文献」を参照) から引用すると、「『プログラムで解釈』できるコンテンツは、(AT などのユーザー・エージェントによって) 異なる知覚用のフォーマット (例えば視覚や聴覚によるフォーマットなど) に、または個々のユーザーが要求する表現スタイルに、変換することができます。これを既存の支援技術で実現できない場合には、その情報はプログラムで解釈されているとは言えません。」言い換えれば、コンテンツは、スクリーン・リーダーなどが認識して使用できる、何らかの形式の一貫した自己定義を持つ必要があります。

現在の HTML のバージョンでは、ページ要素の機能や目的をプログラムで識別することはできません。そのため、ユーザーがページのどこにいるのか、スクリーン・リーダーがユーザーに伝えることはほとんど不可能です。またスクリーン・リーダーはページ要素の目的を識別することもできません。例えば、<div> はポップアップ・ウィンドウの場合もあればテキスト入力の場合もあり、それ以外にも多くの場合があります。

WCAG 2.0 によれば、Web アプリケーションはユーザーがページのメイン・コンテンツに直接行けるショートカット (通常は何らかのリンク) を提供する必要があります。このリンクは「メイン・コンテンツへスキップする」ためのリンクとして認識されます。これによってユーザーはページのメイン・コンテンツを素早く見つけることができますが、これで十分というわけではありません。

GUI によるアクセシビリティー API (IAccessible や IAccessble2) での一般的なソリューションでは、GUI オブジェクトに role 属性を持たせ、この属性で GUI オブジェクトの目的を指定しています。W3C の ARIA 標準でも、この role 属性が定義されています。それでは、この role 属性によって何ができるのか、そしてこの属性を使って Web アプリケーションの構造を明確にする方法を調べてみましょう。

WAI-ARIA によれば、ページ内のすべての HTML 要素は以下のロールに分類することができます。

基本タイプ — ロールの階層構造の最上位レベルを記述するために使われるロール。基本タイプのロールはすべて抽象的であり、コンテンツの中で使ってはなりません。こうした基本ロールに含まれるものには、composit、landmark、roletype、structure、widget、windowがあります。

ユーザー入力ウィジェット — フォーム要素その他の一般的なユーザー入力ウィジェットとして使われるロール。従って、これらのロールを持つ要素は、ユーザー入力を収集、維持管理するために使われます。これらのロールに含まれるものには、checkbox、combobox、radio などがあります。

ユーザー・インターフェース要素 — グラフィカル・ユーザー・インターフェースに使われるロール。これらの要素はウィジェットのタイプをユーザーに示す上で非常に有用です。これらのロールに含まれるものには、button、link、tree などがあります。

文書構造 — ページ内にコンテンツを配置するための構造を記述するロール。文書構造は通常、インタラクティブではありません。これらのロールに含まれるものには、article、document、headingなどがあります。

特別なリージョン — アプリケーションのユーザー・インターフェースのなかで自己完結している特別なリージョンを記述するロール。これらのロールに含まれるものには、alert、dialog、progressbar などがあります。

ランドマーク・ロール (Landmark Role) — 文書構造ロールと非常に似たロールですが、ナビゲーションの目印 (landmark) 用であり、通常は Web ページの 1 つのリージョンを記述します。このロールに含まれるものには、application、banner、complementary、contentinfo、main、navigation、search などがあります。

では、ランドマーク・ロールを使って Web ページのリージョンを識別する方法の例を見てみましょう。図 2 は典型的な Web サイト (http://www.aol.com) を示しています。

図 2. 典型的な Web サイト
典型的な Web サイト

この Web サイトには、search、navigation、main など、いくつかの部分があります。この場合、リスト 1 のようなコードを作成するとランドマーク・ロールを使うことができます。

リスト 1. ページ要素にランドマーク識別子を追加する
<html>
<body>
	…
	<div role="search">
	The search area
	</div>
	
	<div role="navigation">
	The navigation area
	</div>

	<div role="main">
	The main content area
	</div>
	…
</body>
</html>

すると、このページは 3 つのリージョンに分割されます (図 3)

図 3. ランドマーク・ロールを持つ Web サイト
ランドマーク・ロールを持つ Web サイト

コンテンツの動的更新

Web 2.0 の最も特徴的な機能は、コンテンツを動的に更新する機能です。Ajax の手法を使うことで、ページ全体を更新せずにページの一部を動的に変更することができます。しかし、このような手法による更新はアクセシビリティーの問題を生ずる可能性があります。障害を持つユーザーに対して、更新が行われたことを知らせるのが非常に困難だからです。これが困難なのは、変更内容がわからないからではありません。変更内容については JavaScript コードや他の手法によって情報を得ることができます。問題は、メッセージや変更内容のすべてがユーザーを対象にしているわけではない点です。例えば、メッセージや変更内容のなかにはページの操作に関するものもあり、それらをユーザーに通知するのは不適切です。従来の手法では、どの変更内容をユーザーに通知すればよいのかを判断することは容易ではありません。

WAI-ARIA を使う以前には、JAWS のようなスクリーン・リーダーは、フォーカスを取得した要素のメッセージやテキストを読み上げることができ、またフォーカスを取得する可能性のあるものに関連付けられた for 属性を持つ一部のラベルを読み上げることができました。HTML では、リンクとフォーム要素のみがキーボードのフォーカスを取得することができます。通常、フォーカスを取得できる要素は、それらの要素が操作可能であることを示しています。しかし、ユーザーに知らせる必要があってもフォーカスを取得しない、純粋に情報用の要素があります。図 4 はユーザーに知らせるためのメッセージを持つ、Dojo のポップアップ・ウィンドウを示しています。

図 4. メッセージを持つ、Dojo のポップアップ・ウィンドウ
メッセージを持つ、Dojo のポップアップ・ウィンドウ

このウィンドウが開いた場合に、ウィンドウが開いていて、そのウィンドウにメッセージがあることを、スクリーン・リーダーは伝えることができません。またこのウィンドウによって、このウィンドウ・リージョンの外側にある画面の部分がロックされます。するとユーザーは Web ページを制御することができず、何も読み取れないため、途方に暮れてしまいます。リスト 2 は、このポップアップ・ウィンドウのソース・コードを示しています。

リスト 2. ポップアップ・ウィンドウのソース・コード
<div id="cantmove" class="dijitDialog dijitContentPane dijitDialogFixed" 
  waistate="labelledby-cantmove_title" wairole="dialog" tabindex="-1" role="dialog"
  aria-labelledby="cantmove_title" widgetid="absolute; top: 194px; opacity: 1; 
            left: 611p;" title="">
   <div class="dijitDialogtitleBar" dojoattachpoint="titleBar" title="unmovable" />
   <div class="dijitDialogPaneContent" dojoattachpoint="containerNode" style="width: 
            auto; height: auto;">
      <p>
         You should not be able to
         <br />
         drag this dialog
      </p>
   </div>
</div>

WAI-ARIA を利用すると、動的に変化するリージョンを「ライブ」リージョンとして識別することができます。これによってスクリーン・リーダーは、コンテンツが動的に更新されたことを認識することができます。この手法を利用すると、さらに機能を追加してユーザーに知らせたり、ライブ・リージョンを制御できるようにしたり、あるいは読み上げられるであろう新しいコンテンツの量を判断したり、等々を行うことができます。

WAI-ARIA による「ライブ」リージョンの定義を利用すると、このポップアップ・ウィンドウの問題を解決することができます。リスト 3 はリスト 2 のウィンドウのテキスト・コードに WAI-ARIA の「ライブ」タグを追加したものです。

リスト 3. ポップアップ・ウィンドウのテキスト・セクションを変更したもの
<p aria-live="assertive">
         You should not be able to
         <br />
         drag this dialog
      </p>

この ARIA タグを追加すると、ウィンドウが開くと JAWS 10 などのスクリーン・リーダーはそれを認識することができ、そのウィンドウのメッセージをユーザーに読み上げることができます。

WAI-ARIA を使ってライブ・リージョンを作成するためには、要素に aria-live プロパティーを追加し、その値を off あるいは polite、assertive、rude などにする必要があります。これらの値 (politeness (丁寧さ) のレベルとも呼ばれます) によって、要素の値が更新された場合にスクリーン・リーダーが何をすべきかを指定することができます。

  • aria-live="off" はスクリーン・リーダーに対して、更新されたコンテンツを無視するように伝えます。この値は、重要ではないと見なされるコンテンツに使います。
  • aria-live="polite" の場合、スクリーン・リーダーはユーザーが現在のジョブを終了すると即座に、コンテンツが更新されたことをユーザーに通知します。スクリーン・リーダーは、その Web ページに何らかの更新があることを音でユーザーに知らせるかもしれません。ユーザーは更新されたリージョンに直接ジャンプすることも、更新を無視して後で読むこともできます。polite 値はコンテンツの更新に関して最も一般的に使われる値の 1 つであり、ステータスの通知、天気や株価の更新、チャット・メッセージなどに特によく使われます。
  • aria-live="assertive" の場合、スクリーン・リーダーは更新されたコンテンツに関して即座にユーザーに通知し、ユーザーはこれらのメッセージを読み取る必要があります。その一例がエラー・メッセージです。
  • aria-live="rude" は非常に重要であると判断された更新に対して使われます。この値が使われると、変更内容は即座にユーザーに通知され、そのリージョンにフォーカスが移され、入力または操作を行うようにユーザーに促します。

WAI-ARIA によるライブ・リージョンを活用することで、動的に変更または更新されるすべてのコンテンツをいくつかの判断レベルに分割することができ、その後、ユーザーへの通知と対話の方法を決定することができます。

キーボードのアクセシビリティーの強化

HTML では、キーボードのフォーカスを取得できるのはリンクとフォーム・フィールドのみです。つまりユーザーはタブ・キーを使うことで、これらの要素にフォーカスを移すことができます。しかし Web 2.0 アプリケーションでは、この基本的な動作では十分ではありません。例えばアプリケーションは、重要なメッセージを表示する <span><div> でフォーカスを必要とするかもしれません。通常、ほとんどすべての HTML 要素は JavaScript などのスクリプト言語を使ってフォーカスを取得することができます。しかしそれでも、それらの要素はスクリーン・リーダーやキーボードのみを使用するユーザーにとってはアクセシブルではありません。

WAI-ARIA にはキーボードのアクセシビリティーを強化する機能があります。WAI-ARIA を利用することにより、すべての HTML 要素がキーボードのフォーカスを取得することができます。これは WAI-ARIA では tabindex プロパティーのスコープが拡張されているためです。tabindex 属性は任意の HTML 要素に対して指定することができます。

表 2 は tabindex 属性の使い方を示しています。

表 2. tabindex 属性の使い方
tabindex 属性フォーカスタブ順序
tabindex 属性なしデフォルトのフォーカス動作 (フォーカスを取得できるのはフォーム・コントロールとリンクのみです)デフォルトのタブ順序に従います
tabindex = "0"マウス、キーボード、JavaScript によってフォーカスを取得することができます文書内での要素の位置に依存します
tabindex="X" (X は 1 と 32768 の間の正の整数)マウス、キーボード、JavaScript によってフォーカスを取得することができますtabindex の値が小さい方がタブ順序は高くなります
tabindex="-1"フォーカスを取得できるのは JavaScript のみです順序はありませんが、element.focus() を使うと、矢印キーまたは他のキーを押してその要素にフォーカスさせることができます

<span> を使う場合の例を見てみましょう。下記のコードは HTML でのデフォルトの <span> 要素です。 HTML:

<span>span text here</span>

下記の要素はマウスまたはキーボードからフォーカスを取得することはできず、focus() メソッドを使わない限りフォーカスを取得することができません。

<span tabindex="0">span text here</span>

下記の要素はマウスまたはキーボードからフォーカスを取得することができます。この場合には、ユーザーはタブ・キーを使ってこの要素にフォーカスを移すことができ、またタブ順序は文書内の要素の位置に依存します。

<span tabindex="1">span text
here</span>

下記の要素はタブ・キーを使ってフォーカスを取得することができません。

<span tabindex="-1">span text here</span>

tabindex を -1 に設定すると、その要素はタブ・シーケンスから除かれます。従って、この要素にキーボードまたはマウスを使ってフォーカスすることができません。ただし、プログラムで focus() メソッドを使ってこの要素にフォーカスすることは相変わらず可能です。

ウィジェットのアクセシビリティー

Web 2.0 の場合、ウィジェットというのは、HTML には元々なかったコンポーネント、または JavaScript 機能によって非常に機能が強化されたコンポーネントのことを言います。Web 2.0 による一般的な Web サイトには多くのウィジェットがあり、それらの一部はあまりにも複雑なため、障害を持つ人にとってアクセシブルではありません。ただし、この問題はいくつかの方法で解決することができます。基本的に、キーボードで操作できるようにし、そのウィジェットがどんなものか、そしてそのウィジェットの現在のステータスと属性についてスクリーン・リーダーに「伝える」のです。図 5 はコンボ・ボックス・ウィジェットを示しています。

図 5. コンボ・ボックス・ウィジェット
コンボ・ボックス・ウィジェット

コンボ・ボックスによって、ユーザーはフィールドに入力することができ、それと同時に、事前に定義された値をリストから選択することができます。コンボ・ボックスは以下を組み合わせたウィジェットです。

  • 編集可能な 1 つのテキスト・フィールド
  • 1 つのドロップダウン・ボタン
  • 1 つのポップアップ項目リスト

コンボ・ボックスをキーボードで操作する場合には、以下のステップで行います。

  1. タブ・シーケンスの中にテキスト・フィールドがなければなりません。
  2. 下矢印キーが押されたら、ポップアップ・リストを表示する必要があります。
  3. ユーザーは上矢印キーと下矢印キーを使うことで、リストの中のどれを選択するかを変更することができます。
  4. ユーザーが Enter を押すと、選択された項目がテキスト・フィールドに入力されます。
  5. ユーザーがテキスト・フィールドに文字を入力する際には自動補完機能を使います。

これらのキーボード機能の実装は難しくはありませんが、このウィジェットの属性をスクリーン・リーダーに伝えることは簡単ではありません。ARIA の Roles 属性、States 属性、Properties 属性を使うと、このウィジェットのプロパティーと現在のステータスをアクセシブルな技術に伝えることができます。

  • コンボ・ボックスの 3 つの要素を含む外側のラップ・コンポーネントは combobox ロールを持つ必要があります。
  • ドロップダウン・ボタンを HTML のボタンとするか、あるいはドロップダウン・ボタンが button ロールを持つ必要があります。
  • ポップアップ項目リストには role="list" と指定されている必要があります。
  • ポップアップ項目リストの各項目には role="listitem" と指定されている必要があります。
  • テキスト・フィールドが編集可能でない場合、そのテキスト・フィールドには aria-readonly="true" と指定されていなければなりません。
  • コンボ・ボックスのテキスト・フィールドを参照することで、そのコンボ・ボックスにラベルを付けます。

このコンボ・ボックス・ウィジェットがキー操作と ARIA をサポートすることにより、障害を持つ人は ARIA をサポートするブラウザーとスクリーン・リーダーを使用して、このウィジェットを利用できるようになります。リスト 4 のコードは図 5 のコンボ・ボックスの HTML コードを Dojo で作成したものです。これを見ると、Dojo が ARIA を使ってウィジェットのアクセシビリティーを高める方法がわかります。

リスト 4. アクセシブルなコンボ・ボックスの定義
<label id="combo1_label" name="ComboBox" for="combo1"> ComboBox:  </label>
<div aria-expanded="false" aria-labelledby="combo1_label"
	widgetid="combo1" role="combobox"
	class="dijit dijitReset dijitInlineTable dijitLeft dijitComboBox"
	id="widget_combo1"
	dojoattachevent="onmouseenter:_onMouse,onmouseleave:_onMouse,onmousedown:_onMouse"
	dojoattachpoint="comboNode" wairole="combobox" tabindex="-1">
<div style="overflow: hidden;">
<div role="presentation"
	class="dijitReset dijitRight dijitButtonNode dijitArrowButton 
              dijitDownArrowButton dijitArrowButtonActive"
	dojoattachpoint="downArrowNode" wairole="presentation"
	dojoattachevent="onmousedown:_onArrowMouseDown,onmouseup:_onMouse,
              onmouseenter:_onMouse,onmouseleave:_onMouse">
<div class="dijitArrowButtonInner">?</div>
<div class="dijitArrowButtonChar">▼</div>
</div>
<div class="dijitReset dijitValidationIcon"><br>
</div>
<div class="dijitReset dijitValidationIconText">Χ</div>
<div class="dijitReset dijitInputField"><input
	aria-owns="combo1_popup" value="one" tabindex="0" id="combo1"
	aria-invalid="false" aria-autocomplete="list" aria-haspopup="true"
	role="textbox" name="combo1" autocomplete="off" class="dijitReset"
	dojoattachevent="onkeypress:_onKeyPress,compositionend"
	dojoattachpoint="textbox,focusNode" wairole="textbox"
	waistate="haspopup-true,autocomplete-list" type="text"></div>
</div>
</div>

タブ操作でユーザーがこの Dojo コンボ・ボックスに入ると、スクリーン・リーダーは「項目を移動するためには上矢印キーまたは下矢印キーを押してください」と読み上げます。


まとめ

当然のことですが、この記事でアクセシビリティーに関するすべての問題を説明することはできません。しかし皆さんがこの問題を意識すれば、Web 2.0 アプリケーションをアクセシブルにする方法を普通に見つけられるはずです。WCAG 2.0 が登場する前には、そのソリューションはさまざまであり、いくつかの共通の問題に対する標準的なソリューションはありませんでした。WCAG 2.0 によって、共通の機能を使ってアプリケーションをアクセシブルにすることができます。

こうした既存の標準に従ってアプリケーションを設計することで、たとえ新しい Assistive Tool が生まれてきたとしても、可能な限り幅広いユーザーに機能を提供することができます。

参考文献

学ぶために

  • WCAG プロジェクトの Web サイトで最新の WCAG 2.0 のドキュメントを読んでください。
  • WCAG プロジェクトの Web サイトで「WCAG 2.0 解説書」を読み、WCAG 2.0 の指針を実装する方法を詳しく学んでください。
  • IBM のアクセシビリティーに関して学んでください。

製品や技術を入手するために

  • w3.org から WAI-ARIA の情報を入手することができます。
  • Dojo 技術の詳細は DojoToolkit.org から入手することができます。

コメント

developerWorks: サイン・イン

必須フィールドは(*)で示されます。


IBM ID が必要ですか?
IBM IDをお忘れですか?


パスワードをお忘れですか?
パスワードの変更

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


お客様が developerWorks に初めてサインインすると、お客様のプロフィールが作成されます。会社名を非表示とする選択を行わない限り、プロフィール内の情報(名前、国/地域や会社名)は公開され、投稿するコンテンツと一緒に表示されますが、いつでもこれらの情報を更新できます。

送信されたすべての情報は安全です。

ディスプレイ・ネームを選択してください



developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

必須フィールドは(*)で示されます。

3文字から31文字の範囲で指定し

「送信する」をクリックすることにより、お客様は developerWorks のご使用条件に同意したことになります。 ご使用条件を読む

 


送信されたすべての情報は安全です。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Web development
ArticleID=432978
ArticleTitle=Web 2.0 技術でのアクセシビリティー
publish-date=09012009