From 4477ff4b11afb851af492c07e42f0792a0a976d0 Mon Sep 17 00:00:00 2001 From: "Queen Vinyl Da.i'gyu-Kazotetsu" Date: Sun, 9 Jul 2023 08:23:33 -0700 Subject: [PATCH] pt-br: remove untranslated/partially translated files (#14099) --- files/pt-br/_redirects.txt | 5 - .../accessibility/css_and_javascript/index.md | 355 -------------- .../writing_style_guide/index.md | 451 ------------------ .../syntax-highlighting-menu.png | Bin 7576 -> 0 bytes .../writing_style_guide/tag-interface.png | Bin 9940 -> 0 bytes .../firefox/experimental_features/index.md | 80 ---- .../mozilla/firefox/releases/50/index.md | 123 ----- .../mozilla/firefox/releases/57/index.md | 237 --------- .../document/getelementsbytagname/index.md | 108 ----- files/pt-br/web/api/keyboardevent/index.md | 234 --------- .../using_service_workers/index.md | 442 ----------------- files/pt-br/web/css/@keyframes/index.md | 131 ----- .../web/css/background-position/index.md | 146 ------ files/pt-br/web/css/border-radius/index.md | 158 ------ 14 files changed, 2470 deletions(-) delete mode 100644 files/pt-br/learn/accessibility/css_and_javascript/index.md delete mode 100644 files/pt-br/mdn/writing_guidelines/writing_style_guide/index.md delete mode 100644 files/pt-br/mdn/writing_guidelines/writing_style_guide/syntax-highlighting-menu.png delete mode 100644 files/pt-br/mdn/writing_guidelines/writing_style_guide/tag-interface.png delete mode 100644 files/pt-br/mozilla/firefox/experimental_features/index.md delete mode 100644 files/pt-br/mozilla/firefox/releases/50/index.md delete mode 100644 files/pt-br/mozilla/firefox/releases/57/index.md delete mode 100644 files/pt-br/web/api/document/getelementsbytagname/index.md delete mode 100644 files/pt-br/web/api/keyboardevent/index.md delete mode 100644 files/pt-br/web/api/service_worker_api/using_service_workers/index.md delete mode 100644 files/pt-br/web/css/@keyframes/index.md delete mode 100644 files/pt-br/web/css/background-position/index.md delete mode 100644 files/pt-br/web/css/border-radius/index.md diff --git a/files/pt-br/_redirects.txt b/files/pt-br/_redirects.txt index 03eef4f3c784f5..30a8fb2bb3e3a5 100644 --- a/files/pt-br/_redirects.txt +++ b/files/pt-br/_redirects.txt @@ -381,7 +381,6 @@ /pt-BR/docs/JavaScript/Reference/Statements/let /pt-BR/docs/Web/JavaScript/Reference/Statements/let /pt-BR/docs/JavaScript/uma_reintroduction_ao_JavaScript /pt-BR/docs/Web/JavaScript/Language_overview /pt-BR/docs/Learn/Accessibility/Acessibilidade_problemas /pt-BR/docs/Learn/Accessibility/Accessibility_troubleshooting -/pt-BR/docs/Learn/Accessibility/CSS_e_JavaScript /pt-BR/docs/Learn/Accessibility/CSS_and_JavaScript /pt-BR/docs/Learn/CSS/CSS_layout/Fluxo_Normal /pt-BR/docs/Learn/CSS/CSS_layout/Normal_Flow /pt-BR/docs/Learn/CSS/CSS_layout/Intro_leiaute_CSS /pt-BR/docs/Learn/CSS/CSS_layout/Introduction /pt-BR/docs/Learn/CSS/CSS_layout/Layout_de_varias_colunas /pt-BR/docs/Learn/CSS/CSS_layout/Multiple-column_Layout @@ -442,7 +441,6 @@ /pt-BR/docs/Localização /pt-BR/docs/Glossary/Localization /pt-BR/docs/MDN/About /pt-BR/docs/MDN/Writing_guidelines /pt-BR/docs/MDN/Contribute/Content /pt-BR/docs/conflicting/MDN/Writing_guidelines -/pt-BR/docs/MDN/Contribute/Content/Style_guide /pt-BR/docs/MDN/Writing_guidelines/Writing_style_guide /pt-BR/docs/MDN/Contribute/Estruturas /pt-BR/docs/conflicting/MDN/Writing_guidelines/Page_structures /pt-BR/docs/MDN/Contribute/Estruturas/Compatibility_tables /pt-BR/docs/MDN/Writing_guidelines/Page_structures /pt-BR/docs/MDN/Contribute/Estruturas/Macros /pt-BR/docs/conflicting/MDN/Writing_guidelines/Page_structures_978c99f4f82eae196d51ce675e5181c7 @@ -469,8 +467,6 @@ /pt-BR/docs/MDN/Contribute/guia/Create_an_interactive_exercise_to_help_learning_the_web/distant_example /pt-BR/docs/conflicting/MDN/Contribute/Howto/Create_an_interactive_exercise_to_help_learning_the_web /pt-BR/docs/MDN/Feedback /pt-BR/docs/MDN/Community /pt-BR/docs/MDN/Guidelines /pt-BR/docs/conflicting/MDN/Writing_guidelines -/pt-BR/docs/MDN/Guidelines/Style_guide /pt-BR/docs/MDN/Writing_guidelines/Writing_style_guide -/pt-BR/docs/MDN/Guidelines/Writing_style_guide /pt-BR/docs/MDN/Writing_guidelines/Writing_style_guide /pt-BR/docs/MDN/Kuma /pt-BR/docs/orphaned/MDN/Yari /pt-BR/docs/MDN/Primeiros_Passos /pt-BR/docs/MDN/Community/Contributing/Getting_started /pt-BR/docs/MDN/Structures /pt-BR/docs/conflicting/MDN/Writing_guidelines/Page_structures @@ -492,7 +488,6 @@ /pt-BR/docs/Mozilla/Add-ons/WebExtensions/pre-requisitos /pt-BR/docs/Mozilla/Add-ons/WebExtensions/Prerequisites /pt-BR/docs/Mozilla/Add-ons/WebExtensions/sua_primeira_WebExtension /pt-BR/docs/Mozilla/Add-ons/WebExtensions/Your_first_WebExtension /pt-BR/docs/Mozilla/Add-ons/WebExtensions/user_interface/Itens_do_menu_de_contexto /pt-BR/docs/Mozilla/Add-ons/WebExtensions/user_interface/Context_menu_items -/pt-BR/docs/Mozilla/Firefox/Novas_funcionalidades /pt-BR/docs/Mozilla/Firefox/Experimental_features /pt-BR/docs/Mozilla/Firefox/Releases/3/Zoom_de_página_inteira /pt-BR/docs/Mozilla/Firefox/Releases/3/Full_page_zoom /pt-BR/docs/Quirks_Mode_and_Standards_Mode /pt-BR/docs/Web/HTML/Quirks_Mode_and_Standards_Mode /pt-BR/docs/SVG /pt-BR/docs/Web/SVG diff --git a/files/pt-br/learn/accessibility/css_and_javascript/index.md b/files/pt-br/learn/accessibility/css_and_javascript/index.md deleted file mode 100644 index 22d3676216f712..00000000000000 --- a/files/pt-br/learn/accessibility/css_and_javascript/index.md +++ /dev/null @@ -1,355 +0,0 @@ ---- -title: CSS e JavaScript - melhores práticas de acessibilidade -slug: Learn/Accessibility/CSS_and_JavaScript -original_slug: Learn/Accessibility/CSS_e_JavaScript ---- - -{{LearnSidebar}}{{PreviousMenuNext("Learn/Accessibility/HTML","Learn/Accessibility/WAI-ARIA_basics", "Learn/Accessibility")}} - -CSS e JavaScript, quando usados de maneira correta, têm também potencial para permitir experiências web acessíveis... ou podem causar danos significativos se usados de forma indevida. Este artigo descreve algumas das melhores práticas em CSS e JavaScript a serem consideradas para garantir que até mesmo conteúdos complexos estejam tão acessíveis quanto possível. - - - - - - - - - - - - -
Pré-requisitos: - Conhecimento básico de computação, Conhecimento básico de HTML, CSS, e - JavaScript, e entendimento sobre - o que é acessibilidade. -
Objetivo: - Tornar-se familiarizado com o uso de CSS e JavaScript apropriadamente em - seus documentos web para maximizar a acessibilidade e não diminuir sua - importância. -
- -## CSS e JavaScript são acessíveis? - -CSS e JavaScript não têm a mesma importância imediata que o HTML, mas eles continuam sendo capazes de ajudar ou causar danos à acessibilidade, dependendo de como são usados. Ou seja, é importante que você considere algumas das melhores práticas para assegurar que o seu uso de CSS e JavaScript não danifiquem a acessibilidade de seus documentos. - -## CSS - -Vamos começar dando uma olhada no CSS. - -### Semântica correta e expectativas do usuário - -É possível usar CSS para fazer qualquer elemento HTML se parecer com qualquer coisa, mas isso não quer dizer que você deve. Como frequentemente mencionado no nosso artigo [HTML: Uma boa base para acessibilidade](/pt-BR/docs/Learn/Accessibility/HTML), você deve utilizar a semântica apropriada do elemento para determinada tarefa, sempre que possível. Se não o fizer, isso poderá acarretar confusão e problemas de usabilidade para todos, particularmente para usuários portadores de deficiência. Utilizar uma semântica correta tem muito a ver com as expectativas do usuário — elementos se parecem e se comportam de certas maneiras, de acordo com suas funcionalidades, e essas convenções são esperadas pelos usuários. - -Por exemplo, um usuário utilizando um leitor de tela não consegue navegar por uma página através de elementos de heading se o desenvolvedor não tiver usado apropriadamente estes elementos para marcação do conteúdo. Da mesma forma, um heading perde o seu propósito visual se você estilizá-lo de maneira que ele não se pareça com um heading. - -A regra de ouro é que você pode atualizar o estilo de recurso de página para se adequar ao seu design, mas não o altere tanto ao ponto de não mais se parecer ou se comportar como o esperado. As sessões que se seguem resumem os principais recursos HTML a serem considerados. - -#### Estrututa "standard" de conteúdo textual - -Headings, parágrafos, listss — o núcleo do conteúdo textual da sua página: - -```html -

Heading

- -

Parágrafo

- - -``` - -Um código CSS típico pode se parecer com isso: - -```css -h1 { - font-size: 5rem; -} - -p, li { - line-height: 1.5; - font-size: 1.6rem; -} -``` - -Você tem de: - -- Selecionar tamanhos de fonte sensíveis, altura de linhas, espaçamento entre letras, etc. para fazer com que o seu texto seja lógico, legível e de leitura confortável. -- Tenha certeza que os seus headings se destaquem do corpo do seu texto, geralmente grande e em negrito conforme o estilo padrão. -- A cor do seu texto deve ter um bom contraste com a cor de fundo. - -Veja [HTML fundamentos de texto](/pt-BR/docs/Learn/HTML/Introduction_to_HTML/HTML_text_fundamentals) e [Estilizando texto](/pt-BR/docs/Learn/CSS/Styling_text) para maiores informações. - -#### Texto em negrito - -Elemento de marcação que confere ênfase específica ao texto envolvido por ele: - -```html -

A água está muito quente.

- -

Gotículas de água em superfícies são chamadas de condensação.

-``` - -Você pode querer adicionar alguma cor no seu texto em negrito: - -```css -strong, em { - color: #a60000; -} -``` - -De qualquer forma, você raramente irá precisar de estilizar um elemento de ênfase. As convenções para texto em negrito e itálico são bastante reconhecidas e alterar seu estilo pode causar confusão. Para saber mais sobre elemento ênfase (negrito), veja [Emphasis and importance](/pt-BR/docs/Learn/HTML/Introduction_to_HTML/HTML_text_fundamentals#Emphasis_and_importance). - -#### Abreviações - -É um elemento que permite abreviação, acrônimo ou inicialização que esteja associada com sua expansão: - -```html -

Web content is marked up using HTML.

-``` - -Novamente, você pode querer estilizá-lo de alguma forma: - -```css -abbr { - color: #a60000; -} -``` - -A convenção de estilo que é reconhecida para abreviações é uma linha pontilhada, e não é recomendado estilizá-la. Para saber mais sobre abreviações, veja [Abbreviations](/pt-BR/docs/Learn/HTML/Introduction_to_HTML/Advanced_text_formatting#Abbreviations). - -#### Links - -Hyperlinks — the way you get to new places on the web: - -```html -

Visit the Mozilla homepage.

-``` - -Some very simple link styling is shown below: - -```css -a { - color: #ff0000; -} - -a:hover, a:visited, a:focus { - color: #a60000; - text-decoration: none; -} - -a:active { - color: #000000; - background-color: #a60000; -} -``` - -The standard link conventions are underlined and a different color (default: blue) in their standard state, another color variation when the link has previously been visited (default: purple), and yet another color when the link is activated (default: red). In addition, the mouse pointer changes to a pointer icon when links are moused over, and the link receives a highlight when focused (e.g. via tabbing) or activated. The following image shows the highlight in both Firefox (a dotted outline) and Chrome (a blue outline): - -![](focus-highlight-firefox.png) - -![](focus-highlight-chrome.png) - -You can be creative with link styles, as long as you keep giving users feedback when they interact with the links. Something should definitely happen when states change, and you shouldn't get rid of the pointer cursor or the outline — both are very important accessibility aids for those using keyboard controls. - -#### Form elements - -Elements to allow users to input data into websites: - -```html -
- - -
-``` - -You can see some good example CSS in our [form-css.html](https://github.com/mdn/learning-area/blob/master/accessibility/css/form-css.html) example ([see it live](http://mdn.github.io/learning-area/accessibility/css/form-css.html) also). - -Most of the CSS you'll write for forms will be for sizing the elements, lining up labels and inputs, and getting them looking neat and tidy. - -You shouldn't however deviate too much from the expected visual feedback form elements receive when they are focused, which is basically the same as links (see above). You could style form focus/hover states to make this behaviour more consistent across browsers or fit in better with your page design, but don't get rid of it altogether — again, people rely on these clues to help them know what is going on. - -#### Tables - -Tables for presenting tabular data. - -You can see a good, simple example of table HTML and CSS in our [table-css.html](https://github.com/mdn/learning-area/blob/master/accessibility/css/table-css.html) example ([see it live also](http://mdn.github.io/learning-area/accessibility/css/table-css.html)). - -Table CSS generally serves to make the table fit better into your design and look less ugly. It is a good idea to make sure the table headers stand out (normally using bold), and use zebra striping to make different rows easier to parse. - -### Color and color contrast - -When choosing a color scheme for your website, make sure that the text (foreground) color contrasts well with the background color. Your design might look cool, but it is no good if people with visual impairments like color blindness can't read your content. - -There is an easy way to check whether your contrast is large enough to not cause problems. There are a number of contrast checking tools online that you can enter your foreground and background colors into, to check them. For example WebAIM's [Color Contrast Checker](http://webaim.org/resources/contrastchecker/) is simple to use, and provides an explanation of what you need to conform to the WCAG criteria around color contrast. - -> **Nota:** A high contrast ratio will also allow anyone using a smartphone or tablet with a glossy screen to better read pages when in a bright environment, such as sunlight. - -Another tip is to not rely on color alone for signposts/information, as this will be no good for those who can't see the color. Instead of marking required form fields in red, for example, mark them with an asterisk and in red. - -### Hiding things - -There are many instances where a visual design will require that not all content is shown at once. For example, in our [Tabbed info box example](http://mdn.github.io/learning-area/css/css-layout/practical-positioning-examples/info-box.html) (see [source code](https://github.com/mdn/learning-area/blob/master/css/css-layout/practical-positioning-examples/info-box.html)) we have three panels of information, but we are [positioning](/pt-BR/docs/Learn/CSS/CSS_layout/Positioning) them on top of one another and providing tabs that can be clicked to show each one (it is also keyboard accessible — you can alternatively use Tab and Enter/Return to select them). - -![](tabbed-info-box.png) - -Screen reader users don't care about any of this — they are happy with the content as long as the source order makes sense, and they can get to it all. Absolute positioning (as used in this example) is generally seen as one of the best mechanisms of hiding content for visual effect, because it doesn't stop screen readers from getting to it. - -On the other hand, you shouldn't use {{cssxref("visibility")}}`:hidden` or {{cssxref("display")}}`:none`, because they do hide content from screen readers. Unless of course, there is a good reason why you want this content to be hidden from screen readers. - -> **Nota:** [Invisible Content Just for Screen Reader Users](http://webaim.org/techniques/css/invisiblecontent/) has a lot more useful detail surrounding this topic. - -### Accept that users can override styles - -#### Accept that users can override your styles - -It is possible for users to override your styles with their own custom styles, for example: - -- See Sarah Maddox's [How to use a custom style sheet (CSS) with Firefox](https://www.itsupportguides.com/knowledge-base/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-firefox/) for a useful guide covering how to do this manually in Firefox, and [How to use a custom style sheet (CSS) with Internet Explorer](https://www.itsupportguides.com/knowledge-base/computer-accessibility/how-to-use-a-custom-style-sheet-css-with-internet-explorer/) by Adrian Gordon for the equivalent IE instructions. -- It is probably easier to do it using an extension, for example the Stylish extension is available for [Firefox](https://addons.mozilla.org/en-US/firefox/addon/stylish/), [Safari](https://safari-extensions.apple.com/details/?id=com.sobolev.stylish-5555L95H45), [Opera](https://addons.opera.com/en/extensions/details/stylish/), and [Chrome](https://chrome.google.com/webstore/detail/stylish/fjnbnpbmkenffdnngjfgmeleoegfcffe). - -Users might do this for a variety of reasons. A visually impaired user might want to make the text bigger on all websites they visit, or a user with severe color deficiency might want to put all websites in high contrast colors that are easy for them to see. Whatever the need, you should be comfortable with this, and make your designs flexible enough so that such changes will work in your design. As an example, you might want to make sure your main content area can handle bigger text (maybe it will start to scroll to allow it all to be seen), and won't just hide it, or break completely. - -## JavaScript - -JavaScript can also break accessibility, depending on how it is used. - -Modern JavaScript is a powerful language, and we can do so much with it these days, from simple content and UI updates to fully-fledged 2D and 3D games. There is no rule that says all content has to be 100% accessible to all people — you just need to do what you can, and make your apps as accessible as possible. - -Simple content and functionality is arguably easy to make accessible — for example text, images, tables, forms and push button that activate functions. As we looked at in our [HTML: A good basis for accessibility](/pt-BR/docs/Learn/Accessibility/HTML) article, the key considerations are: - -- Good semantics: Using the right element for the right job. For example, making sure you use headings and paragraphs, and {{htmlelement("button")}} and {{htmlelement("a")}} elements -- Making sure content is available as text, either directly as text content, good text labels for form elements, or [text alternatives](/pt-BR/docs/Learn/Accessibility/HTML#Text_alternatives), e.g. alt text for images. - -We also looked at an example of how to use JavaScript to build in functionality where it is missing — see [Building keyboard accessibility back in](/pt-BR/docs/Learn/Accessibility/HTML#Building_keyboard_accessibility_back_in). This is not ideal — really you should just use the right element for the right job — but it shows that it is possible in situations where for some reason you can't control the markup that is used. Another way to improve accessibility for non-semantic JavaScript-powered widgets is to use WAI-ARIA to provide extra semantics for screen reader users. The next article will also cover this in detail. - -Complex functionality like 3D games are not so easy to make accessible — a complex 3D game created using [WebGL](/pt-BR/docs/Web/API/WebGL_API) will be rendered on a {{htmlelement("canvas")}} element, which has no facility at this time to provide text alternatives or other information for severely visually impaired users to make use of. It is arguable that such a game doesn't really have this group of people as a part of its main target audience, and it would be unreasonable to expect you to make it 100% accessible to blind people, however you could implement [keyboard controls](/pt-BR/docs/Games/Techniques/Control_mechanisms/Desktop_with_mouse_and_keyboard) so it is usable by non-mouse users, and make the color scheme contrasting enough to be usable by those with color deficiencies. - -### The problem with too much JavaScript - -The problem often comes when people rely on JavaScript too much. Sometimes you'll see a website where everything has been done with JavaScript — the HTML has been generated by JavaScript, the CSS has been generated by JavaScript, etc. This has all kinds of accessibility and other issues associated with it, so it is not advised. - -As well as using the right element for the right job, you should also make sure you are using the right technology for the right job! Think carefully about whether you need that shiny JavaScript-powered 3D information box, or whether plain old text would do. Think carefully about whether you need a complex non-standard form widget, or whether a text input would do. And don't generate all your HTML content using JavaScript if at all possible. - -### Keeping it unobtrusive - -You should keep **unobtrusive JavaScript** in mind when creating your content. The idea of unobtrusive JavaScript is that it should be used wherever possible to enhance functionality, not build it in entirely — basic functions should ideally work without JavaScript, although it is appreciated that this is not always an option. But again, a large part of it is using built-in browser functionality where possible. - -Good example uses of unobtrusive JavaScript include: - -- Providing client-side form validation, which alerts users to problems with their form entries quickly, without having to wait for the server to check the data. If it isn't available, the form will still work, but validation might be slower. -- Providing custom controls for HTML5 `