Access4all / adg

Accessibility Developer Guide
http://www.accessibility-developer-guide.com
Other
187 stars 36 forks source link

Change codepen references to links instead of post form #211

Open renestalder opened 5 years ago

renestalder commented 5 years ago

Based on the short discussion on Slack, I noticed that the current Codepen implementation automatically creates a pen on your account. It uses a form and a submit button to link to the pen, which, instead of opening the original pen, creates a fork on your account.

The not so beautiful side of this is also that, due to the submit button, the Codepen can't opened in a new window.

Proposal

Link to an original pen that can be forked instead of creating the pen for the user.

Possible problems

Could be that those pens do not exist yet and have to be created, as It looks like that the post actually sends the data for the pen.

jmuheim commented 4 years ago

In the very first implementation of the ADG, all examples resided on CodePen and were then imported into the ADG.

We could think about displaying the general CodePen iFrame, like Paciello Group does it in their blog:

image

I don't know though how accessible this would be. That's the reason why we kept the ADG and CodePen strictly separate, so nobody could blame us like: "Ooooh, you use something that is not 100% accessible in your guide!". On the other hand, Paciello Group doesn't seem to have an issue with that.

Possible problems: Could be that those pens do not exist yet and have to be created, as It looks like that the post actually sends the data for the pen.

The question is whether we could automatically create/update pens during the build process.

Also, I like the plain view that we have in the ADG (e.g. https://www.accessibility-developer-guide.com/examples/tables/spanning-rows-cols/_examples/table-spanning-multiple-rows-and-columns/), we should definitely keep it, regardless whether we also provide a pen (on CodePen, you have to open it manually through a menu, which is cumbersome, especially when having a screen reader running).

ralf57 commented 4 years ago

@jmuheim not sure why this issue has been assigned to me since you and @renestalder already did some work/investigation on it.

jmuheim commented 4 years ago

You're right, @ralf57.

Any response to my thoughts, @renestalder?

renestalder commented 4 years ago

@jmuheim If I understand it correctly, then it would still require to setup an ADG account on codepen to host the embeds (which comes back to my proposal), as you can see, clicking the codepen logo in their blog routes you to a specific pen on an account.

So then, the first initiative I propose is creating that account and creating all pens there. Then link to the specific pens with a link instead of a POST.

With this, the scope of the ticket would be reached.

If we embed them directly then, can be an addition, which we might first want to check for any drawbacks with the website's speed and also, how they render on mobile (as with remaining space on small viewports, it's always cumbersome when your finger is on top of another scrolling container, while you wanted to scroll the page, not the codepen).

jmuheim commented 4 years ago

I don't think that it's a good decision to "outsource" codes from the GitHub directory to Codepen examples.

We could add a mechanism to create the examples on the fly while deploying the project, but how would the mechanism know which example corresponds to which pen?

I'm not really sure yet what's the huge drawback of the current implementation? A created fork can easily be deleted, and at least on my Chrome/macOS I can open any button in a new window by Cmd-clicking on it.

ralf57 commented 4 years ago

@jmuheim @renestalder could you please come to an agreement on the direction to take or drop this issue?

renestalder commented 4 years ago

@jmuheim

I'm not really sure yet what's the huge drawback of the current implementation? A created fork can easily be deleted, and at least on my Chrome/macOS I can open any button in a new window by Cmd-clicking on it.

So from that, I might retest on all browsers. I only have the feedback from one source via Twitter and back when this came in, that problem could be replicated on my side. And I for sure also see it as a problem for myself if a website blocks me from opening something in a new window.

Coming back to the lean solution: Opening a Codepen account and creating the pens manually first is the fastest approach here. Automation can still be added after that. Those code samples didn't change a lot in the last two years, so it's not a mayor blocker for a first move.