Tag Archives: developer

Effectively including accessibility into web developer training – Karl Groves

…Today, I’d like to follow “Your computer school sucks” with some actual guidance for web developer training schools and bootcamps.

Do not treat accessibility as its own topic

A few years ago, I wrote a series of blog posts under the theme Selling Accessibility. The content for many of those posts was driven by interviews I did with a number of people in the accessibility field, one of whom was Cher Travis-Ellis from CSU Fresno. Higher Education has some unique challenges when it comes to online accessibility, especially when it comes to the amount of content being created and the large numbers of non-technical people who create that content. During our discussions, Cher shared with me a neat trick she used when training CSU Fresno staff on accessible content creation: add the accessibility training to all the other training. Unless there’s a really specific technique that deals only with accessibility, nobody really needs to know that you’re teaching them how to make something accessible. For instance, if you’re teaching someone how to use MS Word and you talk about using actual headings instead of bolded text, the accessibility aspect of that practice doesn’t really matter. In other words, you’re teaching people how to do a good job, anyway. The same thing goes for web development. Many accessibility best practices are also just quality best practices. Teach people how to do a good job and, when it comes to techniques that are specific to accessibility, that should be in the core curriculum too.

Discuss the role of “markup” in Hypertext markup language

Discuss the Document Object Model, including Object-Oriented Principles like Abstraction, Inheritance, and Encapsulation

Discuss user input devices

Discuss quality

Discuss basic user expectations, including predictability of the interface

Expect More

Curated by (Lifekludger)
Read full article at Source: Effectively including accessibility into web developer training – Karl Groves

Being a deaf developer

… Some deaf people successfully become programmers. It’s mostly thought-based, often solitary work, where all your output is written down. Specifications and bugs come to you (in an ideal world, at least) on paper and in ticketing systems instead of through other people’s noiseholes. Some areas aren’t quite so fabulous (I’m looking at you, interminable conference call meetings involving 15 people sitting in a circle around a gigantic table), but adjustments are always possible.

The stereotype of a programmer as a solitary eccentric who’s allergic to human company is unfair and inaccurate. As a group, we’re a very social bunch. We write blogs, we speak at conferences, we produce tutorials, we mentor. This isn’t new, either – it’s an atmosphere that dates from before the earliest days of the internet at Bell Labs, or MIT, and scores of other R&D orgs. I love this social world of code, as being able to surround yourself with competent, enthusiastic individuals is a big part of becoming a better developer yourself. But one thing that I’ve always felt shut out of is pair programming.

Pair programming, in principle, is great – it’s like Rubber Duck debugging on steroids.

So it was great to get the opportunity to pair with Rowan Manning on the Pa11y project, the automated accessibility testing tool built for Nature. Using Screenhero to set up a remote pairing session meant that we could both look at the screen and use text to communicate, losing no information and generating no confusion.

This was the first time I’ve done a pairing session that worked as it should. It’s difficult to express what a difference this makes as I think most hearing people find it hard to appreciate how much information loss occurs in general conversation with a deaf person. Imagine that in your city that all the books you’ve ever read have had ~60% of the words in them randomly blanked out with a Sharpie. Then imagine going on holiday to a neighbouring city where (mercifully) nobody does that and you can suddenly read an entire book without needing to guess at anything. It’s a bit like that.

Curated by (Lifekludger)
Read full article at Source: Being a deaf developer

Being a deaf developer

I’ve been deaf since infancy. It is not profound; my hearing loss is described as moderate to severe and is mostly problematic at higher frequency ranges, the range at which most human speech happens.

I rely on lip-reading and identifying vowel patterns to understand spoken language. Particular struggles are:recognising consonants, especially sibilants and unvoiced consonants (all consonants are high frequency sounds, and the unvoiced and sibilant consonants don’t activate the vocal chords)the beginning of sentencesthe end of sentencesSome deaf people successfully become programmers. It’s mostly thought-based, often solitary work, where all your output is written down.

Specifications and bugs come to you (in an ideal world, at least) on paper and in ticketing systems instead of through other people’s noiseholes. Some areas aren’t quite so fabulous (I’m looking at you, interminable conference call meetings involving 15 people sitting in a circle around a gigantic table), but adjustments are always possible.

Curated by (Lifekludger)
Read full article at Source: Being a deaf developer