From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by befuddled.reisers.ca (Postfix, from userid 65534) id 6E2C31EF839; Thu, 9 Oct 2014 09:15:02 -0400 (EDT) Received: from hurricane.the-brannons.com (hurricane.the-brannons.com [IPv6:2001:470:1:41:a800:ff:fe3e:bc77]) by befuddled.reisers.ca (Postfix) with ESMTP id 764FF1EF837 for ; Thu, 9 Oct 2014 09:15:00 -0400 (EDT) Received: from localhost (71-38-154-164.ptld.qwest.net [71.38.154.164]) by hurricane.the-brannons.com (Postfix) with ESMTPSA id 7D4F678C54 for ; Thu, 9 Oct 2014 06:15:17 -0700 (PDT) From: Chris Brannon To: "Speakup is a screen review system for Linux." Subject: Re: the push to get rid of CONFIG_VT in the kernel and the future of Speakup References: <87zjd64c16.fsf@mushroom.PK5001Z> <543593E4.5040400@gmail.com> <54359B9E.10203@verizon.net> <5435AE9F.1090306@math.wisc.edu> <5435B544.2090907@math.wisc.edu> <20141009123246.GF1044@opera.rednote.net> Date: Thu, 09 Oct 2014 06:14:54 -0700 In-Reply-To: <20141009123246.GF1044@opera.rednote.net> (Janina Sajka's message of "Thu, 9 Oct 2014 08:32:46 -0400") Message-ID: <87vbnt2xm9.fsf@mushroom.PK5001Z> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Bogosity: Ham, tests=bogofilter, spamicity=0.000000, version=1.2.4 X-BeenThere: speakup@linux-speakup.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Speakup is a screen review system for Linux." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 09 Oct 2014 13:15:02 -0000 Janina Sajka writes: > If the answer is that the console needs to stay, then we need console > based a11y. Yes, console access is still useful and relevant for lots of us. The whole point of the message that started this thread is that We need to be aware of possible future developments in Linux, so that our community can adapt without being caught off-guard. I'd really like to know how long we will have the current console code in the kernel. For now, the answer is "indefinitely", but there's a real possibility that the situation could change in coming years. I guess the next step is to start making a contingency plan. How will a screen reader be integrated with the coming userspace console solution? Should it be included directly in that codebase, or should it be some sort of third-party add-on? I think the latter approach is probably the best, because it can be maintained by the people who care the most about console a11y. Also, it allows for multiple interchangeable implementations, independent of the userspace console server itself. That means we will need some method of hooking into the console server for accessibility purposes, in much the same way as we use the kernel-provided keyboard and VT notifier mechanism today. For that, we'll have to come up with some sort of API, and we can't do that in a vacuum. At some point, we're going to have to open a dialog with the folks who are working on the userspace console server, so that our concerns can be addressed. -- Chris