diff --git a/_articles/ta/accessibility-best-practices-for-your-project.md b/_articles/ta/accessibility-best-practices-for-your-project.md new file mode 100644 index 00000000000..b0bc4b6eace --- /dev/null +++ b/_articles/ta/accessibility-best-practices-for-your-project.md @@ -0,0 +1,301 @@ +--- +lang: ta +title: உங்க Project-க்கான Accessibility Best Practices +description: உங்க open source project-அ எல்லாரும், முக்கியமா மாற்றுத்திறனாளிகள் ஈஸியா யூஸ் பண்றதுக்கான சூப்பரான வழிகள். +class: accessibility-best-practices +order: -1 +image: /assets/images/cards/accessibility-best-practices.png +--- + +Accessibility (அடிக்கடி _a11y_ னு சுருக்கி சொல்வாங்க) அப்படீன்னா, குறைபாடுகள், assistive technology, environment அல்லது device-அ தாண்டி உங்க project-அ எல்லாராலயும் யூஸ் பண்ண முடியணும்ங்க. இதுல screen readers, keyboard-only navigation, captions/transcripts, போதுமான color contrast, அப்புறம் தெளிவான content structure எல்லாமே அடங்குங்க. + +## மாற்றுத்திறனாளிகள் கூட Partner பண்ணுங்க + +**"எங்கள பத்தி எங்களுக்கு இல்லாம எதுவும் இல்ல"** ("Nothing about us without us") - Accessibility-க்காக நீங்க பண்ணக்கூடிய ரொம்ப முக்கியமான விஷயம், அத யூஸ் பண்ற அவிங்கள (people) மையப்படுத்துறது தானுங்க. Guidelines அப்புறம் automated tools-அ விட, மாற்றுத்திறனாளிகளான users, contributors, அப்புறம் testers-க்கு தான் அந்த கஷ்டங்கள் நல்லா புரியும்ங்க. அவங்களோட lived experience-அ சீக்கிரமாவும் அடிக்கடி கேட்டு தெரிஞ்சுக்கோங்க. + +### அத Practice-ல கொண்டு வாங்க + +பாதிக்கப்படுற அவிங்கள கலந்துக்காம எடுக்குற decisions பெரும்பாலும் சரியா வராதுங்க. மாற்றுத்திறனாளிகளுக்காக (for them) உருவாக்குறத விட, அவிங்க கூட சேர்ந்து (with them) உருவாக்குனா, எல்லாமே சூப்பரான software-ஆ வருங்க. + +அவிங்க experience-அ மையப்படுத்துறதுக்கு சில வழிகள் இதோங்க: + +* Contributors வித் disabilities-அ வெறும் bug triage-க்கு மட்டும் இல்லாம, design discussions-லையும் கூப்பிடுங்க. +* உங்களால முடியும்போதெல்லாம் usability testing அப்புறம் feedback-க்கு மாற்றுத்திறனாளிகள involve பண்ணுங்க. +* உங்க project-அ அவிங்க எப்டி யூஸ் பண்றாங்கனு சொல்லும்போது, அது உங்க assumptions-அ மாத்துனா கூட பரவாயில்லனு கொஞ்சம் காது கொடுத்து கேளுங்க. +* Accessibility reports-அ complaints-ஆ பாக்காம expertise-ஆ பாருங்க - நீங்க நெனைக்கிறத விட நிறைய பேர்த்த அத represent பண்ணலாங்க. + +### Accessibility எல்லாருக்கும் லாபமுங்க + +* **இது நெறய பேர்த்த பாதிக்கும்ங்க.** [World Health Organization](https://www.who.int/news-room/fact-sheets/detail/disability-and-health) சொல்றபடி, தோராயமா 1.3 billion மக்கள் (6 ல 1த்தர்) ஏதாவது ஒரு மாற்றுத்திறனோட இருக்காங்க. +* **இது quality-யோட ஒரு பகுதியுங்க.** Accessible products பொதுவாவே எல்லாருக்குமே ஈஸியா யூஸ் பண்ற மாதிரி தானுங்க இருக்கும். +* **இது support load-அ குறைக்கும்ங்க.** தெளிவான UI அப்புறம் docs இருந்தா குழப்பமான users குறைவா இருப்பாங்க. +* **உங்க contributor base-அ பெருசாக்கும்ங்க.** Assistive tech users-உம் இதுல நல்லா participate பண்ண முடியும்ங்க. +* **இது innovation-அ வளர்க்கும்ங்க.** பலவித தேவைகளுக்கு design பண்றப்போ எல்லாரும் பயனடையற மாதிரி features வருங்க (உதாரணத்துக்கு captions, voice control, dark mode எல்லாமே accessibility solutions-ஆ ஆரம்பிச்சது தானுங்க). +* **இது பெரும்பாலும் கட்டாயமுங்க.** பல orgs (அப்புறம் சில governments) procurement அப்புறம் compliance-க்காக accessibility-அ கட்டாயம் கேக்குறாங்க. +* **நம்ம future நிச்சயமில்லாததுங்க.** இன்னைக்கு நமக்கு இருக்கிற திறன்கள் நாளைக்கும் அப்படியே இருக்கும்னு யாருனாலயும் உறுதியா சொல்ல முடியாதுங்க. + +## ஒரு accessibility statement-ஓட ஆரம்பிங்க + +Code-குள்ள குதிக்கிறதுக்கு முன்னாடி, உங்க project-ஓட accessibility commitment-அ document பண்ண கொஞ்சம் டைம் ஒதுக்குங்க. Accessibility-ன்றது சும்மா பின்னாடி யோசிக்கிறது இல்ல, அதான் முக்கியம்னு users-க்கும் contributors-க்கும் ஒரு accessibility statement சொல்லுங்க. Guide-க்கு, [W3C's Developing an Accessibility Statement](https://www.w3.org/WAI/planning/statements/)-அ refer பண்ணுங்க. + +எதிர்பார்ப்புகள செட் பண்ணி, users-க்கு issues report பண்ண ஈஸியா இருக்குற மாதிரி ஒரு clear statement-அ வைங்க. நீங்க உங்க README-லேயே ஒரு accessibility section-அ சேக்கலாங்க, இல்லனா தனியா ஒரு `ACCESSIBILITY.md` file-அ create பண்ணி, எல்லாருக்கும் தெரியுற மாதிரி README-ல இருந்து link பண்ணலாங்க. இந்த [ACCESSIBILITY.md example](https://github.com/open-source-accessibility/accessibility-toolkit/blob/main/ACCESSIBILITY.md)-அ refer பண்ணுங்க. + +### Goals + +* Measurable goals அப்புறம் guidelines-அ சொல்லுங்க (உதாரணத்துக்கு [WCAG AA](https://www.w3.org/TR/WCAG22/#wcag-2-layers-of-guidance) சாத்தியமா இருக்குற இடத்துல). +* உங்க primary priorities, அப்புறம் அத எப்டி மீட் பண்றீங்கனு (keyboard அப்புறம் screen reader support, captions அப்புறம் transcripts, etc.) define பண்ணுங்க. +* ஏதாவது known limitations, அப்புறம் alternative workarounds (இருந்தா) அதையும் define பண்ணுங்க. + +### Contributor requirements + +Contributors-க்கு என்னென்ன expectations இருக்குனு அவிங்களுக்கு தெளிவான guardrails-அ செட் பண்ணுங்க: + +* **Testing:** எல்லா UI changes-உம் ஒரு accessibility testing tool வச்சு (like [Axe DevTools](https://www.deque.com/axe/devtools/extension/#:~:text=Try%20Axe%20DevTools%20Extension%20in%20your%20browser%20of%20choice)) கட்டாயம் test பண்ணிருக்கணுங்க. +* **Documentation:** SVGs, images, அப்புறம் interactive elements-க்கு உங்க project-ஓட accessibility guidelines-அ follow பண்ணுங்க. +* **CI/CD:** Accessibility linting workflow-ல violations ஏதாச்சும் வந்தா PRs fail ஆயிடும்ங்க. + +### Supported environments + +* நீங்க support பண்ற platforms-அ லிஸ்ட் பண்ணுங்க (web, mobile web, iOS, Android, terminal/CLI, desktop apps). +* Partial-support notes ஏதாச்சும் இருந்தா லிஸ்ட் பண்ணுங்க. + +### Accessibility bugs-அ report பண்றது + +* Accessibility issue template-அ யூஸ் பண்ணி issues-அ open பண்ண reporters-கிட்ட கேளுங்க. +* **Tip:** Expectations-அ நேர்மையா செட் பண்ணுங்க (உதாரணத்துக்கு "We're working on this - tracking in ISSUE-123"); reports-அ acknowledge பண்ணுங்க, முடிஞ்சப்போ follow-up இல்லனா workaround குடுங்க. + +#### ஏன் உங்க general issue process-ல இருந்து accessibility-அ தனியா பிரிக்கணுங்க? + +Users தனியா ஒரு accessibility statement அப்புறம் reporting path-அ எதிர்பார்க்க ஆரம்பிச்சுட்டாங்க - இது private sector அப்புறம் government sites-ல ஒரு வழக்கமான convention-ஆ மாறிடுச்சுங்க. ஏதாச்சும் ஒரு barrier வரும்போது பல users முதல அததாங்க தேடுவாங்க. உங்க general issue flow-ல இருந்து accessibility-அ தனியா வச்சிக்கிறது ரொம்ப முக்கியமுங்க ஏன்னா: + +* **Impact time-sensitive ஆனதுங்க.** ஒரு accessibility bug, user-அ கொஞ்சம் தொந்தரவு பண்றதோட நிக்காம, உங்க project-அ யூஸ் பண்ண முடியாதபடி block பண்ணிடுங்க. தனி path வச்சா reported issues-அ சீக்கிரமா triage பண்ண உதவுங்க. +* **Context வேற மாதிரி இருக்குங்க.** Accessibility reported issues-க்கு specific information தேவையுங்க (assistive tech, OS, browser, severity), அத ஒரு generic bug template கேட்காதுங்க. +* **இது commitment-அ காட்டுதுங்க.** ஒரு தனியான, கண்ணுக்கு தெரியுற statement, users அப்புறம் contributors-க்கு accessibility-ங்கிறது first-class concern, "other bugs" குள்ள போடுற விஷயம் இல்லனு காட்டுங்க. +* **Reporters அந்த report-அ file பண்ணவே assistive technology யூஸ் பண்ணலாங்க.** ஒரு clear, predictable process (ஒரு known file, known label, known template) ரொம்ப பாதிக்கப்பட்டவங்களுக்கு ஈஸியா இருக்குங்க. + +## Docs-அ default-ஆ accessible ஆக்குங்க + +Documentation தாங்க users தொடுற முதல் "UI". அத எல்லாராலயும் படிக்க முடியுதான்னு பாத்துக்கோங்க. + +### Structure and semantics + +* ஒரு logical **heading hierarchy**-அ யூஸ் பண்ணுங்க, levels-அ தாண்டிப் போகாதீங்க (`#`, `##`, `###`, `####`, `#####`, and `######`). +* Unique, descriptive **link text**-அ யூஸ் பண்ணுங்க ("click here" னு சொல்லாம "Read the contributing guide" னு சொல்லுங்க). +* **Plain language**-அ யூஸ் பண்ணுங்க, jargon-அ தவிர்த்துடுங்க, அப்புறம் abbreviation-அ முதல் தடவ யூஸ் பண்ணும்போது expand பண்ணுங்க. +* Manual-ஆ நம்பர் போடுறத விட, [**Real lists**](https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax#lists)-அ யூஸ் பண்ணுங்க. +* எல்லாரும் ஈஸியா கண்டுபிடிக்கிற மாதிரி, pages முழுக்க help அப்புறம் navigation-அ ஒரே இடத்துல (consistent locations) வைங்க. +* வெறும் position இல்லனா styling வச்சு மட்டும் meaning convey பண்றத தவிர்த்துடுங்க ("see the red text on the right" அப்டின்னு சொல்லாதீங்க). + +### Images, diagrams and videos + +* Images-க்கு அர்த்தமுள்ள **alternative text** (அடிக்கடி "alt text" னு சுருக்குவாங்க) குடுங்க ([W3C's alt Decision Tree](https://www.w3.org/WAI/tutorials/images/decision-tree/)-அ refer பண்ணுங்க). +* Text இருக்குற images-அ யூஸ் பண்றத விட, முடிஞ்சவரைக்கும் real text-அ யூஸ் பண்ணுங்க. +* Complex images-க்கு (architecture diagrams மாதிரி), பக்கத்துலேயே ஒரு additional text alternative-அ சேருங்க (bullets இல்லனா ஒரு சின்ன explanation). +* நீங்க demos, tutorials, talks, இல்லனா release videos publish பண்ணுனா: + * **Captions** குடுங்க (முடிஞ்ச வரைக்கும் human-edited-ஆ குடுங்க). + * ஒரு **transcript** குடுங்க. + * Audio அப்புறம் video auto-play ஆகுறத தவிர்த்துடுங்க. + * முக்கியமான on-screen actions-அ வாய் வார்த்தையா (verbally) describe பண்ணுங்க. + +### Tables + +* Tables-அ tabular data-க்கு மட்டும் யூஸ் பண்ணுங்க, layout-க்கு வேண்டாங்க. +* Column அப்புறம் row headers-அ data cells-ஓட இணைக்க **header cells** குடுங்க. +* Table-ஓட purpose-அ describe பண்ற மாதிரி ஒரு **caption இல்லனா summary** குடுங்க. + +### Code blocks + +* Lines-அ ரொம்ப நீளமாக்காம பாத்துக்கோங்க (wrapping readability-க்கு உதவுங்க). +* Meaning-அ காட்ட வெறும் color highlighting-அ மட்டும் நம்பி இருக்காதீங்க. +* Code என்ன பண்ணுது அப்புறம் success எப்டி இருக்கும்னு inline-ல explain பண்ணுங்க. + +## Accessible interfaces-அ Design பண்ணுங்க + +உங்க project-ல ஒரு web UI இருந்தா, இந்த high-impact defaults எல்லா users-க்கும் ஹெல்ப் பண்ணும்ங்க. + +### Keyboard support + +* Interactive-ஆ இருக்குற எல்லாமே keyboard only மூலமா reach பண்ணவும் யூஸ் பண்ணவும் முடியணுங்க. +* ஒரு **visible focus indicator** இருக்குறத confirm பண்ணுங்க (focus outlines-அ replace பண்ணாம அத எடுக்காதீங்க). +* Visual layout-க்கு match ஆகுற மாதிரி ஒரு logical **tab order**-அ மெயின்டெயின் பண்ணுங்க. +* நீங்க intentionally focus-அ மேனேஜ் பண்ணி (modal dialogs மாதிரி) வெளிய வர வழி குடுத்தா தவிர, components-குள்ள focus-அ trap பண்ணாதீங்க. + +### Semantics first + +* முடிஞ்சபோதெல்லாம் **native HTML** elements (`

`, `