「なぜ日本のウェブサイトでは1Passwordでクレジットカード番号を一発入力できないのか？」という素朴な疑問から、少し調べてみました。なお1Passwordはパスワード管理ソフトであり、またウェブサイトのフォームにパスワードやクレジットカード情報を一発入力するためのブラウザ拡張機能です。

クレジットカード番号入力フォームに関する標準を探したところ、IETFとWHATWGの取り組みを見つけることができました：

Electronic Commerce Modeling Language (ECML), Version 2 Specification by IETF
HTML Standard: 4.10.19.8 Autofill by WHATWG

こういった標準に準拠することで、1Passwordのような支援技術(assistive technology)にフォームの「意味」(semantics)を提供できるということのようです。

私の考えでは、後者（HTML Autofill）の方式が実装しやすいのでオススメです。

ECMLによるマークアップ

1Password開発者はECML2によるマークアップを推奨しています。

Making Input Fields Compatible with 1Password - AgileBits Support Forum:

While 1Password has several "fallbacks," you're best bet is to follow the conventions set forth in RFC 4112, Electronic Commerce Modeling Language (ECML), Version 2 Specification, for the best compatibility with 1Password and other software (including some assistive technology for disabled users).

RFC4112 ECML2仕様には分かりやすいHTMLマークアップ例がなかったので、かわりにRFC 3106 ECML v1.1から引用しておきます：

 <FORM action="http://ecom.example.com" method="POST">
Please enter card information:
<p>Your name on the card
  <INPUT type="text" name="Ecom_Payment_Card_Name" SIZE=40>
<br>The card number
  <INPUT type="text" name="Ecom_Payment_Card_Number" SIZE=19>
<br>Expiration date (MM YY)
  <INPUT type="text" name="Ecom_Payment_Card_ExpDate_Month" SIZE=2>
  <INPUT type="text" name="Ecom_Payment_Card_ExpDate_Year" SIZE=4>
  <INPUT type="hidden" name="Ecom_Payment_Card_Protocol">
  <INPUT type="hidden" name="Ecom_SchemaVersion"
         value="http://www.ecml.org/version/1.1">
<br>
 <INPUT type="submit" value="submit"> <INPUT type="reset">
 </FORM>

ということで、RFC4112 ECML2: 2.1.1. The Field Listで定義されているフィールド名（例：Ecom_Payment_Card_Name）を、フォームフィールドの name 属性に指定すればよさそうですね。

※フォームフィールドのname属性を自動的に決めるタイプのアプリケーションフレームワークとは相性が悪そうですね… 他の属性名（例えばdata-ecmlなど）でECMLフィールドを指定できればよいのですが、そういう代替手段の存在は不明です。

注意点：

So that browser software can tell what version it is dealing with, it is REQUIRED that the Ecom_SchemaVersion field be included in every transaction when ECML is being used on the web. Ecom_SchemaVersion SHOULD appear on every web page that has any Ecom fields. It is usually a hidden field in HTML Forms.

autocomplete属性によるマークアップ

WHATWGではautocomplete属性値として下記の通り定義しています（2015年12月10日現在）：

HTML Standard: Living Standard — Last Updated 9 December 2015 (as of Dec 10, 2015, "Last Updated 9 December 2015"):

4.10.19.8 Autofill

4.10.19.8.1 Autofilling form controls: the autocomplete attribute

User agents sometimes have features for helping users fill forms in, for example prefilling the user's address based on earlier user input. The autocomplete content attribute can be used to hint to the user agent how to, or indeed whether to, provide such a feature.

クレジットカード情報に関する属性値は下記のものですね：

cc-name
cc-given-name
cc-additional-name
cc-family-name
cc-number
cc-exp
cc-exp-month
cc-exp-year
cc-csc
cc-type

HTMLマークアップ例を同仕様書から引用します：

