Subscribe: Comments for WebAIM Blog
Added By: Feedage Forager Feedage Grade B rated
Language: English
comment screen  comment  content  css style  css  reader  readers css  readers  screen reader  screen readers  screen  style content 
Rate this Feed
Rate this feedRate this feedRate this feedRate this feedRate this feed
Rate this feed 1 starRate this feed 2 starRate this feed 3 starRate this feed 4 starRate this feed 5 star

Comments (0)

Feed Details and Statistics Feed Statistics
Preview: Comments for WebAIM Blog

Comments for WebAIM Blog

The WebAIM Web Accessibility Blog

Last Build Date: Wed, 15 Nov 2017 14:36:14 +0000


Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Philipp

Wed, 15 Nov 2017 14:36:14 +0000

Wouldn’t it be great if there is something like „Browserstack“ but just for screenreader? So you can test different screenreader over different browser (and maybe hardware). 
Does somebody know if there is something like that out there somewhere? If someone is interested —> contact me and i’ll make a project around that ;-) (

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by John Northup

Wed, 08 Nov 2017 16:45:22 +0000

It's tempting to use tabindex and ARIA, but this can turn into a real maintenance issue. We regard ARIA as a tool of last resort, for things that HTML can't do. As for tabindex--we have never seen an implementation of positive tabindex values that didn't just cause more problems. We advise developers to structure HTML in a logical order and to position that content visually as needed with CSS.

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Mike

Wed, 08 Nov 2017 11:59:07 +0000

As we know that in CSS3, we have some advanced properties that is used for positioning the elements as well as designing them beautifully. But, usually the designers break the order of content which is visually perfect but not suitable for screen-reader. So, we should prefer using 'tab-index' and aria-* attributes.

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Blee Blat

Sun, 24 Sep 2017 03:03:08 +0000

This is not just frustrating for developers, it also is hard for users. I would like it if I could just use one browser/screen reader combination for computers and one for mobile. But sadly, I'm stuck having at least 2 screen readers on the computer and 2 browsers. The phones only have one screen reader handy, so that's all I have on Android and iOS when I was using it. Having to bounce browser /screen reader combinations just because one doesn't read the page accurately is not helpful. I wonder if there's anything we can do for this? How common is it for computer users who don't rely on assistive technology to have to run the same site through multiple browsers to read it effectively? Currently there are weird bugs in some browser screen reader combinations where certain page elements are not read or read incompletely. The only way you know when things are read wrong on some pages is to use another screen reader, or the same screen reader with another browser. This tends to mostly affect CSS or forms, but probably affects other javascript and things. I'm not a web developer, but I could learn if someone thought it'd help. Standards are often ignored anyway, just like legislation. Having a standard doesn't really help. If someone wants to customize the heck out of their system, they will, and you can't test every case. Part of this is up to the user to know how to use the technology, and part of it is the developer having enough compassion to make the best job of writing the pages and code accurately. There's no standard that you could write that will make someone care about something enough to do it. Legislation of anything is likely to have a negative affect anyway especially among caring people. The other problem is that acccessibiliity means nothing if you don't need to use it yourself. I hit the same snag once when I wrote a program that didn't take into account unicode, because I only speak English and have no way to test internationalization. I suspect this happens to developers as well. If they don't know a screen reader user personally, why would they think to make things accessible? You can't legislate altruism, which is what this comes down to. Part of the problem with some screen readers is things like NVDA's "browse mode" which I personally don't like because it breaks every web app with keyboard shortcuts. I happen to like a lot of keyboard shortcuts. Facebook and Google Music are examples where this is particularly annoying. I have a large music library and I'd have a larger feed possibly if that particular site wasn't so cumbersome to navigate and use. But built-in screen readers like Narrator and Voiceover don't receive updates quick enough to keep up with a dynamic web. W3C recommendations can't move fast enough either. It'd be helpful to include things like Orca and Linux because users of those platforms are more likely to be able to help developers fix a lot of the things that are broken. The worst thing you can do is have screen readers parsing HTML because that's where most of the trouble starts. We should discourage that practice. A screen reader is supposed to read the screen and leave it up to the user what to do with the data. Probably the place to start is to get operating system makers to expose accessibility API's in such a way that things like "browse mode" or virtual buffers can never happen. That will get rid of a large class of odd behavior and make sure that the user and the developer both know precisely what markup or code is doing at all times. If this comment is too long or out of place otherwise not helpful, feel free to delete it. Otherwise thank you for reading and I hope the somewhat random and disorganized thoughts might be somehow useful. If you need help testing, I have time and would bother learning web development to help. With so much being on the web, it'[...]

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Cranston

Fri, 08 Sep 2017 14:56:47 +0000

I am currently involved in a pretty large scale accessibility overhaul for a number of government sites. The inconsistencies between various screen readers / browsers / OSs is almost laughable. It seems absurd to me that a law could be passed that requires compliance with undefined and inconsistent specifications. So far, it seems following wcag/w3c documentation is only a start and is only actually helpful in the most simple situations. Tables have been a nightmare (if anyone can come up with a decent solution for a responsive, mobile-friendly table that works with screenreaders that isn't more aria- attributes than actual table markup I'm all ears). Description lists just come out as a block of text. Pseudo elements are read by screenreaders (and as far as I can tell, there's no way to hide them from screenreaders). Changing the display: property of an element can cause screenreaders to present them differently. Flexbox order vs DOM order - seems to depend... And getting one screen reader to behave correctly doesn't mean others will. Voiceover is inconsistent between desktop and mobile. Each screenreader can be configured differently as well, so whats the standard there. I think everyone should be able to access whatever content they want in a way that's appropriate for them, but this feels a little like we're being legally required to support a very broad category of software with seemingly few predictable standards.

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Markus

Fri, 08 Sep 2017 11:42:15 +0000

This is very helpful, thank you! The only thing that surprises me is that it seems generated content was outright bad. If I get Jens Meiert right, for example, then there are cases when generated content is useful. The cases Karl Groves mentions, as with marking PDF links, look acceptable for Meiert. Again if I understand them well, maybe they can comment.

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Gareth

Fri, 08 Sep 2017 06:54:50 +0000

I always turn CSS off, and assume that's what a screen reader is going to "see" and read out. That might not be a 100% accurate assumption, but HTML is for content and CSS is for design (seperation of concerns). A screen reader should be interested in the former and not so much the latter.

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Susanna

Tue, 05 Sep 2017 14:41:42 +0000

But what about ::before and ::after generated content? That's particularly what I'd like to know. I manage a website with many different users who are very very bad at remembering to do things like indicating PDF links. I'd like to add a filetype indicator as generated content in the CSS, but have understood that it will be skipped by screenreaders, is that correct?

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by jojo esposa

Mon, 04 Sep 2017 01:37:49 +0000

This is a surprise! I knew that screen readers read codes in a linear way and CSS don't get in the way. Thank you very much for this very useful info.

Comment on Screen Readers and CSS: Are We Going Out of Style (and into Content)? by Lee Kowalkowski

Fri, 01 Sep 2017 09:52:34 +0000

I find it much better, long term, to ensure as much as possible, no - everything - is correct in source HTML. For example, prefer removing/inserting content over hiding/showing. I can see that hidden content, and sometimes, without hacking, some sites just glitch and suddenly it's there. I've also seen many cases where authors have visually hidden content intended only for screen reader users when it would actually be of benefit to sighted users, too, even automatically-hidden content like image alt text. Also, if you're into industry-strength workmanship, CSS-only solutions tend to be inappropriate for language or locale sensitive cases (injecting words into a page, or formatting cents/pence superscript). I'm sure somebody could indeed design a CSS localisation solution for such cases, but having everything correct in source HTML to start with is more robust and usually simpler.