#4: Post edited
by
Rodolfo Manin
·
2025-08-25T13:52:10-03:00 (10 meses ago)
#3: Post edited
by
Rodolfo Manin
·
2025-08-25T13:33:45-03:00 (10 meses ago)
#2: Post edited
by
Rodolfo Manin
·
2025-08-25T13:27:02-03:00 (10 meses ago)
Formatação do texto
Acessibilidade
#1: Post edited
by
Rodolfo Manin
·
2025-08-25T13:25:25-03:00 (10 meses ago)
Accessibility
Formatação do texto
<p>This short guide goes over several aspects of accessibility to keep in mind when writing or editing posts on the Codidact network. There are many different disabilities out there, and these tips cover accessibility for many of them, such as people using screen readers, keyboard users, colorblind users, and people with cognitive disabilities.</p>
<a href="#Understandable">Making your posts understandable</a>
<ul>
<li><a href="#Vocabulary">Vocabulary</a></li>
<li><a href="#Jargon">Define acronyms and specialized terms</a></li>
<li><a href="#Paragraphs">Paragraph and sentence breaks</a></li>
</ul>
</li>
</ul>
<hr>
<h2 id="Formatting">Formatting</h2>
<h3 id="Headings">Headings</h3>
<p>Headings are used to separate sections of information. Each heading should give you a decent indication of what you can expect in that section. (As an example, the heading "headings" before this section is a good hint that this section is about headings.)</p>
<ul>
<li>
<p>Follow an intuitive header order.</p>
<p>Don't jump from an <code><h2></code> to an <code><h5></code>; follow a consistent, intuitive order for headings, where top-level sections have a higher-level header and sub-sections have a lower-level header. You shouldn't skip levels of headings (for instance, moving from an <code><h2></code> to an <code><h4></code> without an <code><h3></code> in between)<br>
However, when you are ending a sub-section and moving back to a higher-level section, you can move from a low-level header (such as <code><h4></code>) back up to a higher-level header (such as <code><h2></code>) without including a mid-level header.</p>
</li>
<li>
<p>There should generally only be one top-level header (which can be formatted using <code><h1></code> or <code>#</code>) per-page.</p>
<p>Posts on the Codidact network have a top-level heading as the question or article title.<br>
Whether or not using another top-level header is appropriate depends on the type of post you're writing, as well as on how the question and answers are structured. Posts covering a large number of topics or that are split up into multiple, entirely distinct sections sometimes might need to include more than one top-level heading, but consider carefully if it's actually necessary.</p>
</li>
<li>
<p>Only use headings for actual headings, and don't use headings for non-header content.</p>
<p>If something acts as a heading, it should be properly marked up as a heading, using either the appropriate Markdown or HTML tags. The opposite holds true as well; if something is not acting as a heading, it should not be formatted as a heading. If you want to emphasize something, don't use headings to do that.</p>
</li>
</ul>
<p>Screen readers and similar can jump from heading to heading (including describing what level of heading), so keep that in mind when choosing headings for your posts.</p>
<hr>
<h4 id="Headings-Examples">Examples</h4>
<p>A good heading order follows the logical layout of the page, without skipping over levels, consistently uses the same level headings for sections at the same level, and only uses headings for actual heading content.</p>
<pre>// Example of a good heading order
<h1>Question title (automatically provided)<h1>
<h2>Answer section 1</h2>
<h3>Answer sub-section 1a</h3>
<h3>Answer sub-section 1b</h3>
<h2>Answer section 2</h2>
<h3>Answer sub-section 2a</h3>
<h3>Answer sub-section 2b</h3>
<h4>Answer sub-sub-section 2b.1</h4>
<h4>Answer sub-sub-section 2b.2</h4>
<h2>Answer section 3</h2>
</pre>
<p>The heading order above shows an answer that doesn't use a top-level heading (<code><h1></code>), since there's already one on the page - the question title. It uses <code><h2></code> to differentiate its high-level sections. It then uses <code><h3></code> for the sub-sections, and when it's necessary to have a sub-sub-section, it uses <code><h4></code>.</p>
<p>A bad heading order would skip levels, use headings for non-heading content, or unnecessarily over-use top-level headings.</p>
<pre>// Example of a bad heading order
<h1>Question title (automatically provided)</h1>
<p>This bad example uses <code><h1></code> twice in the answer, despite there already being a top-level heading as the question title. It uses an <code><h1></code> heading for the answer summary, using a heading for non-heading content. It then uses wildly inconsistent heading levels for its different sections and sub-sections, and skips levels of headings (such as moving directly from <code><h3></code> to <code><h5></code>).</p>
<hr>
<h3 id="Emphasis">Emphasized text</h3>
<p>Emphasized text, such as bold or italics, is good for calling attention to key words or sentences. However, if it's overused, it ends up defeating its own purpose and making a post more difficult to read instead of clearer.</p>
<ul>
<li>
<p>Bold text should be used sparingly.</p>
<p>Only use it to highlight words or sentences that actually need special attention called to them.</p>
</li>
<li>
<p>Italics should only be used when it is appropriate to use italics.</p>
<p>Italics are used for emphasizing stress on a certain word, italicizing the names of works, indicating words in foreign languages, and other standard uses of italics. Don't over-use italics on text that doesn't need to be italicized; remember that italics can make it harder to read the text for certain people, including some people with dyslexia.</p>
</li>
<li>
<p>Avoid bolding or italicizing entire paragraphs.</p>
</li>
</ul>
<h3 id="Code">Code markup</h3>
<ul>
<li>
<p>Code markup should be used for code, including variable names and other code elements that may be found in non-code lines.</p>
<p>This allows for code highlighting to work, and makes it clear when a code element is being referred to.</p>
</li>
<li>
<p>Code markup should not be used for any non-code elements.</p>
<p>This includes using it for emphasis, for tables, or other non-code usage. Instead, use the <a href="https://meta.codidact.com/help/formatting">dedicated formatting</a> for those elements. Misusing code markup can cause issues for assistive technology such as screen readers.</p>
</li>
</ul>
<h3 id="Text-size">Text size</h3>
<ul>
<li>
<p>Don't stack subscripts or superscripts to make your text tiny.</p>
<p>Using superscript or subscript once is enough, and only use it when necessary. Screen readers may not differentiate between sub- or superscript and regular text, so keep that in mind.</p>
</li>
</ul>
<p>Codidact has integrated footnotes available, so you should avoid using sub- and superscript for footnotes; use the dedicated Markdown instead.</p>
<h3 id="Tables">Tables</h3>
<ul>
<li>
<p>If possible, avoid putting ambiguous data into tables - i.e., having data that you can't tell which column of the table it would be associated with without checking, such as having two columns containing plain numbers.</p>
</li>
<li>
<p>Avoid blank header rows in tables, and don't use table formatting for data that doesn't actually belong in a table.</p>
</li>
</ul>
<h2 id="Images">Images</h2>
<h3 id="Alt-text">Alternative (alt) text</h3>
<ul>
<li>
<p>Whenever you include an image in a post, you should include alternative text (commonly called "alt text") that serves the same purpose as the image.</p>
<p>This replaces the default text of "Image_alt_text". This is used by screen readers, search engines, and when images can't be displayed (such as images being blocked in certain countries or by school/business networks).</p>
</li>
<li>
<p>The alt text should be short, succinct, and serve the exact same purpose as the image - it shouldn't contain more or less information than the image itself.</p>
</li>
</ul>
<p>As a general way of making sure your alt text is appropriate, consider if the information present in the post would change at all if the image was replaced entirely with the alt text. If the information would stay the same, you're good to go.</p>
<h3 id="Decorative-images">Decorative images</h3>
<ul>
<li>A decorative image, which serves no purpose other than visual, should have its alt text be entirely blank.</li>
</ul>
<p>Note that this is <em>blank</em>, not <em>missing</em>. From a coding perspective, this means setting its <code>alt</code> attribute to <code>=""</code>, not leaving out the <code>alt</code> attribute.</p>
<p>In general, you should avoid including images that don't serve any specific purpose or that are just decorative in your post.<br>
If you find yourself including a decorative image, make sure that it's not formatted as a link, leaving only the embedded image, and to set the alt text to be blank.</p>
<p>In order to avoid the possibility of dead images, and ensure that that post remains stable for as long as possible, you should avoid using an external image hosting service. Instead, use the built-in image uploader for the Codidact Network. This means that the image is stored on our own servers instead of depending on someone else.</p>
<hr>
<h4 id="Images-examples">Examples</h4>
<p>Let's take the following snippet of a post for our example:</p>
<blockquote>
<p>When you go to edit a post, you now have the option to check the "redact" button:</p>
<p><img alt="Checkbox to select "redact": Redact original content by hiding the previous versions from history?" src="https://meta.codidact.com/uploads/qwvy25mvolpdjabhknuujzjncbpm"><br>
<sub>(Source: "<a href="https://meta.codidact.com/posts/289192/289193#answer-289193">What should I do when I come across PII in a post?</a>" by Mithical on Codidact Meta, licensed under CC BY-SA-NC 4.0)</sub></p>
</blockquote>
<p>In this example, the image is being used to illustrate the new button and what it does. That information needs to be presented in the alt text as well, which the current alt text does:</p>
<pre>
</pre>
<p>This is short and to the point. It tells anybody who can't see the image what information is shown with the checkbox, which is why the screenshot was included.</p>
<p>A bad example would be leaving out the alt text, having overly long alt text, or relying on an external image hosting service:</p>
<pre>
</pre>
<p>In the first bad example, there is both no alt text and it relies on an external image service. There is no information presented to anyone who can't see the image, and there's the risk that the image will go dead even for people who can see it.<br>
In the second bad example, the alt text is too long. It has information that's not present in the image itself, such as information about the edit comment appearing in the revision history, and describes information that's not relevant to the purpose of the screenshot - which is simply to show what you're presented with when you go to redact a post.</p>
<hr>
<h3 id="Color">Don't rely solely on color</h3>
<p>When your image uses colors to indicate a difference between things - such as on a chart or graph - you should also use a different method of differentiating, such as an icon or different shape. Also avoid using colors that are known to be a problem for colorblind users (such as red/green).</p>
<h3 id="Contrast">Contrast</h3>
<p>Avoid colors that are too close to each other, especially for text on a background color. As a simple way of testing, take a glance at the image in sunlight - can you still make it out?</p>
<h3 id="Animations">Animations</h3>
<p>We don't currently support any way to disable or pause animations in posts, so avoid using animations where possible. In particular, make sure to avoid flashing content (especially anything flashing more than three times a second - don't do that!). Flashing content can cause seizures, and looping animations can be distracting for everyone, but especially for people with some cognitive disabilities.</p>
<h3 id="Text-images">Images of text</h3>
<ul>
<li>
<p>Avoid images of text.</p>
<p>Images of text can't have the text selected, be read by screen readers, indexed by search engines, have the text adjust in a responsive design, or have the font changed. This includes images of code; instead, put the actual code in your post and format it using the dedicated code formatting Markdown.</p>
</li>
</ul>
<h4 id="Quotes">Quoting</h4>
<ul>
<li>
<p>If you are quoting from somewhere, don't provide an image of the text; use text, formatted as a blockquote (which can be done by putting a <code>></code> at the beginning of a paragraph), and cite your source.</p>
<p>This applies to both online and offline resources, such as Wikipedia or a physical book.</p>
</li>
<li>
<p>Do not use code formatting for quotes.</p>
</li>
</ul>
<h2 id="Links">Links</h2>
<h3 id="Link-text">Link text</h3>
<ul>
<li>
<p>Avoid link text such as "Here" or "Read more".</p>
<p>The link should explain its purpose through the text itself. Remember that screen readers and similar tools can jump to specific links, but if they're named something like "this", navigating to the correct link is much harder.<br>
Don't go too far in the other direction, though; there's no need to make an entire sentence a link as long as the link text is descriptive and distinct.</p>
</li>
<li>
<p>In general, link text should be unique - don't use the same link text twice in one post if those links go to different places.</p>
<p>While not required by any standard that I'm aware of, I'd encourage you to take steps to make sure that any resource you link to remains stable by archiving it in the Web Archive when you link to it. (This is similar to what Wikipedia does; sources used in articles are almost always archived so that a backup exists.)</p>
<h2 id="Understandable">Making your posts understandable</h2>
<h3 id="Vocabulary">Vocabulary</h3>
<ul>
<li>
<p>In general, try to keep your vocabulary simple.</p>
<p>This doesn't mean avoiding all technical terms, or not using the correct terms for things, but don't use jargon or fancy words when it's not necessary. This makes it easier for people who don't speak English as their first language, or people with cognitive disabilities, to understand your post.</p>
</li>
</ul>
<p>This should not come at the expense of precision or accuracy, though; keep your audience in mind. If you are writing for a highly specialized or technical audience, you shouldn't necessary shy away from using the relevant terminology; but if you're writing for everyone, using relatively simple terms is often a good idea.</p>
<h3 id="Jargon">Define acronyms and specialized terms</h3>
<ul>
<li>
<p>The first time you use an acronym, you should fully spell out what you're referring to.</p>
<p>A common example found on Codidact (CD) is just that - the acronym CD. However, that acronym can also refer to the terminal command <code>cd</code>, or the physical medium of Compact Discs, as well as other meanings. Once you've defined what CD stands for in your specific post, you can continue to use the acronym.</p>
</li>
</ul>
<p>This applies to specialized terms, jargon, and words in other languages as well. The first time you use a specialized term, define what it means or translate it.</p>
<h3 id="Paragraphs">Paragraph and sentence breaks</h3>
<ul>
<li>
<p>Avoid walls of text.</p>
<p>Make sure to break up your posts into sections, paragraphs, and sentences. When something runs on for too long, or is too dense, it can be very hard for people to get through, especially people who don't speak the language well or people with certain cognitive disabilities.</p>
</li>
</ul>
<hr>
<p>And those are the top tips for making your post accessible! Remember that accessibility is an ongoing process, so don't feel too bad if not all of your posts meet these guidelines. They can always be edited later, and the important thing is to keep accessibility in mind as you go forwards writing and editing posts.</p>
<p>Este breve guia aborda vários aspectos de acessibilidade que devem ser levados em conta ao escrever ou editar publicações na rede Codidact. Há muitas deficiências diferentes por aí, e essas dicas abrangem a acessibilidade para muitas delas, como pessoas que usam leitores de tela, usuários de teclado, usuários daltônicos e pessoas com deficiências cognitivas.</p>
<li><a href="#Web-Archive">Recurso estável (Arquivo da Web)</a></li>
</ul>
</li>
<li>
<a href="#Understandable">Tornando suas postagens compreensíveis</a>
<ul>
<li><a href="#Vocabulário">Vocabulário</a></li>
<li><a href="#Jargão">Definir acrônimos e termos especializados</a></li>
<li><a href="#Paragraphs">Parágrafos e quebras de frases</a></li>
</ul>
</li>
</ul>
<hr>
<h2 id="Formatação">Formatação</h2>
<h3 id="Headings">Headings</h3>
<p>Os títulos são usados para separar seções de informações. Cada título deve fornecer uma indicação decente do que pode ser esperado naquela seção. (Por exemplo, o título "cabeçalhos" antes desta seção é uma boa dica de que esta seção é sobre cabeçalhos.)</p>
<ul>
<li>
<p>Siga uma ordem de cabeçalho intuitiva.</p>
<p>Não pule de um <code><h2></code> para um <code><h5></code>; siga uma ordem consistente e intuitiva para os cabeçalhos, em que as seções de nível superior têm um cabeçalho de nível superior e as subseções têm um cabeçalho de nível inferior. Você não deve pular níveis de cabeçalhos (por exemplo, passar de um <code><h2></code> para um <code><h4></code> sem um <code><h3></code> no meio)<br>
No entanto, ao encerrar uma subseção e voltar para uma seção de nível superior, é possível passar de um cabeçalho de nível baixo (como <code><h4></code>) de volta para um cabeçalho de nível superior (como <code><h2></code>) sem incluir um cabeçalho de nível médio.</p>
</li>
<li>
<p>Em geral, deve haver apenas um cabeçalho de nível superior (que pode ser formatado usando <code><h1></code> ou <code>#</code>) por página.</p>
<p>Os posts na rede Codidact têm um cabeçalho de nível superior como a pergunta ou o título do artigo.<br>
A conveniência ou não de usar outro cabeçalho de nível superior depende do tipo de publicação que você está escrevendo e de como a pergunta e as respostas estão estruturadas. As postagens que abrangem um grande número de tópicos ou que são divididas em várias seções totalmente distintas às vezes podem precisar incluir mais de um cabeçalho de nível superior, mas considere cuidadosamente se isso é realmente necessário.</p>
</li>
<li>
<p>Só use títulos para títulos reais e não use títulos para conteúdo que não seja de cabeçalho.</p>
<p>Se algo funciona como um título, deve ser marcado adequadamente como um título, usando as tags Markdown ou HTML apropriadas. O oposto também é verdadeiro: se algo não estiver funcionando como um título, não deve ser formatado como um título. Se você quiser enfatizar algo, não use títulos para fazer isso.</p>
</li>
</ul>
<p>Os leitores de tela e similares podem pular de um título para outro (inclusive descrevendo o nível do título), portanto, tenha isso em mente ao escolher os títulos para suas postagens.</p>
<hr>
<h4 id="Headings-Examples">Exemplos</h4>
<p>Uma boa ordem de títulos segue o layout lógico da página, sem pular níveis, usa consistentemente os títulos do mesmo nível para seções do mesmo nível e usa apenas títulos para o conteúdo real do título.</p>
<pre>// Exemplo de uma boa ordem de títulos
<h1>Título da pergunta (fornecido automaticamente)<h1>
<h2>Seção de resposta 1</h2>
<h3>Resposta subseção 1a</h3>
<h3>Responda a subseção 1b</h3>
<h2>Responda a seção 2</h2>
<h3>Responda à subseção 2a</h3>
<h3>Responda a subseção 2b</h3>
<h4>Responda à subseção 2b.1</h4>
<h4>Responda à subseção 2b.2</h4>
<h2>Responda à seção 3</h2>
</pre>
<p>A ordem do cabeçalho acima mostra uma resposta que não usa um cabeçalho de nível superior (<code><h1></code>), pois já existe um na página - o título da pergunta. Ele usa <code><h2></code> para diferenciar suas seções de alto nível. Em seguida, usa <code><h3></code> para as subseções e, quando é necessário ter uma sub-subseção, usa <code><h4></code>.</p>
<p>Uma ordem de cabeçalho ruim pularia níveis, usaria cabeçalhos para conteúdo que não fosse de cabeçalho ou usaria desnecessariamente cabeçalhos de nível superior em excesso.</p>
<pre>// Exemplo de uma ordem de cabeçalho ruim
<h1>Título da pergunta (fornecido automaticamente)</h1>
<h1>Resumo da resposta (conteúdo real)</h1>
<h3>Seção de resposta 1</h3>
<h5>Responda à subseção 1a</h5>
<h4>Responda a subseção 1b</h4>
<h2>Responda a seção 2</h2>
<h4>Notas</h4>
<h1>Obrigado pela leitura!/h1>
</pre>
<p>Este exemplo ruim usa <code><h1></code> duas vezes na resposta, apesar de já haver um cabeçalho de nível superior como título da pergunta. Ele usa um título <code><h1></code> para o resumo da resposta, usando um título para conteúdo sem título. Em seguida, ele usa níveis de título extremamente inconsistentes para suas diferentes seções e subseções e pula níveis de títulos (como passar diretamente de <code><h3></code> para <code><h5></code>).</p>
<hr>
<h3 id="Ênfase">Texto enfatizado</h3>
<p>O texto enfatizado, como negrito ou itálico, é bom para chamar a atenção para palavras-chave ou frases. No entanto, se for usado em excesso, ele acaba anulando seu próprio objetivo e tornando a postagem mais difícil de ler em vez de mais clara.</p>
<ul>
<li>
<p>O texto em negrito deve ser usado com moderação.</p>
<p>Só use-o para destacar palavras ou frases que realmente precisam de atenção especial.</p>
</li>
<li>
<p>Os itálicos devem ser usados somente quando for apropriado usá-los.</p>
<p>O itálico é usado para enfatizar a ênfase em uma determinada palavra, colocar em itálico os nomes de obras, indicar palavras em idiomas estrangeiros e outros usos padrão do itálico. Não use itálico em excesso em um texto que não precisa ser itálico; lembre-se de que o itálico pode dificultar a leitura do texto para determinadas pessoas, inclusive para algumas pessoas com dislexia.</p>
</li>
<li>
<p>Evite colocar negrito ou itálico em parágrafos inteiros.</p>
</li>
</ul>
<h3 id="Código">Marcação de código</h3>
<ul>
<li>
<p>A marcação de código deve ser usada para código, incluindo nomes de variáveis e outros elementos de código que podem ser encontrados em linhas que não sejam de código.</p>
<p>Isso permite que o realce de código funcione e deixa claro quando um elemento de código está sendo referido.</p>
</li>
<li>
<p>A marcação de código não deve ser usada para nenhum elemento que não seja de código.</p>
<p>Isso inclui usá-lo para dar ênfase, para tabelas ou outro uso que não seja de código. Em vez disso, use a <a href="https://meta.codidact.com/help/formatting">formatação dedicada</a> para esses elementos. O uso incorreto da marcação de código pode causar problemas para a tecnologia de assistência, como leitores de tela.
</li>
</ul>
<h3 id="Text-size">Tamanho do texto</h3>
<ul>
<li>
<p>Não empilhe subscritos ou superscritos para tornar seu texto pequeno.</p>
<p>Usar o sobrescrito ou o subscrito uma vez é suficiente e somente quando necessário. Os leitores de tela podem não diferenciar entre subscrito ou sobrescrito e texto normal, portanto, tenha isso em mente.</p>
</li>
</ul>
<p>O Codidact tem notas de rodapé integradas disponíveis, portanto você deve evitar o uso de sub e superscript para notas de rodapé; em vez disso, use o Markdown dedicado.</p>
<h3 id="Tabelas">Tabelas</h3>
<ul>
<li>
<p>Se possível, evite colocar dados ambíguos em tabelas - ou seja, ter dados aos quais você não pode dizer a qual coluna da tabela eles estariam associados sem verificar, como ter duas colunas contendo números simples.</p>
</li>
<li>
<p>Evite linhas de cabeçalho em branco nas tabelas e não use formatação de tabela para dados que não pertençam de fato a uma tabela.</p>
</li>
</ul>
<h2 id="Imagens">Imagens</h2>
<h3 id="Alt-text">Texto alternativo (alt)</h3>
<ul>
<li>
<p>Sempre que incluir uma imagem em uma publicação, você deve incluir um texto alternativo (comumente chamado de "texto alternativo") que tenha a mesma finalidade que a imagem.</p>
<p>Isso substitui o texto padrão de "Image_alt_text". Isso é usado por leitores de tela, mecanismos de pesquisa e quando as imagens não podem ser exibidas (como imagens bloqueadas em determinados países ou por redes de escolas/empresas).</p>
</li>
<li>
<p>O texto alternativo deve ser curto, sucinto e servir exatamente ao mesmo propósito da imagem - ele não deve conter mais ou menos informações do que a própria imagem.</p>
</li>
</ul>
<p>Como forma geral de garantir que seu texto alternativo seja apropriado, considere se as informações presentes na postagem seriam alteradas se a imagem fosse substituída inteiramente pelo texto alternativo. Se as informações permanecerem as mesmas, você está pronto para ir.</p>
<li>Uma imagem decorativa, que não serve a nenhum outro propósito além do visual, deve ter seu texto alternativo totalmente em branco.</li>
</ul>
<p>Observe que isso é <em>em branco</em>, não <em>ausente</em>. Do ponto de vista da codificação, isso significa definir seu atributo <code>alt</code> como <code>=""</code>, e não deixar de fora o atributo <code>alt</code>.</p>
<p>Em geral, você deve evitar incluir imagens que não sirvam a nenhum propósito específico ou que sejam apenas decorativas em sua postagem.<br>
Se você incluir uma imagem decorativa, certifique-se de que ela não esteja formatada como um link, deixando apenas a imagem incorporada, e defina o texto alternativo como em branco.</p>
<p>Para evitar a possibilidade de imagens mortas e garantir que essa postagem permaneça estável pelo maior tempo possível, você deve evitar o uso de um serviço externo de hospedagem de imagens. Em vez disso, use o carregador de imagens interno da Rede Codidact. Isso significa que a imagem é armazenada em nossos próprios servidores, em vez de depender de outra pessoa.</p>
<hr>
<h4 id="Images-examples">Exemplos</h4>
<p>Vamos usar o seguinte trecho de uma publicação como exemplo:</p>
<blockquote>
<p>Quando você for editar uma publicação, agora terá a opção de marcar o botão "redigir":</p>
<p><img alt="Caixa de seleção para selecionar "redact": Redigir o conteúdo original ocultando as versões anteriores do histórico?" src="https://meta.codidact.com/uploads/qwvy25mvolpdjabhknuujzjncbpm"><br>
<sub>(Fonte: "<a href="https://meta.codidact.com/posts/289192/289193#answer-289193">O que devo fazer quando me deparo com PII em uma publicação?</a>" por Mithical no Codidact Meta, licenciado sob CC BY-SA-NC 4.0)</sub></p>
</blockquote>
<p>Neste exemplo, a imagem está sendo usada para ilustrar o novo botão e o que ele faz. Essas informações também precisam ser apresentadas no texto alternativo, o que o texto alternativo atual faz:</p>
<pre>
</pre>
<p>Isso é curto e direto ao ponto. Ele informa a qualquer pessoa que não possa ver a imagem quais informações são mostradas com a caixa de seleção, e é por isso que a captura de tela foi incluída.</p>
<p>Um exemplo ruim seria deixar de fora o texto alternativo, ter um texto alternativo muito longo ou depender de um serviço externo de hospedagem de imagens:</p>
<pre>
.
</pre>
<p>No primeiro exemplo ruim, não há texto alternativo e ele depende de um serviço de imagem externo. Não há nenhuma informação apresentada para quem não pode ver a imagem, e há o risco de que a imagem morra mesmo para as pessoas que podem vê-la.<br>
No segundo exemplo ruim, o texto alternativo é muito longo. Ele contém informações que não estão presentes na imagem em si, como informações sobre o comentário de edição que aparece no histórico de revisões, e descreve informações que não são relevantes para o objetivo da captura de tela, que é simplesmente mostrar o que é apresentado quando você vai redigir uma postagem.</p>
<hr>
<h3 id="Cor">Não confie apenas na cor</h3>
<p>Quando sua imagem usar cores para indicar uma diferença entre as coisas - como em um gráfico ou tabela - você também deverá usar um método diferente de diferenciação, como um ícone ou uma forma diferente. Evite também usar cores que são conhecidas por serem um problema para usuários daltônicos (como vermelho/verde).</p>
<h3 id="Contraste">Contraste</h3>
<p>Evite cores muito próximas umas das outras, especialmente para texto em uma cor de fundo. Como uma maneira simples de testar, dê uma olhada na imagem sob a luz do sol - você ainda consegue vê-la?
<h3 id="Animações">Animações</h3>
<p>No momento, não oferecemos suporte a nenhuma forma de desativar ou pausar animações em publicações, portanto, evite usar animações sempre que possível. Em particular, evite conteúdo intermitente (especialmente qualquer coisa que pisque mais de três vezes por segundo - não faça isso!). O conteúdo intermitente pode causar convulsões, e as animações em loop podem distrair a todos, mas especialmente as pessoas com alguma deficiência cognitiva.</p>
<h3 id="Text-images">Imagens de texto</h3>
<ul>
<li>
<p>Evite imagens de texto.</p>
<p>As imagens de texto não podem ter o texto selecionado, ser lidas por leitores de tela, indexadas por mecanismos de pesquisa, ter o texto ajustado em um design responsivo ou ter a fonte alterada. Isso inclui imagens de código; em vez disso, coloque o código real em sua postagem e formate-o usando a formatação de código dedicada Markdown.</p>
</li>
</ul>
<h4 id="Citações">Citações</h4>
<ul>
<li>
<p>Se estiver fazendo uma citação de algum lugar, não forneça uma imagem do texto; use o texto, formatado como uma citação em bloco (o que pode ser feito colocando um <code>></code> no início de um parágrafo) e cite sua fonte.</p>
<p>Isso se aplica tanto a recursos on-line quanto off-line, como a Wikipedia ou um livro físico.</p>
</li>
<li>
<p>Não use formatação de código para citações.</p>
</li>
</ul>
<h2 id="Links">Links</h2>
<h3 id="Link-text">Texto do link</h3>
<ul>
<li>
<p>Evite textos de links como "Aqui" ou "Leia mais".</p>
<p>O link deve explicar sua finalidade por meio do próprio texto. Lembre-se de que os leitores de tela e ferramentas semelhantes podem pular para links específicos, mas se eles tiverem um nome como "isto", será muito mais difícil navegar até o link correto.<br>
No entanto, não vá muito longe na outra direção; não há necessidade de transformar uma frase inteira em um link, desde que o texto do link seja descritivo e distinto.</p>
</li>
<li>
<p>Em geral, o texto do link deve ser exclusivo - não use o mesmo texto de link duas vezes em uma publicação se esses links forem para lugares diferentes.</p>
</li>
</ul>
<h3 id="Web-Archive">Recurso estável (Arquivo da Web)</h3>
<p>Embora não seja exigido por nenhum padrão que eu conheça, eu o encorajaria a tomar medidas para garantir que qualquer recurso para o qual você crie um link permaneça estável, arquivando-o no Web Archive quando você criar um link para ele. (Isso é semelhante ao que a Wikipedia faz; as fontes usadas nos artigos quase sempre são arquivadas para que haja um backup.)</p>
<h2 id="Compreensível">Tornar suas postagens compreensíveis</h2>
<h3 id="Vocabulário">Vocabulário</h3>
<ul>
<li>
<p>Em geral, tente manter seu vocabulário simples.</p>
<p>Isso não significa evitar todos os termos técnicos ou não usar os termos corretos para as coisas, mas não use jargões ou palavras sofisticadas quando não for necessário. Isso facilita a compreensão de sua postagem por pessoas que não têm o inglês como primeiro idioma ou por pessoas com deficiências cognitivas.</p>
</li>
</ul>
<p>No entanto, isso não deve ser feito às custas da precisão ou da exatidão; tenha em mente seu público-alvo. Se você estiver escrevendo para um público altamente especializado ou técnico, não deve deixar de usar a terminologia relevante; mas se estiver escrevendo para todos, usar termos relativamente simples geralmente é uma boa ideia.</p>
<h3 id="Jargão">Definir acrônimos e termos especializados</h3>
<ul>
<li>
<p>Na primeira vez em que usar um acrônimo, você deve explicitar completamente a que está se referindo.</p>
<p>Um exemplo comum encontrado no Codidact (CD) é exatamente isso: o acrônimo CD. No entanto, esse acrônimo também pode se referir ao comando de terminal <code>cd</code>, ou à mídia física dos Compact Discs, além de outros significados. Depois de definir o que significa CD em sua postagem específica, você poderá continuar a usar o acrônimo.
</li>
</ul>
<p>Isso também se aplica a termos especializados, jargões e palavras em outros idiomas. Na primeira vez que você usar um termo especializado, defina o que ele significa ou traduza-o.</p>
<h3 id="Parágrafos">Parágrafos e quebras de frases</h3>
<ul>
<li>
<p>Evite paredes de texto.</p>
<p>Certifique-se de dividir suas publicações em seções, parágrafos e frases. Quando algo se estende por muito tempo ou é muito denso, pode ser muito difícil para as pessoas entenderem, especialmente as pessoas que não falam bem o idioma ou as pessoas com certas deficiências cognitivas.</p>
</li>
</ul>
<hr>
<p>E essas são as principais dicas para tornar sua postagem acessível! Lembre-se de que a acessibilidade é um processo contínuo, portanto, não se sinta mal se nem todas as suas publicações atenderem a essas diretrizes. Elas sempre poderão ser editadas posteriormente, e o importante é manter a acessibilidade em mente à medida que você for escrevendo e editando as publicações.</p> <p>
Rodolfo Manin
·
2025-08-25T13:52:10-03:00 (10 meses ago)