> but the icons break at high zoom levels, then is that accessible?
Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.
Bad usability precludes good accessibility. You seem to be implying that accessibility is just about being able to access the content. That's wrong, accessibility is about ease of access to the content. If what you were saying were true, then semantically correct HTML wouldn't be a WCAG requirement. But semantically correct HTML improves usability for people using assistive technologies, thus it is an important part of designing accessible content. Accessibility IS dependent on usability.
If just the ability to access the content was the only factor in designing accessible content, then you could just tell your blind clients to view the page source and read it character by character. But obviously that would not be acceptable because it creates a significant barrier for usability that sighted clients would not face. Designing accessible content is about removing barriers that make it harder for people with disabilities to access the content, and bad usability is one of those barriers.
> That's wrong, accessibility is about ease of access to the content.
That doesn't account for cognitive disabilities.
Ease of access is up to the user-agent software. Accessibility is more than just that. As front end developers we have to provide that content in a meaningful and understandable form without getting in the browser's or screen reader's way. Sometimes that isn't enough and you need to use ARIA to clarify things more precisely.
> then you could just tell your blind clients to view the page source and read it character by character.
Screen readers provide a variety of navigational tools for drilling into page content. They don't just read text.
I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.
> Screen readers provide a variety of navigational tools for drilling into page content. They don't just read text.
And CSS is also used to provide navigational tools for drilling into page content. For example, putting navigation panels on a sidebar rather than in between the header and the content. That's not just done for aesthetics, it's done to make the information on the page easier to understand. But if your brilliantly-designed page layout breaks when zoomed in, then that is a barrier which disabled people will face that abled people will not. By doing accessibility testing with CSS disabled you will not be able to test the accessibility of such navigational features.
Sure, they could use a screen reader instead, but maybe they don't want to use a screen reader. Maybe page zoom is enough for them normally and that's what they prefer. By not taking accessibility into consideration when creating the visual design of the page, you are basically saying that the visual design of your page is crafted just for the needs of abled people, and disabled people should have to use special tools to access your content. That's inaccessible.
> I am not really sure what you are arguing. You can have great CSS and great accessibility at the same time.
You have my point backwards. I am arguing that you can't have great accessibility with bad CSS. Thus you need to do your accessibility testing with CSS enabled (just like how your clients who have disabilities will be using it).
You are deliberately confusing presentation for semantics, which is discriminatory. The WCAG directly mentions not doing this. You cannot achieve AA conformance when you attempt to force this on your users.
For example red means stop and green means go to many people. When color is the primary means of status description that is discriminatory, because blind people cannot perceive color in any way. The status must be described in some other way equally for all users, but it can be colored red/green by CSS for increased usability. The same goes for page structures like menu bars. The standards even provide examples with ARIA.
CSS is only a factor for people with motor control limitations when interactive controls are too close together to be accessed uniquely with a mouse click. If this is a concern for you have somebody with advanced Parkinson’s usability test your site, otherwise turn CSS off for all other accessibility testing.
> When color is the primary means of status description that is discriminatory, because blind people cannot perceive color in any way. The status must be described in some other way equally for all users
Yes, agreed. That's why you should provide a non-colour-based indicator of the status, AND ALSO make sure the colours work for partially vision impaired people (or colourblind, etc).
If the information is technically accessible, but in an awkward and hard-to-use format compared to the sighted version of that information, then it's not really accessible. Making colourblind people read awkward labels when you could just as easily use colourblind-compatible colours is inaccessible. I am not confusing presentation and semantics, I am just saying that both are involved in creating accessible content.
Yes, it is still accessible, but usability is decreased. There are multiple ways to activate a button. Accessibility and usability are not contested or mutually exclusive qualities. You can have both great CSS and great accessibility at the same time.