Wiki Hackathon _dieses_ WE in Essen

2017-03-29 Thread Paul Hänsch
Hallo Liste,

für dieses Wochenende ist in der Stadt Essen ein Workshop zur Pflege und zum
Ausbau des FSFE Wikis geplant. Die Planung lief bisher über die
WikiCareTakers-Liste und vor Allem über [1].

Da einer der Koordinatoren nun kurzfristig abgesagt hat, und es vermutlich
etwas weniger technisch wird, möchte ich die Einladung zum Workshop hiermit
explizit ausweiten.

Es soll darum gehen Praktiken für die alltägliche Wiki-Bedienung zu finden,
und als Empfehlung zu dokumentieren, Artikel übersichtlich zu verlinken,
Plugins für den Gebrauch zu evaluieren und allgemein durch Dokumentation und
Struktur die Übersichtlichkeit und Bedienbarkeit des Wikis zu verbessern.

Wir treffen uns am Freitag und Samstag im Unperfekthaus, und ich möchte euch
ermutigen, an einem oder beiden Tagen dazu zu kommen [2].

[1] https://wiki.fsfe.org/Teams/WikiCaretakers/Sprint2017
[2] https://wiki.fsfe.org/Teams/WikiCaretakers/Hackathon2017

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Freier-Software-Abend am 29.11.2017 - Einladung

2017-11-28 Thread Paul Hänsch
On Tue, Nov 21, 2017 at 09:48:17AM +0100, Dr. Michael Stehmann wrote:
> Gäste sind auch bei diesen Treffen wie immer herzlich willkommen.

Hallo Düsseldorfer,

Ich möchte die Gelegenheit nutzen um einmal bei euren Treffen vorbei zu
schauen. Ich reise mit der Bahn und würde mich freuen, wenn sich für mich vor
Ort die Gelegenheit ergibt später auf irgendeiner Couch zu crashen.

Wir sehen uns am Mittwoch!
-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

JavaScript als Barriere (war: Aktion Mensch und der barrierefreie Player)

2017-12-20 Thread Paul Hänsch
On Wed, Dec 20, 2017 at 07:23:17PM +0100, Johannes Zarl-Zierl wrote:
> Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber 
> was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist 
> (grundsätzlich) kein Problem, solange einige Regel beachtet werden.

Ich denke, Seiteninhalte hinter die Ausführung von JavaScript zu stellen
nötigt den Benutzer dazu Code auszufuhren, über dessen Tun und Inhalt er
effektiv keine Kontrolle hat. Das ist meiner Meinung nach inkompatibel mit den
vier Freiheiten. Allein eine Free Software Lizenz ändert daran nichts, denn
der Benutzer hat ja dann immer noch keine Kontrolle über das Script, das ihm
die Seite da aufdrängt.
Deswegen bin ich persönlich immer gegen den Einbau von JavaScript auf
FSFE-Seiten. Einen offiziellen Konsens haben wir da leider im Moment nicht.

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Aktion Mensch und der barrierefreie Player

2017-12-20 Thread Paul Hänsch
Ich verfolge diese Liste sonst nicht aktiv, nur ein paar Anmerkungen dazu:

On Wed, Dec 20, 2017 at 03:34:58PM +0100, Christian Imhorst wrote:
> Ich bin da aber leider zu wenig Experte, um das einschätzen zu können,
> würde aber auch sagen,
> dass HTML5 in diesem Sinn besser ist als JavaScript.

Der Begriff HTML5 ist diesbezüglich leider ein völliger Rohrkrepierer. Die
tatsächliche Markup-Spezifikation hat eine Handvoll Features standardisiert,
die von Browsern ohnehin schon mehr oder weiniger unterstützt wurden. Am
berühmtesten ist dabei das Video-Tag.
Vor allem aber erschien HTML5 im Paket mit einer Revision verschiedener
Webstandards. Darunter CSS3, SVG und eine (mehr oder minder) einheitliche
Spezifikation einer ECMA-Script-API (aka. JavaScript).

HTML5 ist damit im Sprachgebrauch zu einem Sammelbegriff von allem geworden,
was Browser in den letzten Jahren irgendwie angefangen haben zu unterstützen.
Insbesondere ist es eine Entschuldigung geworden Browserseitiges Scripting
einzusetzen, weil das ja jetzt "standardisiert" sei.

Wenn du heute einen Webdev HTML5 sagen hörst, heißt das häufiger als nicht:
"wir werfen da jetzt ganz viel JavaScript drauf". Möglicherweise ist das das
Gegenteil von dem was du dir vorstellst. Klar ist dass du an dem Begriff
eigentlich garnichts festmachen kannst. Ich empfehle ihn zu vermeiden.

