I’ve had to venture into this recently because playable websites generated with Dialog use just normal <span>s (with a special class) for links. One of my testers said to add role="link" to them, which helped, but I haven’t heard about the “work properly with keyboards” part.
What should one do to make links work like links, when you can’t just make them be normal <a> tags? (I imagine that’s the all-around best solution, but it would require more interpreter hacking than I’m comfortable with at the moment.)
Also an option, though if I’m digging deep enough into the interpreter to change the HTML it generates, I’ll probably just go with <a>s. That’s what everyone expects links to be after all.
To make spans work like links, you would need to add a tabindex property to make them focusable, and also keyboard events to handle “clicking” with the space bar… And I’m sure there are other things too.
Really, I think modifying the interpreter to use <a> elements, which have everything built-in, would just be easier.
(I believe I already raised this issue somewhere, but since Dialog seems unmaintained, I guess we won’t have a fix soon.)
Followup: is it possible to find what CSS is applied to elements by default? For example, I know links default to color: blue and text-decoration: underline, but I don’t know what other properties they have that might mess with the layout. (The interpreter layout is specified in absolute units and seems very finely-tuned; I don’t know if I can fix it if I break it.)
If memory serves me correctly, the short answer is no.
I believe the text will wrap within the button itself, but not wrap in the flow of text in a paragraph. I also remember there being an issue with spans and that styling <a> tags was the best way forward. I’m pretty thorough when it comes to JS/HTML/CSS and I couldn’t crack the code. Browsers definitely deal with <a> tags in their own unique way, despite what CSS/JS allows you to do to mimic the functionality built into <a> tags.
Then only reason I wouldn’t want an <a> tag is because all major browsers show the URL in the lower corner when the cursor is over it. It makes web apps feel less like apps that way, especially when you go full screen and your not “surfing the web” anymore.
Because the href attribute is required to render an <a> tag properly, I include them when the page is rendered and then remove the href after the fact. The browser is none the wiser and keyboard accessibility is left intact.
Anyway, that’s the only reason I’ve discovered as to why anyone would not use an <a> tag. Aesthetics, basically.
Things with the link nature should be a’s (or should be given the ARIA role link, but when an HTML element exists with the appropriate meaning already, it’s always preferable to just use it).
Things with the button nature should be button’s (or at least have ARIA role button).
These are helpful criteria most of the time, when things are clearly link-ish or clearly button-ish. But there’s also an ambiguous middle ground where it becomes a judgement call.
This is correct. <button>s are treated as though they are blocks. Even if you set display: inline, it will be interpreted as display: inline-block.
That’s perhaps one of the few reasons in which you might need an <a> rather than a button. Beyond that it’s mostly personal style, though Zed is right about the ARIA roles. I’ve recently been designing a file browser in HTML, and decided to mostly use buttons for my clickables.
I’ve finally bitten the bullet and started editing the interpreter to output <a>s instead of <span>s. It just seems like all-around the best option; role="link" worked okay, but if it doesn’t enable keyboard navigation, that’s really not good enough imo.
I’m also making each player input in the transcript a <h2>, which should make them easier to navigate between. I’m not at this point putting an <a> inside the <h2>, even though it can be clicked to re-input the same command, but that could change.
Mozilla Developer Network has a pretty good guide on how to make an accessible button out of a tag that isn’t <button>. Yes, it is a decent amount of work to get right, but right now, it’s the only way to get a button whose contents will wrap across lines like <a>s do… to the best of my knowledge, anyway.
Is there a reason to make a <button> act like an <a> instead of just using an <a> in the first place?
(Not a snarky question—most of my HTML knowledge is pre-2010. The reason I was using a <span> instead originally is that I didn’t write the original interpreter, and by default it outputs <span>s, and I didn’t want to break anything trying to change that.)
I’m not sure if I am understanding you correctly, but basically what Zed said—if something isn’t “navigating” somewhere (imagine me air quoting because navigating can be an ambiguous concept in this modern age) it should either be a <button> or have a button ARIA role.
It feels tough to come up with a a scenario where <a role=“button”> is the correct move. My inclination would be to use a <span> instead.
Hm. Is performing an action in an IF generally considered button-y then? I figured that going between Twine passages (or their equivalent in other systems) was fundamentally a sort of “navigation”, but you’re right, it’s also sort of an “action” or “change of state”.
So would it be better to make them all spans with the button role, and set the tabindex so they can be navigated between? I feel like this should be a solved problem in IF, with how long Twine’s been around, but this is the first time I’m trying to reimplement it myself.
It’s important to remember that HTML tags existed before CSS. It was the browser that styled the elements. Buttons looked like physical buttons you could push with your finger and were distinct from body text. Links looked like text that was clickable, but didn’t interfere with the rendering of body text. That was the need for the distinction, plain and simple. I wouldn’t overthink it. <a> tags and <button> tags are equally as accessible to screen readers and keyboard control today. So, if the clickable link could possibly be in the body of the text, use an <a> tag. If the clickable link will always remain on it’s own, rendered separately from the body text (like interface menu items), it’s safe to use a <button> tag.
I use <a> tags because they are more versatile. You can style an <a> tag to function/display like a button, but you can’t style a <button> tag to display like an anchor tag.
As a side note, if HTML were to be rewritten today, I think it would look very different.
I confess to knowing absolutely nothing about the coding side of JavaScript(If I’m honest, the number of websites that work better when you disable JavaScript that isn’t vital for the sight to function was enough to make me want to avoid ever using it for my own web stuff), but from where I sit, most HTML elements seem to have the ability to focus them by tabbing from adjacent elements and activating them with space or enter built in while JavaScript clickables(which is what Orca calls them, I have no idea what they are called at the code level) have to be manually coded to be tab focusable and activated by a normal keypress, and most web coders don’t seem to bother so I usually have to press ctrl+shift+a to bring up Orca’s list of clickables on the current page, scroll through the list and then tab to the activate button, something I rarely, if ever have to do with HTML elements. Though the worse are things that are meant to be clicked, but look like normal text to a screen reader, in which case I have to realize something that looks like plain text is meant to be clicked, move the reading cursor to that text, press caps lock plus 9 to hopefully sync the mouse cursor with the reading cursor, than press caps lock plus 7 to do a virtual mouse click and pray to Turing it works(anything requiring a virtual mouse click tends to be very finicky in my experience).
Also, I’d hate to imagine what we’d end up with if someone tried to reinvent the wheel and managed to kill HTML. Would probably be simpler for a lay person to work with, but I’d fear the designers would assume everyone is using a touchscreen or mouse and leave people who only use keyboard hung out to dry. I feel like part of what makes HTML so accessible for blind users is that it was developed back in the days when mice either weren’t a thing or were just starting to catch on, so keyboard control is kind of baked in.