←back to thread

Facebook adds 5 divs, 9 spans and 30 CSS classes to every post in the timeline

(twitter.com)
550 points polskibus | 4 comments | 08 Feb 19 16:04 UTC | HN request time: 0s | source
Show context
guest2457533 ◴[08 Feb 19 16:55 UTC] No.19116135[source]▶
Does this meet the required standard for accessibility users? Do they have any such obligations?
replies(2): >>19116146 #>>19116295 #
gothroach ◴[08 Feb 19 17:08 UTC] No.19116295[source]▶
One of my first thoughts when I saw this was about screen readers. If searching "Sponsored" in Chrome doesn't match the posts, I'd wager screen readers would just go ahead and try to pronounce all the extra 'S's.
replies(1): >>19116356 #
1. Someone1234 ◴[08 Feb 19 17:13 UTC] No.19116356[source]▶
It works fine.

Screen readers obey CSS, this uses CSS to hide all of the additional elements (display: none). Screen readers are also designed to work when text is broken up by other inline elements e.g.:

He<b>llo</b> world

In this case it reads out both the words Sponsored and Public.

> If searching "Sponsored" in Chrome doesn't match the posts

That also worked perfectly fine in Chrome, Firefox, and Edge. Did you scroll enough to render any Sponsored posts?

replies(1): >>19116543 #
2. CharlesColeman ◴[08 Feb 19 17:29 UTC] No.19116543[source]▶
So the technology to defeat this kind of obfuscation has already been developed and is reliable?
replies(2): >>19116620 #>>19116712 #
3. Someone1234 ◴[08 Feb 19 17:35 UTC] No.19116620[source]▶
Well a web browser has to render it correctly, so yes? A screen reader is just another type of browser at this point.

These techniques work because some blockers only support a limited subset of what a full browser can do (namely block resource locations and specific HTML elements).

4. barbecue_sauce ◴[08 Feb 19 17:42 UTC] No.19116712[source]▶
And rather insignificant to implement. All this protects against is low-effort document scraping. If they randomized it somehow, that would be a little harder to defeat.