ENH - Update links styling

docs/_static/custom.css

@@ -1,6 +1,8 @@
 /* Background of stable should be green */
 .version-switcher__container a[data-version-name*="stable"] {
   position: relative;
+  background-color: var(--pst-color-success-bg);
+  box-shadow: inset 3px 0px 0px var(--pst-color-success);
 }
 
 .version-switcher__container a[data-version-name*="stable"] span {
@@ -14,8 +16,6 @@
   position: absolute;
   left: 0;
   top: 0;
-  background-color: var(--pst-color-success);
-  opacity: 0.1;
 }
 
 /* custom CSS classes (used in docs/user_guide/extending.rst) NOTE: the begin

docs/_static/gallery.yaml

@@ -56,9 +56,6 @@
 - title: SEPAL
   website: https://docs.sepal.io/en/latest/index.html
   img-bottom: ../_static/gallery/sepal.png
-- title: EnOSlib
-  website: https://discovery.gitlabpages.inria.fr/enoslib/
-  img-bottom: ../_static/gallery/enoslib.png
 - title: Matplotlib
   website: https://matplotlib.org/stable/
   img-bottom: ../_static/gallery/matplotlib.png

docs/community/topics/accessibility.md

@@ -15,4 +15,6 @@ We run a [Lighthouse](https://developers.google.com/web/tools/lighthouse) job in
 The configuration for Lighthouse can be found in the `.github/workflows/lighthouserc.json` file.
 
 For more information about configuring Lighthouse, see [the Lighthouse documentation](https://github.com/GoogleChrome/lighthouse-ci/blob/main/docs/configuration.md).
-For more information about Accessibility in general, see [](../../user_guide/accessibility.rst).
+For more information about Accessibility in general, see [](../../user_guide/accessibility.md).
+
+We have also recently added automated tests using [Playwright](https://playwright.dev/python/) and [axe-core](https://github.com/dequelabs/axe-core) to improve our accessibility testing and reporting.

docs/user_guide/accessibility.md

@@ -0,0 +1,142 @@
+# Accessibility
+
+Creating and publishing content that does not exclude disabled users is a complex and iterative task.
+
+While there is no one-size-fits-all solution to maintaining accessible content,
+the PyData Sphinx Theme and this documentation site use some techniques to avoid common content shortcomings.
+
+:::{note}
+Issues and pull requests to identify or fix accessibility issues on this theme or site are heartily welcomed!
+:::
+
+## What We've Done
+
+### Metadata
+
+Several of our documentation pages contain metadata (i.e., `.. meta::` directives
+in reStructuredText) giving summaries of the page contents. If you notice a
+page that lacks metadata, please open a pull request to add it!
+
+### Colors
+
+- Our default code highlighting styles are `a11y-high-contrast-light` and
+  `a11y-high-contrast-dark` from https://github.com/Quansight-Labs/accessible-pygments.
+  These styles are designed to meet WCAG 2 AA or AAA contrast requirements.
+  If you don't like the look of our default code highlighting styles, there are several more
+  to choose from at https://github.com/Quansight-Labs/accessible-pygments.
+- We recently revisited the PyData Sphinx theme color palette to ensure that
+  the colors we use meet WCAG 2 AA or AAA contrast requirements.
+- We also re-defined our `primary` and `secondary` colors to be more accessible and distinct from semantic colors used
+  to denote success, warning, info, and danger contexts or information.
+- We simplified the color palette and removed some colors that were problematic in meeting WCAG 2 AA or AAA contrast requirements
+  and for certain types of colorblindness.
+- We have improved how we assign text colors to interactive elements such as buttons and dropdowns to ensure that they meet
+  WCAG 2 AA or AAA contrast requirements.
+
+## What You Can Do
+
+### Site configuration
+
+The following sections include recommendations for settings in the `conf.py` file that can positively impact the
+accessibility of content generated by this theme and Sphinx in general.
+
+### Natural Language
+
+If not using a more robust [internationalization approach](https://www.sphinx-doc.org/en/master/usage/advanced/intl.html),
+specifying at least the baseline natural language will help assistive technology
+identify if the content is in a language the reader understands.
+
+:::{hint}
+In your `conf.py` file, [specifying the language your docs are written in](https://www.sphinx-doc.org/en/master/usage/configuration.html#confval-language) will propagate to the top-level `HTML` tag.
+
+```python
+  language = "en"
+```
+
+:::
+
+### Add a Site Map
+
+Site maps, usually served from a file called `sitemap.xml` are a broadly-employed
+approach to telling programs like search engines and assistive technologies where
+different content appears on a website.
+
+If using a service like [ReadTheDocs](https://readthedocs.com), these files
+will be created for you _automatically_, but for some other approaches below,
+it's handy to generate a `sitemap.xml` locally or in CI with a tool like
+[sphinx-sitemap](https://pypi.org/project/sphinx-sitemap/).
+
+:::{hint}
+
+For a simple site (no extra languages or versions), ensure `sphinx-sitemap`
+is installed in your documentation environment, and modify your `conf.py`:
+
+```python
+    extensions += ["sphinx_sitemap"]
+
+    html_baseurl = os.environ.get("SPHINX_HTML_BASE_URL", "http://127.0.0.1:8000/")
+    sitemap_locales = [None]
+    sitemap_url_scheme = "{link}"
+```
+
+:::
+
+### Logo best practices
+
+If you use both light and dark themes, it's best to provide a logo that works well in both or to provide an alternative for the dark theme.
+If you have a logo, you can add alt-text to it by adding the following to your
+`conf.py`:
+
+```python
+  "logo": {
+      "text": "PyData Theme",
+      "image_dark": "_static/logo-dark.svg",
+      "alt_text": "PyData Theme home",
+  },
+```
+
+Note the use of "home" in the alt text to indicate that the logo is also a link to the home page.
+
+### In the Browser
+
+Several in-browser tools exist for interactively debugging the accessibility
+of a single page at a time and can be useful during the content development cycle.
+
+### Built-in tools
+
+Most major browsers, including [Firefox](https://developer.mozilla.org/en-US/docs/Tools/Accessibility_inspector)
+and [Chrome](https://developers.google.com/web/tools/chrome-devtools/accessibility/reference),
+have accessibility tools built-in as part of their web developer tools.
+These tools can help to quickly identify accessibility issues and often include links to standards.
+
+#### tota11y
+
+[tota11y](https://khan.github.io/tota11y/#Installation) is an open source
+"bookmarklet" which modifies the currently-loaded page in place and highlights
+several accessibility issues.
+
+#### WAVE
+
+[WAVE](https://wave.webaim.org/extension/) is a proprietary (but _gratis_)
+browser extension which can highlight multiple issues.
+
+:::{warning}
+Note that automated testing and extensions such as the ones mentioned above will at best catch 30-40% of accessibility issues.
+They are not a replacement for manual testing and having a perfect score on any of these tools does not mean that
+the site can be used by disabled users but instead signals that it follows some accessibility best practices.
+:::
+
+### In Continuous Integration
+
+Several automated tools are available for assessing _glaring_ accessibility
+issues across some pages at once, usually with many configurable options.
+
+#### Lighthouse
+
+[Lighthouse](https://developers.google.com/web/tools/lighthouse) provides an automated assessment of basic accessibility issues in addition to search engine
+automation, page performance, and other best practices.
+
+:::{hint}
+Specifically, [foo-software/lighthouse-check-action](https://github.com/foo-software/lighthouse-check-action)
+is run on selected pages from the generated documentation site.
+:::