> Da Basis "mediaelement.js" denke ich nicht, dass es funktioniert. Wie ich
> das sehe, wird JavaScript
> für die Steuerung benötigt und für das Flash bzw. Silverlightfallback für
> ältere Browser, die kein
> HTML5 unterstützen.

Wahrscheinlich denken die Entwicker sowas in der Richtung, das ist aber
quatsch. Das -Tag ist mit einem Fallback spezifiziert, das in eben den
Browsern wirksam wird, die das Tag nicht unterstützen (da unbekannte Tags
schon immer quasi wie ein  behandelt werden). Darin kann z.B. das breit
unterstützte, aber dazumal inoffizielle -Tag untergebracht werden, oder
ein iFrame oder einfach ein Download-Link zum Video - all das geht auch als
Kette von Fallbacks, die absolut kein Scripting benötigt.

> > * Wie kann ich verschiedene Sprachversionen unterstützen? Bei der
> >  aktuellen Seite können wir je nach Spracheinstellung der Besucher ein
> >  unterschiedliches Video einbinden [1]. Binde ich den vorgestellten
> >  Player ebenfalls einfach per HTML-Snippet ein (bei dem ich ja ggf. den
> >  Videolink modifizieren kann), oder liegt das in irgendeiner Datei, die
> >  dynamisch geladen wird?

Videodateien und externe Untertitel lassen sich genau so per language
negotiation selektieren, wie wir es mit html-Dateien machen.

> Könnte man sich anschauen, wenn nicht das eigentliche K.O.-Kriterium käme,
> nämlich:

> > Ein weiterer Punkt ist natürlich der Aufwand. Schon jetzt sind
> > professionell gestaltete Videos ein hoher Kostenaufwand, die Untertitel
> > zeitaufwändig für unsere ehrenamtlichen Übersetzer. Zusätzlich bräuchten
> > wir ein Video für Gebärdensprache (und gibt es da nicht auch
> > verschiedene Sprachen?) sowie eine Tonspur mit Audiodeskription.

Richtig. Ist dieser Aufwand geleistet, braucht es allerdings kein JavaScript
um verschiedene Varianten zur Auswahl zu stellen. Ich weiß ehrlich nicht was
man da Scripten wollen würde, oder warum das Vorteile bringen soll.

Wenn die Aktion Mensch natürlich zu einer JavaScript-Klitsche geht und sagt,
die sollen ein JavaScript bauen, das dies und jenes macht, nehmen die das
Geld. Der Fehler liegt in der Spezifikation.

Der Hauptgrund, warum so viele Webseiten JS verwenden um damit das -Tag
zu erzeugen, das sie eigentlich gleich hätten in die Seite schreiben können,
ist wahrscheinlich, dass sich das im Workflow so ähnlich anfühlt wie damals
den Flash-Player einzubinden. Das gepaart mit Copy-und-Paste-Programmierung
aus Unwissenheit.

Erschwerend kommt hinzu, dass Youtube ja auch JavaScript zur Video-Einbettung
benutzt, auch im sogenannten HTML5-Player. Der interessierte Beobachter kommt
dann schnell auf die Idee, dass das so sein muss. Eigentlich macht Youtube das
aber nur aus DRM-Gründen.

Meine Erfahrung ist, dass man dieser Unwissenheit meist mit wenig Aufwand
abhelfen kann. Webdevs verstehen die Problematik, wenn man sie anspricht, und
sind schnell bereit auch aus einer anderen Quelle zu Copy-Pasten.

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: JavaScript als Barriere (war: Aktion Mensch und der barrierefreie Player)

2017-12-20 Thread Paul Hänsch
On Wed, Dec 20, 2017 at 11:53:31PM +0100, Johannes Zarl-Zierl wrote:
> > [...]
> 
> Diese Thematik sehe ich orthogonal zum Thema, ob JavaScript Barrierefreiheit 
> unterstützt oder verhindert.

Das verstehe ich. Es ist nicht ganz das selbe. Lass mich nochmal versuchen zu
deinem Punkt zurück zu finden.

On Wed, Dec 20, 2017 at 07:23:17PM +0100, Johannes Zarl-Zierl wrote:
> Ich habe zwar nur sehr beschränktes Wissen zum Thema Barrierefreiheit, aber
> was ich bisher aus einschlägigen Vorträgen gehört habe war: Javascript ist
> (grundsätzlich) kein Problem, solange einige Regel beachtet werden.

