Add Tamil (ta) translation of accessibility best practices guide

[ajaitech]

Translates _articles/accessibility-best-practices-for-your-project.md into Tamil, added at _articles/ta/accessibility-best-practices-for-your-project.md.

This is currently the only article missing from every translation folder in the repo, ta included, so this closes that gap for Tamil readers.

What this change does

• One new file, 301 lines. No existing files are modified.
• Front matter uses lang: ta with a translated title and description. class, order and image are left byte-identical to the English source so the site build, navigation order and social card are unaffected. The source's untranslated: true flag is intentionally not carried over.
• Structure matches the English source exactly: 41 headings at the same levels, 126 list items at the same nesting depths, and all 30 external links preserved with their original targets.
• Translator credit follows the convention already used in _articles/ta/maintaining-balance-for-open-source-maintainers.md (GitHub handle in the Contributors section).

Why it adds value

Accessibility is the one guide with no translations at all, and Tamil has one of the larger developer populations without it. Making this article readable in Tamil lowers the barrier for maintainers who would otherwise skip the topic entirely.

A note on register

This translation is written in colloquial spoken Tamil (Kongu / Coimbatore usage) rather than the formal written register used in the other _articles/ta/ files. That is a deliberate choice rather than an oversight: it reflects how a great many Tamil-speaking developers actually read and talk about this material, and technical terms are left in English as they are in everyday usage.

I'm aware this differs from the existing Tamil articles and I'm very happy to discuss it. If maintainers would prefer consistency across the ta folder, I'll gladly revise toward the formal register.

---

• Have you followed the contributing guidelines?
• Have you explained what your changes do, and why they add value to the Guides?

[ajaitech]

Heads up on the failing tests check. I looked into it and I don't think it's something this PR can fix on its own, so here's what I found in case it's useful.

All 27 failures are broken-link errors of the form /<lang>/accessibility-best-practices-for-your-project/ ... which does not exist.

The source is the hreflang loop in _includes/head.html:

{% if page.lang and page.untranslated != true and site.data.locales.size > 1 %}
...
<link rel="alternate" hreflang="{{ lang }}" href="{{ site.url }}/{{ lang }}{{ default_url }}" />

The loop emits an alternate for every locale in _data/locales without checking whether that translation exists. It has never surfaced before because every locale folder in _articles/ currently carries an identical set of 12 articles. The only exception is accessibility-best-practices-for-your-project.md, which is English-only and shielded by untranslated: true.

This PR adds the first non-English copy of that article, so the block runs for it for the first time: 29 locales, minus en (handled separately and pointing at a page that does exist), minus ta itself, equals exactly the 27 errors reported.

That means any PR translating a new article into one language first will hit this, not just this one.

The natural fix is an existence guard on the non-en branch, reusing the pattern already in _layouts/article.html:

{% assign translated = site.articles | where: 'lang', lang | where: 'class', page.class | first %}
{% if translated %}...{% endif %}

I stopped short of putting that in this PR for two reasons. It's site build logic rather than translation work, and page.class is empty on localized non-article pages, so a naive guard would silently drop hreflang tags that those pages emit correctly today. That tradeoff felt like a maintainer's call rather than mine to make inside a translation PR.

Happy to open a separate PR for the guard, or fold it into this one if you'd prefer to keep them together. Just let me know which you'd rather have.