Ensuring All font-size are set in px

[jpdevries]

waving the 🏳 on WCAG 2.0 1.4.4, WCAG 2.1 1.4.11, and Chrome's font-size preference

This PR proposes that if we are going to go against WCAG, and set font size in declarative units which causes font size preferences not to be respected, we should do so across the board.

User Story

• As a web user, who may be low vision, I should be able to update my Font Size preferences in Chrome and have my preference reflected across all, or none, of the type one would expect to scale on the page.

Consistency is a fundamental part of typography. It's fine to not end paragraphs with a period, or use double spaces, as long as you do so everywhere. So, if we are going to take away a user's ability to scale type with their font size setting we should be consistent about it.

Rhythm is another fundamental aspect of typography. When only some of the expected type scales, it blows our layout up and makes the page "off beat".

The Issue

Browsers default font size for content to relative units. When updating your font size preference Chrome will not scale elements with font size set in pixels. It is unexpected to the user for only some of the type to scale. So either it should all be set with retaliative units, or none of it should be.

if a user sets a preference there (Extra Large for example) it won’t have any effect on text content specified with pixels

Notice the labels are the only thing that scale when I change my browser preference. This is because they default to em units.

This is why if you are going to set some type in px you should set all type in px. Otherwise it will have unexpected affects on the user.

Conclusion

I'd much rather this PR serve as an example of why every browser uses relative units for font size, and why we should respect font size preferences, but if it does not we should at least be consistent in removing support for the font size preference.

See Also

• Relative Layout (em) #3

[olexpono]

Comments in #3

[olexpono]

TO BE CLEAR, as I read both of those WCAG and related entries in the UA guidelines, I don't think support of the font-size setting is necessary; it is sufficient to support zoom. Obviously, it would be "optimal" to support both in one scaling system, but it just doesn't seem like something we should get students stuck on within the first month of them learning to code.

In that respect, I think " 🏳️ on WCAG " like we've abandoned it, is hyperbolic.

@benjaminEwhite please merge. Let me know if you have any q's about JP and I's argument etc.

[jpdevries]

I meant I am waiving the flag on trying to get responsive and accessible typography, along with satisfying user expectations of web pages responding to their legibility settings, into the curriculum. I wouldn't suggest we are "abandoning WCAG". We can't abandon something we haven't adopted yet.

Users expect pages to respond to their agent in a multitude of ways. WCAG was written partly to guide us towards doing so. WCAG authors and the collective a11y community have expressed the importance of using relative CSS units since CSS units. So many developers ignored best practices (at the time they were doing so px didnt zoom and it was a blatant violation) browser vendors made a breaking change. Poor habits forced them to do so because the web was broken. Just like later on with disabling pinch zoom, poor practices in the wild forced vendors to make a breaking change.

So those poor habits, and how modern browsers have adapted to combat them, don't satisfy the WCAG. They undermine them. If a page inhibits the use of the user agent, such as legibility settings, regardless of other behavior, it is going against WCAG and with the momentum of poor practice.

[benjaminEwhite]

To be honest, I don't have time to get into the nitty gritty of this back and forth. Here are my high level observations:

• The diff to convo about the diff ratio here is excessive.

    label, p {
        font-size: 16px;
    }

  ^^ vs. a novel (or at least a novella) of conversation about this change.

• From the student perspective, the impact of making ^^ change (or not making it) are literally nil. There's no accompanying discussion of a11y here. And if the student actually could piece together the a11y implications, they would already be an expert on a11y.

• @jpdevries you're the de facto a11y expert for Thinkful, so I have no doubt that what you're proposing is right in terms of creating an accessible interface. That said, there's a difference between creating accessible interfaces, and teaching them. We're not helping anyone by sneaking in a11y without actually teaching it.

• all that said, I think it's fine to merge this PR because it's innocuous enough. Even if students do look at the CSS here, they won't have a feeling either way about setting this font-size. But I think there should be no illusions: this PR changes literally nothing in terms of student experience and learning.

FWIW, Elias Mason is working on a revision to Unit 1 Lesson 2 of web-dev-001 that will explicitly teach basic a11y topics. You can see high level outline here. I don't think this revision will get into the intricacies of font-sizing because it's too much conceptual overhead at once, but it will provide a conceptual foundation that we can expand in phase 2 of web dev bootcamp.

[jpdevries]

We're not helping anyone by sneaking in a11y without actually teaching it.

