From 218934fa2ed1c702a6d3923d2aa2cc6b43c48684 Mon Sep 17 00:00:00 2001 From: Peter Bengtsson Date: Tue, 8 Dec 2020 14:43:23 -0500 Subject: initial commit --- files/tr/web/accessibility/index.html | 77 +++++++++++++++++++ .../accessibility/understanding_wcag/index.html | 59 +++++++++++++++ .../understanding_wcag/keyboard/index.html | 87 ++++++++++++++++++++++ 3 files changed, 223 insertions(+) create mode 100644 files/tr/web/accessibility/index.html create mode 100644 files/tr/web/accessibility/understanding_wcag/index.html create mode 100644 files/tr/web/accessibility/understanding_wcag/keyboard/index.html (limited to 'files/tr/web/accessibility') diff --git a/files/tr/web/accessibility/index.html b/files/tr/web/accessibility/index.html new file mode 100644 index 0000000000..ff844f6a40 --- /dev/null +++ b/files/tr/web/accessibility/index.html @@ -0,0 +1,77 @@ +--- +title: Accessibility +slug: Web/Accessibility +translation_of: Web/Accessibility +--- +

Accessibility (often abbreviated to A11y—as in "a" then 11 characters then "y") in Web development means enabling as many people as possible to use Web sites, even when those people's abilities are limited in some way.

+ +

For many people, iş fikirleri technology makes things easier. For people with disabilities, technology makes things possible. Accessibility means developing content to be as accessible as possible no matter an individual's physical and cognitive abilities and no matter how they access the web.

+ +

"The Web is fundamentally designed to work for all people, whatever their hardware, software, language, culture, location, or physical or mental ability. When the Web meets this goal, it is accessible to people with a diverse range of hearing, movement, sight, and cognitive ability." {{ Ref(1) }}

+ +
+
+

Key tutorials

+ +

The MDN Accessibility Learning Area contains modern, up-to-date tutorials covering accessibility essentials:

+ +
+
What is accessibility?
+
This article starts off the module with a good look at what accessibility actually is — this includes what  Türk telekom bayiliği almak groups of people we need to consider and why, what tools different people use to interact with the Web, and how we can make accessibility part of our web development workflow.
+
HTML: A good basis for accessibility
+
A great deal of web content can be made accessible just by making sure the correct HTML elements are used for the correct purpose at all times. This article looks in detail at how HTML can be used to ensure maximum accessibility.
+
CSS and JavaScript accessibility best practices
+
CSS and JavaScript, when used properly, also have the potential to allow for accessible web experiences ... or they can significantly harm accessibility if misused. This article outlines some CSS and JavaScript best practices that should be considered to ensure even complex content is as accessible as possible.
+
WAI-ARIA basics
+
Following on from the previous article, sometimes making complex UI controls that involve unsemantic HTML and dynamic JavaScript-updated content can be difficult. WAI-ARIA is a technology that can help with such problems by adding in further semantics that browsers and assistive technologies can recognize and use to let users know what is going on. Here we'll show how to use it at a basic level to improve accessibility.
+
Accessible multimedia
+
Another category of content that can create accessibility problems is multimedia — video, audio, and image content need to be given proper textual alternatives so they can be understood by assistive technologies and their users. This article shows how.
+
Mobile accessibility
+
With web access on mobile devices being so popular, and popular platforms such as iOS and Android having fully-fledged accessibility tools, it is important to consider the accessibility of your web content on these platforms. This article looks at mobile-specific accessibility considerations.
+
+
+ +
+

Other documentation

+ +
+
Understanding the Web Content Accessibility Guidelines
+
+

This set of articles provides quick explanations to help you understand the steps that need to be taken to conform to the recommendations outlined in the W3C Web Content Accessibility Guidelines 2.0 (WCAG 2.0 or just WCAG, for the purposes of this writing).

+
+
Keyboard-navigable JavaScript widgets
+
Until now, web developers who want to make their styled <div> and <span> based widgets  have lacked the proper techniques. Keyboard accessibility is part of the minimum accessibility requirements which a developer should be aware of.
+
ARIA
+
A collection of articles to learn how to use ARIA to make your HTML documents more accessible.
+
Assistive technology (AT) development
+
A collection of articles intended for AT developers
+
Mobile accessibility checklist
+
This document provides a concise checklist of accessibility requirements for mobile app developers.
+
Cognitive accessibility
+
When creating web content, be aware of how you can ensure that it is accessible to people cognitive impairments.
+
Accessibility for seizure disorders
+
Some types of visual web content can induce seizures in people with certain brain disorders. Understand the types of content that can be problematic, and find tools and strategies to help you avoid them.
+
+
+ +

View all articles about Accessibility...

+
+ + +


+  

+
+ +

{{ endnote(1) }} W3C - Accessibility

+ +

See also

+ + + + diff --git a/files/tr/web/accessibility/understanding_wcag/index.html b/files/tr/web/accessibility/understanding_wcag/index.html new file mode 100644 index 0000000000..fe71b20ebc --- /dev/null +++ b/files/tr/web/accessibility/understanding_wcag/index.html @@ -0,0 +1,59 @@ +--- +title: Understanding the Web Content Accessibility Guidelines +slug: Web/Accessibility/Understanding_WCAG +tags: + - NeedsTranslation + - TopicStub + - WCAG + - Web Content Accessibility Guidelines +translation_of: Web/Accessibility/Understanding_WCAG +--- +

This set of articles provides quick explanations to help you understand the steps that need to be taken to conform to the recommendations outlined in the W3C Web Content Accessibility Guidelines 2.0 or 2.1 (or just WCAG, for the purposes of this writing).