<form method=post action="step2.cgi">
 <input type=hidden autocomplete=transaction-currency value="CHF">
 <input type=hidden autocomplete=transaction-amount value="15.00">
 <p><label>Credit card number: <input type=text inputmode=numeric autocomplete=cc-number></label>
 <p><label>Expiry Date: <input type=month autocomplete=cc-exp></label>
 <p><input type=submit value="Continue...">
</form>

1Passwordは上記の仕様（HTML Autofill）への対応を明言しています：

Designing your website to work best with 1Password - 1Password Support:

1Password uses the HTML Autofill attribute when available to help determine the intention of various fields.

Normally explicit autofill attributes are not required, but if you’ve managed to find an edge case, this is a great way to give 1Password an extra hint.

なお、ブラウザの対応状況も気になるところです。Can I Useでは「autocomplete属性のon/off」への対応状況は示されているものの、「autocomplete属性値としてcc-numberは利用可能か」といったことまではわかりませんでした。ですので、GitHub Issuesで "+1" しておきました。これらが集計されてCaniuse Feature suggestion listになっています。

アクセシブルなフォームで明るい未来（追記1）

冗談みたいな見出しをつけてしまいましたが。

この文章ではクレジットカード入力フォームの話だけをしましたが、ECMLやHTML Autofillでは、住所などを含む個人情報全般についてもフィールド名が定義されています。したがって、こういったセマンティクスをフォームフィールドにマークアップしてあげれば、1Passwordなどの支援技術によって 会員登録フォームや購入フォームを丸ごと一発入力 できるようになるはずです。

最近はSafariなどのブラウザ自体がオートフィル機能で住所なども扱うようになっています。つまり、フォームのアクセシビリティを高めることは、決して1Passwordユーザーなどの「上級者」だけに関係することではなくて、 すべてのインターネットユーザーに関わる のです。

ウェブ開発者のひとりひとりが、こういった標準に則ってフォームのアクセシビリティを向上させれば、 ウェブのユーザーエクスペリエンスが底上げされる ことになるでしょう。

そういうわけで、ウェブ開発者のかたは、ここに書いてあることを頭の片隅に入れておいていただき、フォームの実装時に参照していただければ幸いです。

別の未来の話（追記2）

もはや余談ですが。

そもそも、いろんなサイトに同じ個人情報を登録して回る必要はあるのでしょうか。多くのインターネットユーザーは、すでに特定の企業（携帯電話、EC、OSなどの企業）に対して、住所を含む多くの個人情報を預けていることでしょう。だったら、それらの情報を使いまわせばいいはずです。このような考え方を「ID連携」といい、そのための技術としてOpenID Connectなどがあります（それ以外にも多くの技術があります）。ユーザーの代わりに第三者ウェブサイトに対して個人情報を提供する主体のことをIDプロバイダー(IdP)といいます。

EC決済についてはすでにID連携が進んでいます。携帯電話キャリアが提供するID連携サービスとしては、My Softbank認証、auかんたん決済、ドコモケータイ払いなどが知られています。また、EC大手もAmazonログイン＆ペイメント、楽天らくらく決済、Yahoo!かんたん決済などのID連携サービスを提供しています。これらのサービスを導入したサイトでは、ユーザーはフォームに個人情報を入力する必要がありません。

スマートフォンOSを提供するApple、Google、Microsoftなども大手IDプロバイダーです。例えばiOSデバイスの指紋認証機構(Touch ID)を使ってユーザー認証し、Apple IDの情報を使ってネットショッピングや会員登録ができるようになれば、とても手軽です。会員登録フォームは不要ですし、サイトのパスワードを覚える必要もありません。こういったことはいずれ実現されるでしょう。

未来はどっちだ

「すべてのフォームが一発入力できる未来」と「ID連携によって大半のフォームが駆逐される未来」のどちらが先に実現するかはわかりませんが、当面はこの二つの取り組みが平行して進歩していくのではないかと思います。最終的により望ましいのは後者ですが、短期的には前者への取り組みも有意義ですから。したがって、この二つの「共進化」を意識しながら開発に取り組むのがよいのではないでしょうか。