Barrierefreiheit in Webanwendungen

| Tags: IPC12

Zu kompliziert! nur für Blinde! zu teuer! müssen wir das machen?

Barrierefreiheit bringt sauberen HTML und CSS Code.

Man benutzt aktuelle Technik und bekommt SEO Optimierung gratis.

Accessibility vs Useability

  • Accessibility ist, wie gut man eine Seite erreichen kann
  • Useability ist, wie gut man eine Seite benutzen kann

Gesetze und Normen

  • Behindertengleichstellungsgesetz BGG -> §11
  • Barrierefreie Informationstechnik-Verordnung (BITV)
  • Web Accessibility Initiative (WAI)
    • Alternative zu Videos und Audioinhalte
    • Struktus/Semantik nicht nur durch Farben darstellen
    • W3C Richtlinen einhalten
    • Klare Navigationsmechanismen
    • Einfach gehaltene Inhalts- und Satzstrukturen
    • Geräteunabhängiges Design

Wer braucht's?

  • Nutzer mit leerem Mausakku
  • Gruppe der 50+
  • Sehnenscheidentzündung
  • Rot-Grüne-Schwäche
  • moderne Mobiltechnik
  • langsame Internetverbindung
  • 6,7 Mio mit Schwerstbehinderung
  • 164.000 blinde und 1 Mio sehbehinderte Menschen

Farben & Kontraste

  • Rot/Grün-Kombinationen vermeiden
  • Grelle Farben vermeiden
  • Genug Kontrast zwischen Text und Hintergrund

Farbkontrast Analyzer von Web for all

HTML

  • Korrekte HTML Elemente nutzen (h1-h6, p, table, ul, ...)
  • Suchfeld als erstes im Quelltext anlegen
  • Verstecktes Menü
  • Sprunglinks
    • <a href>, <a id>
    • nicht zuviele davon
    • hervorheben bei hover, focus, active
  • Formatierungen und Darstellungen
    • sonnvolle Formatierungen
    • Unterstreichungen nur bei Links
    • Fettdruck in Maßen
    • nichr kursiv verwenden
    • sinnvolle alt-Attribute in Bildern <img alt="Hier eine Beschreibung">
  • Formulare
    • Pflichtfeldhinweis in <label> (Nicht nur ein Sternchen - für Blinde)
    • Captcha Frage innerhalb des Labels positionieren
    • Fehlermeldung vor Eingabefeldern ausgeben (im HTML!, nicht zwangsweise auch so sichtbar)
    • Seitentitel bei Fehlerausgabe abändern
    • aktives Feld hervorheben
  • Navigation
    • aktiver Navigationspunkt mit <strong> einfaßen
    • Links "flächig" (display: block;) definieren, damit Benutzer mehr als den Text zum klicken haben
    • verstecktes Menü mit Sprunglinks

Didaktik

  • Fachbegriffe, Abkürzungen, Fremdwörter vermeiden
  • Einfache Sätze und Sprache
  • Links mit sinnvollen Bezeichnungen

Display: none; wird vom Screenreader nicht vorgelesen, d.h. man darf Dinge, die Screenreader lesen sollen nicht mit display: none; belegen!

Screenreder können JavaScript!

Summary

Barrierefreiheit ist Win-Win-Situation für Benutzer, Entwickler und das Management.

Optimierungen sind nicht nur gut für das HTML, CSS sondern auch für SEO.

PHPUnit Best Pratice

| Tags: IPC12

Sebastian Bergmann is talking about PHPUnit Best Pratices

Nobody likes to install a software.

Install PHPUnit via PEAR or composer.

Be descriptive about what you are testing

If you write tests for a class named Money, name the Test MoneyTest, give your test methods descriptive names.

It (the descriptive name of the method) forces you to think about what the test code is supposed to do

Be expressive what you are testing

In PHPUnit 3.7 there is a new @cover Annotation to only mark code inthis method in the code coverage report

/**
  * @cover Money::negate
  */

This avoids false positives in the code coverage report, if the method only is a sidenote of a test.

Create good error messages

$this->assertEmpty(array()); # Error: asserted empty, got not empty
# vs.
$this->assertTrue(empty()) # Error: asserted true, got false <- bad.

Use assertions

Obviously... Use them.

Strict mode

The strict mode counts the assertions in a test. If there is no assertion, the test is marked as incomplete and there is no code coverage.

phpunit --strict --verbose MoneyTest

Use it!

Write real unit tests

Remove all dependencies, use mock objects or stubs.

$stub = $this->getMock('MoneyInterface');

$stub->expects($this->any())
	 ->method('getAmount')
     ->will($this->returnValue(1));

Decouple test code and data

Data providers solve the problem to duplicate the test code for different parameters.

/**
 * @dataProvider provider
 */   
public function testAdd($a, $b, $c) {
	$this->assertEquals($c, $a + $b);
}

public function provider() {
	return array(
    	'correct1' => array(1,2,3), 	# you can set names for the groups to pop up in error message
        'correct2' => array(5,6,11)
    );
}

Use a configuration file

Bootstrap file, configuration settings

Bootstrap runs a bootstrap file before the tests are run.

  • backupGlobals (backup global variables before tests and restore afterwards)
  • backupStaticAttributes (same as above, but with static attributes)
  • strict mode (see above)
  • cacheTokens (static code analysis checks for die(), echo(), etc. and caches these tokens)

It is possible to order the unit tests

  1. (real) unit tests, run fast, are very valuable, because it shows directly the unit of code which fails
  2. integration tests
  3. edge-to-edge tests
  4. end-to-end test

The larger the test is, the less valuable the output is

Define the type of logging

junit, coverage-clover, coverage-html and the targets of the export files

Filters

Define filters, in which files should be looked for tests

Use the most specific assertion!

Write real unit tests

Desingnig Beautiful APIs

| Tags: IPC12

Talk by Tobias Schlitt (@tobySen)

Cute little animals raise the concentration level

Know your audience. It depends on your developers and users, whether they understand a API or not.

On the beauty of APIs

A beautiful API enables you to realize even unforseen feautures with elegant code

A good API...

  • ... keeps you flexible, so you can easily add new features.
  • ... is as much code as necassery.
  • ... has a few code as possible.
  • ... is easy to read and understand.
  • ... is simple and testable.

Where can APIs be found

  • Web-APIs: REST, XML-RPC, SOAP, ...
  • Libraries / frameworks
  • Layer boundaries / components / modules
  • Interfaces (and abstract calsses!)

Levels of Beauty

  • OOP/OOD
  • Consistend, good looking code
  • Tests

Syntactic / semantical beauty

  • Code structure
  • Naming & meaning

Documentation

  • API docs
  • Examples & Tutorials
  • User generated docs (comments)

Be descriptive, avoid being ambigious

find() is a lot better than fetch()

index() is better than add()

Avoid dependencies and allow testability

Service::getInstance() # IS BAD

Make implementations replaceable

Use dependency injection to make classes replaceable, for example:

  • search with Solr
  • and put indexing jobs into a ZeroMQ to index it later

And if you want, change it later.

Writing strings in code sucks

No auto completion, you don't get errors shown in your IDE. So use classes and methods instead.

Never use constants for processing instructions

Use a tree of classes instead and map the different criterions on differenct classes LogicalAnd, Equals, Like, etc.

Same for arrays, there is no autocompletion, nobody knows what to put into it. (e.g. Zend Framework Version 1 Zend_Db::__construct())

Prefixing methods with is (e.g. isAllowed()) which returns a boolean value is common sense.

Let your user create objects

No singletons, no static stuff, no static dependencies