Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Add Editable Permalinks #5756
On this branch I am noticing one thing not like the design, which actually was in the thread and that's copying when clicking the link icon. Here is the conversation for reference:#3418 (comment).
We need to of course test this with notices again but overall seems like the design and on track there.
Sorry I have to reference also to the a11y feedback given in the previous PR see #3418 (comment)
Visually, I'd leave this to @karmatosed but I'm not fully sure about the copy button discoverability: it doesn't look like a button, not sure why users should understand it's an UI control.
Note: the permalink is empty now.
Yah, I'm inlined to go this way. It's not an external link, so it seems weird to be using the
Also, thanks to the magic of flexbox, mobile is significantly less unusably ugly now.
Quickly tested: while it seems to work with new posts:
it doesn't seem to work well with existing posts:
From an accessibility perspective, I see part of the feedback is ignored. Navigating content for keyboard users and assistive technologies users is often a linearized experience. Content should be placed in a logical order, taking into account linearization. In this regard, the previous PR was better because it had in order:
(of course, "Copy" shouldn't be a primary button and some details were still unpolished, but the UI in the previous PR was better IMHO)
Not ignored, you mentioned you were going to look at it in #5494, so I assumed the action was going to happen there. I'll see if I can make some changes in this PR, too.
Thanks @pento. Some a11y considerations:
As long as it works in supported browsers, I think using autofocus is fine in this case, as this mini-UI has the specific task to edit the permalink
The buttons placement is still not ideal, and it's a violation of a specific WCAG guideline: the visual order should always match the DOM order:
Tooltips work in an accessible way out of the box when used for the
Switching components on the fly produces a focus loss:
I'd remove the dot at the end of the string :)
Note: I've edited the focus loss issue description, I had described a wrong scenario.
referenced this pull request
Mar 26, 2018
If it's reasonable to apply broadly, I think we should pull this behavior out of
Thanks for the extra info, @afercia.
As it's just a shiny new kind of accessibility issue, I've reverted the DOM order of the copy button back to it's original place: @karmatosed previously mentioned that the design in this PR is a starting point, so let's look at how we can order these things in the next iteration.
When the edit form is closed, it now focusses on the permalink, which seems to be the most relevant element to shift the focus to.
From an accessibility perspective, how do you feel about the current state of this PR as a place to iterate from? There are certainly improvements to be made, but it seems like they are better made as part of the design iterations, as they depend on how things are laid out.
@aduth: could you review the code again?
@karmatosed: I think I've caught everything, but can you confirm that the current design of this PR matches what you had in mind?
@pento thanks for the changes. The most important thing is to avoid the focus loss and that is addressed now (we can iterate on the better place to move focus to). Not sure @aduth
As per the placement of elements, yep this is a case where design and accessibility have different needs. As you suggested I think we can iterate in #5494 even if that issue was meant to improve the placement and tab order of the whole UI, I think it can focus also on the UI content.
@karmatosed I'd suggest to consider the link icon doesn't really look like a button, I have concerns on its discoverability. Can we consider a standard button, for better clarity for all users?