+ +

The WCAG 2.0 and 2.1 provide a detailed set of guidelines for making web content more accessible to people with a wide variety of disabilities. It is comprehensive but incredibly detailed, and quite difficult to gain a rapid understanding of. For this reason, we have summarised the practical steps you need to take to satisfy the different recommendations, with further links to more details where required.

+ +

The four principles

+ +

WCAG is broadly broken down into four principles — major things that web content must be to be considered accessible (see Understanding the Four Principles of Accessibility for the WCAG definitions).

+ +

Each of the links below will take you to pages that further expand on these areas, giving you practical advice on how to write your web content so it conforms to the success criteria outlined in each of the WCAG 2.0 and 2.1 guidelines that further sub-divides each principle.

+ + + +

Should I use WCAG 2.0 or 2.1?

+ +

WCAG 2.1 is the most recent and relevant accessibility standard. Use WCAG 2.1 to help more people with disabilities and reduce the future legal risk for web site owners. Target WCAG 2.0 first when allocating resources. Then step up to WCAG 2.1. 

+ +

What is WCAG 2.1?

+ +

WCAG 2.1 was published as an official recommendation on 05 June 2018. The European Union (EU) adopted WCAG 2.1 as the digital accessibility standard in September 2018. W3C published a press release WCAG 2.1 Adoption in Europe. 

+ +

WCAG 2.1 includes:

+ + + + + +

This guide is intended to provide practical information to help you build better, more accessible websites. However, we are not lawyers, and none of this constitutes legal advice. If you are worried about the legal implications of web accessibility, we'd recommend that you check the specific legislation governing accessibility for the web/public resources in your country or locale, and seek the advice of a qualified lawyer.

+ +

What is accessibility? and particularity the Accessibility guidelines and the law section provide more related information.

diff --git a/files/tr/web/accessibility/understanding_wcag/keyboard/index.html b/files/tr/web/accessibility/understanding_wcag/keyboard/index.html new file mode 100644 index 0000000000..32705d664f --- /dev/null +++ b/files/tr/web/accessibility/understanding_wcag/keyboard/index.html @@ -0,0 +1,87 @@ +--- +title: Keyboard +slug: Web/Accessibility/Understanding_WCAG/Keyboard +translation_of: Web/Accessibility/Understanding_WCAG/Keyboard +--- +
To be fully accessible, a web page must be operable by someone using only a keyboard to access and control it. This includes users of screen readers, but can also include users who have trouble operating a pointing device such as a mouse or trackball, or whose mouse is not working at the moment, or who simply prefer to use a keyboard for input whenever possible.
+ +

Focusable elements should have interactive semantics

+ +

If an element can be focused using the keyboard, then it should be interactive; that is, the user should be able to do something to it and produce a change of some kind (for example, activating a link or changing an option).

+ +
+

Note: One important exception to this rule is if the element has role="document" applied to it, inside an interactive context (such as role="application"). In such a case, focusing the nested document is the only way of returning assistive technology to a non-interactive state (often called "browse mode").

+
+ +

Most interactive elements are focusable by default; you can make an element focusable by adding a tabindex=0 attribute value to it. However, you should only add tabindex if you have also made the element interactive, for example, by defining appropriate event handlers keyboard events.

+ +

See also

+ + + +

Avoid using tabindex attribute greater than zero

+ +

The tabindex attribute indicates that an element is focusable using the keyboard. A value of zero indicates that the element is part of the default focus order, which is based on the ordering of elements in the HTML document. A positive value puts the element ahead of those in the default ordering; elements with positive values are focused in the order of their tabindex values (1, then 2, then 3, etc.).

+ +

This creates confusion for keyboard-only users when the focus order differs from the logical order of the page. A better strategy is to structure the HTML document so that focusable elements are in a logical order, without the need to re-order them with positive tabindex values.

+ +

See also

+ + + +

Clickable elements must be focusable and should have interactive semantics

+ +

If an element can be clicked with a pointing device, such as a mouse, then it should also be focusable using the keyboard, and the user should be able to do something by interacting with it.

+ +

An element is clickable if it has an onclick event handler defined. You can make it focusable by adding a tabindex=0 attribute value to it. You can make it operable with the keyboard by defining an onkeydown event handler; in most cases, the action taken by event handler should be the same for both types of events.

+ +

See also

+ + + +

Interactive elements must be able to be activated using a keyboard

+ +

If the user can interact with an element using touch or a pointing device, then the element should also support interacting using the keyboard. That is, if you have defined event handlers for touch or click events, you should also define them for keyboard events. The keyboard event handlers should enable the effectively the same interaction as the touch or click handlers.

+ +

See also

+ + + +

Interactive elements must be focusable

+ +

If the user can interact with an element (for example, using touch or a pointing device), then it should be focusable using the keyboard. You can make it focusable by adding a tabindex=0 attribute value to it. That will add the element to the list of elements that can be focused by pressing the Tab key, in the sequence of such elements as defined in the HTML document.

+ +

See also

+ + + +

Focusable element must have focus styling

+ +

Any element that can receive keyboard focus should have visible styling that indicates when the element is focused. You can do this with the :focus CSS pseudo-class.

+ +

Standard focusable elements such as links and input fields are given special styling by the browser by default, so you might not need to specify focus styling for such elements, unless you want the focus styling to be more distinctive.

+ +

If you create your own focusable components, be sure that you also define focus styling for them.

+ +

See also

+ + -- cgit v1.2.3-54-g00ecf