[RFC] Establish acceptance criteria for SEO/Accessibility about readme HOT 12 CLOSED

With the set of guidelines in place we are better equipped to make educated decisions when constructing or looking back at pages. I wonder if we should still formalize the concept of acceptance criteria, or what is required to launch a new app, before closing this RFC? I would suggest that we make a minimum score on lighthouse or find some other straightforward metric to ensure that action is taken on confirming SEO requirements are met.

Two suggestions for acceptance criteria:

• Lighthouse score for SEO is 100 or fails only on items outside of project scope
• URL has been run through Live URL testing tool and renders expected data

from readme.

@jonallured good point! Thankfully many SEO and accessibility elements overlap when it comes to page construction, but it is true, you don't need to worry about things like JSONLD or search metadata when working in a CMS. Definitely a good idea to consider these different contexts.

@damassi the checklist in Palette is an excellent example. We will get some cascade when these components are used, but it won't necessarily cover the examples listed above-- Sans supporting h1 blocks is great, but still requires an engineer to know to implement it when creating a page title.

I'm hoping that by spelling out some basic requirements we can spread more awareness around the team, both in terms of considering SEO when building new, as well as when updating old code (to avoid accidentally removing code related to SEO improvements).

from readme.

We haven't switched overt to eslint yet (discussion in the works), but there are some good DX tools that will help with whatever process we adopt, like https://www.npmjs.com/package/eslint-plugin-jsx-a11y and https://github.com/reactjs/react-a11y. (Not sure how interoperable this is with Palette, however -- but it will def help in an audit of our foundation.)

from readme.

I think whenever tooling can help devs make the right choice, it's totally worth pursuing, but our tools change over time. What feels more universal to me is a list of goals regarding SEO and Accessibility. That list can then be enacted by linting rules, etc, but having the list is important either way.

from readme.

Hi all--hear you guys! We've been doing a lot of thinking about SEO best practices and the best way to establish and communicate those. cc @zephraph who was part of a larger conversation yesterday on the topic. Happy to put something together in collaboration with anyone who would like to be involved

from readme.

Another tip that came up in an unrelated meeting, and could be part of any best practices doc/process: Giving unique content prominence in the page, or at least not hiding or truncating it

from readme.

Yeah, good one! Something else here might be some guidance about which pages this should apply to. Like, if I'm working in Volt, SEO isn't really a concern, but accessibility always is!

from readme.

This has already been handled at the Palette level, via our new issue template: see artsy/palette#253 for an example.

Since all new UI is built using palette primitives, things like accessibility will cascade down assuming we're following best practices here.

I think we'll need to audit existing components however; this check-list is fairly new.

from readme.

I've created a set of guidelines that I believe are ready to distribute, but would love to hear any and all feedback before I distribute: https://www.notion.so/artsy/SEO-Accessibility-Guidelines-1b1c12999c994abd9a3a2e8be178489d

from readme.

Just for the record here - in practice meeting today there was a discussion that singe H1/H2 etc is tricky to implement with the way we do responsive design in some cases. The page is rendered separately for bigger and smaller screens so we do end up with duplicated content in some cases even though only one is visible at any given time. Not exactly clear if that is a problem though.

from readme.

@eessex those recommendations seem solid, I'm 👍 on that.

from readme.

Closing this, and will see to implementing the suggested acceptance criteria via another forum.

from readme.