I completely agree.

But I think there should be no illusions: this PR changes literally nothing in terms of student experience and learning.

Perhaps it should mention that browsers default to relative units for <label> and <p> but since we are using px in our design, we use the cascade to override that behavior for consistency? The point is to teach them to be mindful and consistent of how they use CSS units.

[jpdevries]

The diff to convo about the diff ratio here is insane.

You've specifically asked for accessibility and progressive enhancement to be more present yet when these important discussions arise you refer to them as "insane"? I don't appreciate that.

This is an open source repository. I am verbose so that these issue can also serve as a reference to students, so they can come to informed conclusions on their own; not just for you to call my efforts, and expertise, crazy around the water cooler.

@benjaminEwhite when discussing accessibility it is probably best to avoid words like "insane" as, particularly within the disabled community, they are considered ableist slurs:

• http://www.patheos.com/blogs/lovejoyfeminism/2015/09/no-ableist-slurs-please.html
• http://isthisableism.tumblr.com/sluralternatives

I think it is also unfortunate to reduce a discussion on accessibility and WCAG to three lines of CSS. The topic isn't "the diff", it is legibility as it relates to the user agent and progressive enhancement. We both know there is a lot of progress to be made in these areas, let us try and get by without insulting one another.

[benjaminEwhite]

Changed insane to excessive, which is more accurate.

Want to reiterate in as strong as possible terms that teaching a11y is a big priority moving forward. What i'm pointing out is that there's a mismatch between the passion for that vis-a-vis this repo (which is meant to play a particular role in the learning path) vs. the actual student facing impact.

@jpdevries i in no way meant to characterize you as crazy for bringing your passion for a11y to the fore. I was trying to characterize the overall conversation going on here as excessive vis-a-vis its impact to our students. And as I work remotely there's no water cooler pals for me to talk to :)

My basic worry is that time and effort is being spent in the cause of teaching a11y that will have little to no impact to our students. It feels like we're addressing the underlying issue by having an in depth conversation about a three line change to CSS, but in fact, there's no student facing impact.

I think our primary concern with a11y needs to be with how to most effectively and efficiently teach it to our students, paying special attention to how it fits in with other concepts, and being mindful of conceptual overload. That's has to be the litmus test for any a11y related changes we make to code samples and text in our curriculum. And it's specifically this litmus test that's informing the aforementioned revisions to the introductory HTML lesson that Elias is making.

In short, I think we're all aligned on the outcome we want: namely, our students to be aware of and use a11y best practices.

Where we're less aligned, it seems, is on the best way to get there.

Let's try to be rigorous in thinking about how code examples relate to the curriculum they're consumed with, and their sequencing in an overall learning journey that involves learning a large number of hefty concepts in a short period of time (in other words, repos like this one should not be thought of as stand alone entities, they have a context and pedagogical purpose, and that's critical to understanding student facing impact).

[jpdevries]

Where we're less aligned, it seems, is on the best way to get there.

The logistics of how we get there are above my pay grade. I do think there would be less friction in getting there if, as an organization, we refrained from baking assumptions made on the user's behalf into our materials.

For example:

"Font size settings don't matter because people can use browser zoom now"

That is an assumption that does not let the user, or the user agent, speak for themselves. Why is it that we have been more complicit in assuming parts of the spec are not helpful to users than we are with coming to terms with the fact that they are useful to some users?

Some users… How many users? Does that matter? Why do we ask for statistics on how many assistive tech users are in the wild? To imply that there is an acceptable threshold to leave disabled users behind implies that the web is not for everyone. If we embrace the founding principle that the web is for everyone then whether a user group is 5% or 10% of an audience is completely irrelevant.

I'm sure we can agree that particularly on mobile, pinch zoom or other forms of zooming to enlarge text may introduce "horizontal scrolling". Here is the working group's stance on horizontal scrolling:

As a committee, we believe there is no acceptable amount of horizontal
scrolling.

And here is a mathematical study on the cost of scrolling vs word wrapping (in other words zooming vs enlarging text size)

@tholex to speak specifically to your assumption that modern browser zoom satisifes success criteria:

It is in light of this computation the Low Vision Task Forced resolved on 9
Feb 2017 that enlargement without word wrapping is not accessibility
support. The vote was unanimous.

Zooming does not trigger word wrapping, it triggers horizontal scrolling on mobile. Increasing font size correctly triggers word wrapping and no (horizontal) scrolling.