html - Is it bad to use aria-label for content? -

i've case i'd use aria-label give screen-readers access (css pseudo-)content. this:

[data-pseudo-content]::before {    content: attr(data-pseudo-content);  }

<h1 aria-label="this title" data-pseudo-content="this title"></h1>

is bad use aria-label content rather label content? also, screen-readers read this title twice?

to best of understanding, aria-label can applied in situations change or enrich accessible name of element (= textual representation outputted user, either speech or braille). amount of influence of aria-label or aria-labelledby on accessible name depends on how information node contains , type or role itself.

your example (confirmed nvda on windows 8.1 in chrome 42 , firefox 36) doesn't make of difference screen reader, follow set of rules determine accessible name. in experience, screen reader - among others - give priority containing text if other conditions (role) fail. if node happen empty , other alternatives not available, screen reader render aria-labelledby or aria-describedby accessible name if provided. otherwise ignored.

luckily in case, aria standard covers :before , :after part algorithm determining accessible name. can read more how accessible name being computed @ spec: http://www.w3.org/tr/wai-aria/roles#textalternativecomputation

when aria-label or aria-labelledby make use? i'm still researching subject, cannot provide 100% answer time being. do, know makes difference on elements <input>. should apply aria-label when there no visible label available. might useful know that, whenever aria-labelledby rendered, placed first in accessible name. useful form fields, because <label> might not rendered first if many attributes given. aria-label / aria-labelledby useful when use contenteditable attribute on element, make sure content accessible screen readers.

here wiki examples of how aria-label / aria-labelledby applied (search on page words): http://www.w3.org/wai/gl/wiki/category:aria_techniques

remember: best way figure out works , doesn't, playing around screenreader. have not been able test other screen readers (apart nvda , ios voiceover while), implementation on other screen readers jaws might differ. other known screen readers windows eyes , supernova (though heard sn not replacing focus .focus(), careful). might idea test in different browsers, accessibility api might differ , give different outputs.