Specification: https://html.spec.whatwg.org/multipage/semantics.html#the-a-element

As mentioned in some comments in https://www.w3.org/Bugs/Public/show_bug.cgi?id=26622 , it would be useful if the <a> element supported a `disabled` attribute, just like the <button> and <input> elements do.

As mentioned in https://code.google.com/p/chromium/issues/detail?id=388666 , <button>s and <input type="button">s and <a>s are fairly interchangeable. Many webpages use CSS to style some <a>s to look like buttons. However, the lack of support for <a disabled> causes some pain when it becomes necessary for an author to switch from an <a> to a <button> (or vice-versa [1]), or when an author is writing generic code that needs to handle both <a>s and <button>s and cares about the elements' enabledness. The author must switch between using the `disabled` attribute and using some custom class that represents (dis)abledness. And of course, the author must reimplement the "ignore clicks if the element is disabled" logic themselves, instead of having the browser implement it for free.

Using a class instead of an attribute also means that the disabledness of the <a> isn't communicated to users of assistive technology, unless the AT software resorts to using heuristics based on the class name, which can easily fail if the author opts to name the class something other than `disabled` (e.g. to comply with some CSS class naming convention or for namespacing purposes). Authors could use the `aria-disabled` attribute to remedy this, but this requires additional effort and knowledge on the part of authors, which cannot generally be relied upon.


[1]: For example, due to cross-browser inconsistencies in the focus behavior of <a>s vs. <button>s; see https://developer.mozilla.org/en-US/docs/Web/HTML/Element/a#Clicking_and_focus vs. https://developer.mozilla.org/en-US/docs/Web/HTML/Element/button#Clicking_and_focus