Ich denke es kommt auf den Workflow an, den der jeweilige Benutzer gefunden
hat.

Kann ein Benutzer z.B. eingeschränkt sehen, will er manchmal nur Text
vergrößern, oder mit der Maus markieren können (zur Kontrasterhöhung oder
Übertragung in ein TTS-System). Das Scripting darf dann nur nicht aktiv
dazwischen funken.

Insbesondere Nutzer ohne Sicht können aber nach meinem Verständnis ein
Braille-Terminal entspannter finden als einen Vorleseautomaten. Hier kommen
häufig Browser zum einsatz, die einfach kein JavaScript implementieren, auch
wenn das eher eine Überschneidung ist als eine zwingende technische
Beschränkung.
Hier ist es nötig, dass die Seite auch ganz ohne Scripting voll bedienbar
bleibt, und dass vor allem der Textinhalt mit dem Dokument geladen wird (und
nicht erst hinterher durch ein Script nachgeladen wird).

Hinzu kommt, dass es für den Entwickler sehr viel aufwändiger wird,
Barrierefreie Workflows herzustellen und zu testen, sobald JavaScript ins
Spiel kommt. Häufig fällt dann die Barrierefreiheit ganz oder teilweise unter
den Tisch, weil z.B. umherspringende Elemente bei einigen Bedienweisen viel
schwieriger zu beherrschen sind als bei anderen.
Viele dieser Probleme kann man sich als Entwickler sparen, wenn man von
vornherein auf JavaScript verzichtet.

Häufig können die gleichen Effekte, für die JavaScript eingebunden wird auch
mit einem geschicktem Seitenlayout erreicht werden. Ist dies der Fall, besteht
zwar optisch kein Unterschied den man spontan mit besserer oder schlechterer
Bedienbarkeit assoziieren würde, der Browser kann jedoch unterstützende
Techniken viel besser in dem Markup anwenden das er selbst kennt und
implementiert als auf einer Funktionalität die von der Seite gescriptet wird.

Im Zwiefelsfall würde ich immer annehmen, das Browserseitiges Scripting zu
Lasten der Barrierefreiheit ausfällt.

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: JavaScript als Barriere (war: Aktion Mensch und der barrierefreie Player)

2017-12-23 Thread Paul Hänsch
On Thu, Dec 21, 2017 at 04:48:50PM +0100, Jochen Schmitt wrote:
> bei blinden Benutzer ist es so, dass sie in der Regel eine Sprachausgabe 
> benutzen, da die Informationsaufnahme über eine Sprachausgabe deutlich 
> rascher vonstatten geht, als über eine Braillezeile. Hierzu werden spezielle 
> Screenreader, wie VoiceOver, JAWS oder die freie Software NVDA benutzt. Als 
> Browser kommen die normalen Browser in Einsatz, welche auch von sehenden 
> Personen benutzt werden.

Danke für die Beschreibung, meine Vorstellung hierzu war nur grob, und zudem
veraltet.

Hast du Informationen dazu, was für Einschränkungen außerdem noch Hindernisse
in der täglichen Arbei mit Webseiten darstellen können? Das erste woran wir
denken sind immer Augenprobleme, wie stark fällt es aber im Allag ins gewicht,
wenn ich z.B.
 - Maus, Tastatur oder Touchscreen jeweils nicht bequem nutzen kann?
 - nicht hören kann (Inhalte in Videos scheinen häufiger zu werden)?
 - Probleme mit Farbwechseln / Bewegtbildern habe, die in der Nähe der Inhalte
   auftauchen?
 - was für Probleme kann es noch geben?

Hat jemand Informationen dazu, wie hoch die Frustrate bei den jeweiligen
Personengruppen derzeit ist? Kann jemand beschreiben wie man unter den
jeweiligen Randbedingungen das Internet nutzt?

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de

Re: Give it away! - 27.01.2018 18:00 Uhr

2018-01-26 Thread Paul Hänsch
On Wed, Jan 10, 2018 at 06:37:23PM +0100, Dr. Michael Stehmann wrote:
> Ich würde mich freuen, wenn Ihr mich auf dem Weg "heraus aus unserer
> Filterblase" begleiten würdet.

Ich bin dabei. Bis morgen.

-- 
Paul Hänsch █▉Webmaster, System-Hacker
  █▉█▉█▉  
Jabber: p...@jabber.fsfe.org▉▉ Free Software Foundation Europe


signature.asc
Description: PGP signature
___
FSFE-de mailing list
FSFE-de@lists.fsfe.org
https://lists.fsfe.org/mailman/listinfo/fsfe-de