Live data from Hacker News

The easiest way to keep your web apps accessible: Just use text

blog.logrocket.com

141–150 of 271 posts

Re: The easiest way to keep your web apps accessible: Just use text

#141
post #43

I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).

I agree for cases where the text is supposed to behave like a hyperlink - it should be one. But in cases where its behaviour is that of a button (even a button which has the appearance of blue text - think iOS) then onclick is a good choice. Especially for contexts where “open in new tab” makes no sense. I can’t see any valid reason for using a void link - worst of both worlds?

Maybe a link styled to look like a button?

I’d rather style the thing to look the way it should rather than apply unusual functionality to something.

Re: The easiest way to keep your web apps accessible: Just use text

#142

Earlier quoted context omitted.

Not necessarily: I do not want to click back 30 times to get out of your slideshow and back to my Google results. Thank you.

But the problem there is that they used a carousel in the first place. Were it content that justified clicking 30 times into it, it would also justify backing out of it 30 times.

The problem is that it might take a half-dozen clicks to realize it's not worth reading the other 24, then you need to click back a half-dozen times (worse if there are page reloads during that).

Re: The easiest way to keep your web apps accessible: Just use text

#143

Also please don't use bad fonts. Someone posted the following article the other day and the font drove me so nuts that I had to resort editing the CSS code to make it readable. https://blog.bugsnag.com/bug-day-race-condition-therac-25/ I really wish "reading mode" was a prominent feature in desktop browsers.

    font-family: sans-serif;

That is all neede in 2018, it even looks "native".

Re: The easiest way to keep your web apps accessible: Just use text

#144
post #100
post #4

Why would I use LogRocket for my all-text no-js web "app"?

They offer some kind of website hosting? I can't tell because the entire logrocket.com domain is blocked by "Peter Lowe’s Ad and tracking server list" which I have enabled through uBlock Origin. Not sure if I turned on that list or if it's on by default. Either way, the only other site I've ever get that full domain block warning on is Facebook. I'm guessing they're up to some equally nefarious tracking tactics.

Peter Lowe's list is notoriously overzealous and it's enabled by default. It breaks countless websites and I found other lists to be better.

Re: The easiest way to keep your web apps accessible: Just use text

#145
post #43

I'm still looking for "just use links". So many frontends I see use fancy onclicks to emulate links (including updating window.location). However they are either not links or are void links. This breaks all sorts of useful things (copy link location, open in new tab &c.).

This. LinkedIn is particularly terrible. I cannot believe such a huge, successful website can have so horrendous UX.

Re: The easiest way to keep your web apps accessible: Just use text

#146
post #60

Earlier quoted context omitted.

Breaking it is completely unnecessary too, even with single page apps. It's not all that hard to build a React or Angular apps that use proper links along with the browser history API. Designed properly, the apps should be able to load their state and render correctly even when deep-linked to somewhere other than the app's top level. This isn't a new concern - I remember paying attention to this back in the old days…

It's such an extremely simple litmus test: if it breaks the back button of the browser, it's the wrong design. The closest thing to an exception being cases where one needs to be logged in to see a page, or when links are consciously invalidated for some other reason. And even then the website/webapp should still just signal this to the user without a bazillion redirects.

> if it breaks the back button of the browser, it's the wrong design.

Some people don't care about a back button in a single page application and it isn't "trivial" to implement properly. It requires libraries, polyfill support, etc. And in a world where everyone is complaining about js bloat, it should be no surprise why it exists.

Re: The easiest way to keep your web apps accessible: Just use text

#147
post #104

Earlier quoted context omitted.

I agree for cases where the text is supposed to behave like a hyperlink - it should be one. But in cases where its behaviour is that of a button (even a button which has the appearance of blue text - think iOS) then onclick is a good choice. Especially for contexts where “open in new tab” makes no sense. I can’t see any valid reason for using a void link - worst of both worlds?

I recall reading a story about someone who had implemented some sort of table using links for actions. At some point the app data mysteriously got wiped out. Turned out a user had Alexa toolbar installed and it crawled the "delete" links on each row (as well as all the pagination links)...

This is what happens when you use a HTTP GET to perform an "unsafe" action. HTTP GET links should always be safe to crawl... Always... It's in the spec for a reason.

Seen people make mistakes like this before... Even using a POST when it should be a GET can cause funny behavior. Funny, but not dangerous behavior like using GET instead of POST.

Whenever I bring a new web dev aboard this is my first lesson to them, and I say "all sorts of clients are going to crawl your webapp, so make sure your webapp is coded correctly for it." Browsers are coded with this assumption, bots/crawlers, email clients, etc...

Re: The easiest way to keep your web apps accessible: Just use text

#148

Earlier quoted context omitted.

> input button is hidden using CSS tricks because the actual button can't be styled. Buttons can be styled.

Not the file input button, unless things have changed in the last year since I had to build one. Other buttons, sure, but not on file inputs.

You realize you don't need input field for file input in any of the modern browsers. Just capture the click event and create input field temporarily.

    let i = document.createElement('input');
    i.type = 'file';
    // other attributes if you like
    i.onselect = ev => {
      // ev.files contains selected files
    };
    i.click();
    i.remove();
No stupid styling hacks needed. At most you may need tabIndex on the or that represents the button for selecting files.

You can leave around if you want to submit data via and not via XHR.

Re: The easiest way to keep your web apps accessible: Just use text

#149
post #86

Earlier quoted context omitted.

When attempting to open the website I was greeted with: uMatrix has prevented the following page from loading: https://blog.logrocket.com/the-easiest-way-to-keep-your-web-apps-accessible-c2b57506cc2a I never blacklisted the website on uMatrix[0] myself so I checked the list of hosts files I'm using. It's apparently part of Peter Lowe’s Ad and Tracking Server List [1] [0] Obligatory "How do you know someone uses uMatr…

I usually read HN comments before reading the article, I read your comment and checked the other tab - Ha same thing for me I did a quick Google search on them, It's kinda ironic >LogRocket helps you understand problems affecting your users, so that you can get back to building great software.

How is that ironic? It sounds like the problem was self-inflicted.

Re: The easiest way to keep your web apps accessible: Just use text

#150

It really annoys me when a site that just needs to display some text loads a whole react-redux framework. When it comes to reading text I honestly prefer the old school academic websites (albeit with a max-width set). Keeping stuff simple even makes maintaining the site simple, I personally run https://www.discoverdev.io and have used zero JavaScript. Inspired by brutalist design principles :)

Hey nice site. With cache cleared:

79.2KB to load home page

sub-second load

7 total requests

In contrast... where I work, to load our enterprise webapp's home page (running on Angular, WebAPI, many external CSS/JS "plugins"):

5.7MB to load home page

28.95s to load everything

173 total requests

Granted we're serving a way different goal, but still... i admire how lightweight your site is.

Post reply on HN