Decide on how anchor-able components work

[dfreedm]

Related #328, #385

There are really only three ways to do anchors for some components:

Options 1: Anchor around component:

<a href>
  <mwc-button></mwc-button>
</a>

Option 2: Facade anchor attributes

<mwc-button href></mwc-button>

Option 3: Slotted anchor

<mwc-button>
  <a href></a>
</mwc-button>

We should pick one, and use it consistently

[abdonrd]

More references here: https://github.com/PolymerElements/iron-elements/issues/37

[bennypowers]

The old polymer way was to wrap your UI in anchors. IIRC that decision was taken to stay in line with the rest of HTML, which is solid reasoning IMHO

It can get difficult when we're talking about nav links in a drawer which are also list items, and that's a very popular pattern

[hunterloftis]

Has there been any movement here? What's the current-best way to use buttons as anchor links? Options 1 and 3 break styling while option 2 has no effect.

[e111077]

Progress is still being done on this as we are moving onto button finalization work. Stuck behind a rearchitecture of our styles, but likely answer is that there will likely be a different variant for a link button.

In the meantime you will likely have to use a click event listener which should also trigger just fine on a screen reader and via keyboard input; the problem is still a11y in which it will announce as a button rather than a link. We are working on global a11y and role support which is likely to come in lit-element v3.0 in the coming months

[hunterloftis]

Thanks for the update!

[christophe-g]

Any news on this ? Thanks

[steverep]

I'm also wondering what the current status of this and related issues is. From both an accessibility and general keyboard navigation standpoint, options 1 and 3 are not acceptable. There's no such thing as a "button link"; only one ARIA role should result, otherwise the result is extra and confusing screen reader speech, 2 tab stops instead of 1, and invalid markup (i.e. a <button> is not valid inside a <a> and vice versa).

The only valid and accessible way I see to accomplish having a mwc-button navigate to a new URL is to use either window.location.href or window.open.

Option 2 would also be perfectly accessible, and much easier on the implementer, so long as the components rendered an anchor in place of a button:

${this.href
  ?html`<<a role="button" href=${this.href} ...> ... </a>`
  : html`<button ...> ... </button>`
}

[asyncliz]

Components in M3 now accept target and href attributes if they can be links (such as buttons)