[HN Gopher]  Pixels and Accessibility
       ___________________________________________________________________
        
        Pixels and Accessibility
        
       Author : codenberg
       Score  : 57 points
       Date   : 2022-05-18 16:01 UTC (6 hours ago)
        
 (HTM) web link (www.joshwcomeau.com)
 (TXT) w3m dump (www.joshwcomeau.com)
        
       | CharlesW wrote:
       | > _In theory, 1px is equal to a single dot in a computer monitor
       | or phone screen._
       | 
       | Even in theory, this has never been true AFAIK. Pixels (px) are
       | relative to the properties of the viewing device, the user's OS
       | and browser settings, etc. The author appears to be confusing
       | "physical pixel" with "logical pixel".
        
         | Veen wrote:
         | There is a big blue information box in the article that
         | explains this. It's called "Hardware vs. software pixels".
        
           | naberhausj wrote:
           | I agree with CharlesW here. That information box doesn't
           | mention that a normal grid of pixels can also have a non
           | 1-to-1 mapping between physical and logical pixels. Any
           | discussion of pixels that doesn't specifically call out
           | `window.devicePixelRatio` is not going to give people a
           | complete understanding.
           | 
           | This is important. If you're rendering images/graphics with a
           | pixel as your smallest unit then you're not going to look
           | good on most modern devices.
        
           | CharlesW wrote:
           | Along with talking about very different issues in that aside,
           | the author calls the px unit "a bit of a lie" when in fact
           | CSS pixels have always been logical (not physical) pixels. My
           | editor-hat advice is that the article would benefit from a
           | rewrite of the px explanation, and I'd also recommend
           | eliminating the confusing hardware pixels vs. sub-pixels
           | distinction.
        
         | teg4n_ wrote:
         | Try reading more. He's not confusing anything, he specifically
         | calls out how resolution changes and such effect things.
        
           | CharlesW wrote:
           | I did read the fine article, and this just jumped out at me
           | as something that could be improved.
        
           | CharlesW wrote:
           | I read TFA and am suggesting that this could use a
           | correction. To be charitable, this is a misleading
           | oversimplification and doesn't serve readers.
        
       | mjw1007 wrote:
       | As someone with poor vision, I don't want "make everything
       | bigger", and I don't want "make all the text bigger", I want
       | "make the small text bigger".
       | 
       | (Or, ideally, "make small text and fiddly diagrams bigger, but
       | leave most images alone", but let's walk before we try to run.)
       | 
       | So maybe "rems for body text, px for headings" is the way to go.
        
         | clairity wrote:
         | > "So maybe 'rems for body text, px for headings' is the way to
         | go."
         | 
         | what's probably a little more useful is that headings scale up
         | slower than body text, using different clamp() functions, e.g.,
         | https://www.aleksandrhovhannisyan.com/blog/fluid-type-scale-...
        
         | teg4n_ wrote:
         | Browsers typically support a minimum font size setting.
        
           | mjw1007 wrote:
           | That's not quite the right thing either, alas, because
           | sometimes there's text that's legimately supposed to be
           | "small print" where it's OK if it's hard to read. In practice
           | setting it high tends to go wrong near small buttons.
           | 
           | Ideally what I want in an accessibility-settings dialog is
           | "minimum font size that I can comfortably read", and a way
           | for UI authors to say "this is normal body text".
           | 
           | Instead what we tend to get is blanket advice like Android's
           | "use sp dimensions for text", which simply scales everything
           | up.
           | 
           | iOS's preferredFontFor textStyle stuff seems like the right
           | approach in principle, but they still seem to have the idea
           | that if I want large body text I must also want huge headings
           | (which is terrible, because if I have large body text I also
           | have less space than usual).
        
       | samtimalsina wrote:
       | This is one of the long form frontend blogs that I greatly enjoy,
       | and learn sometime new every time. So, I am excited anytime a new
       | one comes out. I hope with Josh releasing his own course[1], that
       | the blog continues to provide excellent resources for "free".
       | 
       | [1](https://css-for-js.dev/)
        
         | joshwcomeau wrote:
         | Appreciate it :)
         | 
         | And yeah, the plan is to keep providing a bunch of free
         | content, knowing that a small % of people who read the blog
         | will go on to buy the course. Way more sustainable than it used
         | to be, when this was something I did outside of my job.
        
       | teddyh wrote:
       | > _1px is equal to a single dot in a computer monitor or phone
       | screen._
       | 
       | Far from always!
       | 
       | "For screen displays, it traditionally represents one device
       | pixel (dot). However, for _printers and high-resolution screens_
       | , one CSS pixel implies multiple device pixels. 1px = 1/96th of
       | 1in."
       | 
       | -- https://developer.mozilla.org/en-US/docs/Web/CSS/length
        
         | TotempaaltJ wrote:
         | The article does talk about this directly after about the
         | sentence you quoted.
        
           | CharlesW wrote:
           | But the part the parent commenter quoted is incorrect and the
           | article would be better for having that fixed. The
           | explanation that follows is misleading as well (it's not a
           | "bit of a lie") and would also benefit from not introducing
           | hardware sub-pixels into the discussion (which are
           | irrelevant).
        
         | jan_Inkepa wrote:
         | >"For screen displays, it traditionally represents one device
         | pixel (dot). However, for printers and high-resolution screens,
         | one CSS pixel implies multiple device pixels. 1px = 1/96th of
         | 1in."
         | 
         | And this multiple isn't necessarily an integer, it's specified
         | as a floating point number (though I've in practice only seen
         | fractional parts of .5 (on a samsung galaxy IIRC) )
         | 
         | ( https://developer.mozilla.org/en-
         | US/docs/Web/API/Window/devi... )
        
       | beanlog wrote:
       | It'd be more accurate and illuminating to say that a px is an
       | angle.
       | 
       |  _The reference pixel is the visual angle of one pixel on a
       | device with a pixel density of 96dpi and a distance from the
       | reader of an arm's length. For a nominal arm's length of 28
       | inches, the visual angle is therefore about 0.0213 degrees. For
       | reading at arm's length, 1px thus corresponds to about 0.26 mm (1
       | /96 inch)._ - https://www.w3.org/TR/css-values-4/#absolute-
       | lengths
       | 
       | This explains why 1px is small on phones and large on
       | televisions; the physical size varies by expected reader
       | distance. The angle tries to stay constant, though in practice it
       | gets rounded to the nearest multiple of the physical pixel size.
        
       | cyral wrote:
       | It's quite ironic how the font settings page for Chrome doesn't
       | do well with different font sizes itself. They got the sidebar
       | backwards and appeared to have used px for the font-size but em
       | for the padding.
        
       ___________________________________________________________________
       (page generated 2022-05-18 23:01 UTC)