I'd like to see the structures added to the contextual help, or a description span as a simpler first step before looking at something interactive. That alone with save people from having to go look for the documentation elsewhere.

I'd like to see the structures added to the contextual help, or a description span as a simpler first step before looking at something interactive. That alone with save people from having to go look for the documentation elsewhere.

I thought about adding a list of available tags to the contextual help, but there is a chance that users would not find them there (issues with Admin Help discoverability).

Deep-linking to a contextual help tab isn't possible now (see #21273), so I opted to add a span below the Custom Structure option to show the available tags. I moved the Codex link to the Available Tags text in this span, and removed the reference to it in the opening section.

This could be a good first step, with possibly adding auto-complete later if someone works up a small proof-of-concept plugin, as @helen suggested.

Patch added that announces addition of structure to permalink structure.

Other issues to consider:

1) Ability to place cursor between items and insert new structure in that location instead of end
2) Avoid adding the same structure twice if clicked twice? Should a second click remove that structure from the string?

1) Ability to place cursor between items and insert new structure in that location instead of end
2) Avoid adding the same structure twice if clicked twice? Should a second click remove that structure from the string?

Added in 29872.4.diff​. It's even possible to replace the selected text in the input field. Slashes are only added when needed. Adding the same structure tag twice doesn't work either. I also cleaned up the HTML a bit to make it more readable.

I think this is an improvement that would help users enter the custom structure tags and I'd second introducing this feature in core. It would be great to refine some details and make the buttons as much easy to use as possible, as well as error-safe. Some considerations off the top of my head:

Selection
When tabbing through the form fields, the input field content will be selected. Then, when operating on the buttons, any content will be cleared out and the new tag inserted. This may not be the desired result, so maybe consider to add a tag at the end by default?

Description
I'd add a short description of what the buttons do after "Available tags:", something like: Click the buttons below to add custom structure tags surrounded by the percentage sign. (with some better wording).

For screen reader users
I'd consider to avoid screen readers announce the percentage signs, this would require one more string to represent the tag without the % that can probably be generated programmatically. The generated HTML instead of, for example:

<button type="button" data-added="%year% added to permalink structure">
<code>%year%</code><span class="screen-reader-text">The year of the post, four digits, for example 2004</span>
</button>

could be something like:

<button type="button" data-added="year added to permalink structure"
aria-label="year (The year of the post, four digits, for example 2004)">
<code>%year%</code>
</button>

Already used tags
When a tag is already present in the structure, the related button does nothing and that's correct. However, there's nothing that can inform users the button won't produce any effect. It gets a bit trickier but in this case the button should announce something like: aria-label="year (Already used in the Custom Structure". Maybe, the buttons representing already inserted tags should also look differently.

Visuals
I'm not a designer, so I'd ask to real designers, however I was wondering if there's a good reason to style these buttons with the styling usually reserved to <code> elements. After all, they're buttons: users should understand immediately what they are, so maybe style them as standard buttons?

Safari doesn't expose a list as a list to assistive technologies when it's styled with list-style: none;. This is a particularly annoying Safari "feature" since VoiceOver won't announce "list" or the number of items in the list. There's a workaround, it's redundant, the W3C validator will produce a warning when it's used, but it doesn't harm anything: add role="list" on the... list.

Then, when operating on the buttons, any content will be cleared out and the new tag inserted. This may not be the desired result, so maybe consider to add a tag at the end by default?

I found this feature to be handy when you want to replace existing tags or add yours at some specific position. For example, when you put the cursor to the beginning of the input and click on a button, the tag will be inserted at the beginning. I added that based on earlier feedback by @joedolson:

1) Ability to place cursor between items and insert new structure in that location instead of end

However, I can remove that selection feature if it doesn't make much sense.

When a tag is already present in the structure, the related button does nothing and that's correct. However, there's nothing that can inform users the button won't produce any effect. Maybe, the buttons representing already inserted tags should also look differently.

I have that "Already used" thing working, but I was wondering if we should just disable a button when the tag was inserted. VoiceOver doesn't announce the buttons anymore in that case and you already have the different styling. Also, @joedolson said this earlier:

2) Avoid adding the same structure twice if clicked twice? Should a second click remove that structure from the string?

at least one -> at least once. ?

Where did you see that, @afercia?

users should understand immediately what they are, so maybe style them as standard buttons?

Yep I've seen the tag is inserted at the previous cursor insertion point :) However, since the "select all" text in the field is the default behavior when tabbing through the fields, that could lead to unexpected results. I'm not sure how to solve this though.

"Already used"
Hm, maybe use "aria-pressed" on a button representing an already used tag? Then, clicking again the button should remove the tag. aria-pressed conveys that the control works like a "toggle", so maybe it could work. /cc @joedolson

in a comment :)
// See if the permalink structure input field has had focus at least one